-- Yup, read them! The problem is not so much for me the idea of how to come to a successful project, because each of those white pages deal with it very nicely. What I am more interested in is applying the theory of constraints to Open Source development. Here is a brief overview of what I am talking about. There are basically three major developments in the TOC. Its also called Drum Buffer Rope in some sectors. The definition of each goes something like this:
Drum - The constraint. If we can agree that everything upstream from the constrain and everything downstream from the constrain can operate faster than the constraint itself, the the constraint is what actually determines the throughput.
Buffer - If something upstream from the constraint goes down or has problems keeping up with the constraint in the meantime because of "murphy's" then there needs to be a "safety" net of time to allow the drum beat to continue on.
Rope - You do not want to flood the system with "stuff" instead, you want to release into the system "stuff" at the same rate of the drum.
So how does this apply to Open Source Management? The same way that it apply's to project management in general. There are scheduling constraints. You need to apply a certain amount of buffers into the overall system scheduling in order to always be feeding the constraint. And you don't want to start anything new until the constraint can handle it.
What I am confused on is the goal of Open Source in general, in order to lay down a general project management white paper to push forward the ideas in general to increase the productivity of all:) So is the goal the same as commercial projects, to make money in the end? If so, then the constraint and measurements to let you know as a manager of the project needs to be set accordinly. However, I am not so sure that is the actual goal of every project. Some projects have no intention of every making a dime, but rather the goal might be to scratch the "itch", or to do something different, or to learn, or to accomplish something that others said would be impossible.
I could easily set up the goals for the my project, since they are relatively easy. However, I am just thinking aloud, because this is something that is very interesting to me, and I would like to write something from my experiences, and allow others to have a good model not for their organization or project, but rather something to help them plan and manage just a little better, using and applying some theory, and some know how:) I am just stuck at the beginning though on getting started with the actual goal, which I have taken for granted for so many years.
To me, it's an interesting exercise, thats all:) I am not trying to reinvent whats been done before, but rather to apply some of the theories that the commercial software sector has been applying for years, and relating those back:) You see, in many case Open Source has an advantage over the MicroSofts of the world, since the goals are different. However, when you drive the other car (M$) you also have several roadmaps and signs that we do not clearly have. I just think that by constructing some of those signs and maps, we are able to compete more as a community which is a good thing for all:)
Rambling again... Bah, its a diary, I'm allowed:)
Chloe's first ever soccer practice is in 2 hrs:) I am a lot more excited about it than she is.
I need to get my predictions for week 1 NFL as well;) Predicting against the spread is a little more difficult than the out right winner, but it is also a little more fun:)