Team building is a challenge for me with open source projects. There is a certain amount of latitude that you have to give everyone on the team in order for there to be some fun, and there is also a certain amount of control that you need to have over the processes in order to maintain the desired consistency. Motivation I have found, usually isn't nearly the concern as it is with for-profit projects, however, keeping everyone on the same page is. It is quite unique that the constraints are completely different with the mindsets.

I suppose that this can be illustrated through the 'TOC' theories, since the exploiting the constraint is different, as well the measurements, and the end goals. Is there a need for throughput reporting, when the goal isn't always to show a return?

I have been looking at the different models of OpenSource structuring, and how successful projects work, since my last project goes into the semi-failure side on my management skills. Some of the organizations such as Apache make very good distinctions as to the 'ladder' of responsibilities, and accountabilities, but I have been wondering if it is the best model for me to benchmark and measure against. Not to say that it isn't the best to emulate, but are there further opportunities to exploit from the constraints of the org structure?

I still don't know if I can grasp in my mind what the ABSOLUTE end goal of an open source project management should be, when there appears to be several to choose from. I must somewhere along the line seem to be missing the castle at the end of the maze. If you take any kind of money out of the equation is the end goal simply satisfaction of creation, or is there some other goal to ponder? If you throw any money back into the equation, does the P & L and throughput become the top of the line as the 'goal'.

Bah, need a beer and another vacation to start think more abstractly.