“You need to overcome the tug of people against you as you reach for high goals.”
George S. Patton.
Long-time readers of this blog will be familiar with the use of Seth Godin’s thrashing principle in OSS to attempt to get a scope locked in and developed against.
The reality is that despite all the best intentions, it’s incredibly rare for changes in scope to appear whilst an OSS project is in-flight. So you may well be looking for guidance on how to handle projects where requirements are sketchy or changing with rapid fluidity.
Long-time readers will also be familiar with my belief in the laws of momentum/inertia applying equally to OSS projects as they do to the world of physics. Even a project with fluid scope needs to develop a momentum of delivery rather than the procrastination of trying to lock down perfect requirements.
I tend to find that even on a highly fluid project, there are usually some requirements that are all but certain amongst the maelstrom of change. There is one principle that indicates that you should tackle the most complex elements first as they’ll take the longest to implement, but following this principle often doesn’t allow for the perception of momentum to build, particularly in the customer’s eyes.
With the momentum principle front-of-mind, I recommend tackling some of the smaller, simpler, least volatile (in terms of change) elements first and build a mode of delivering from the outset for your OSS project.