I’ve started working on a few OSS projects of my own – one’s in the planning stage and another is in the code-now-plan-later stage – and it got me thinking…
When should you start talking about your projects?
I know that the OSS philosphy is to “release early, release often” but how soon is too soon?
Take the project that’s still in planning – if I start talking about it now, others may contribute to the planning and help make a better end-product. On the other hand, it may get so involved trying to satisfy all the contributors that we never get round to writing a single line of code – look at all the DBA projects on SourceForge. Another problem is that whoever is contributing may have a very different idea of how things should be, which is at odds with your original idea and may lead to you losing interest in what is (or rather now was) your project.
Now take the second project I mentioned, which currently exists purely as proof-of-concept, and has no real plan other than seeing if my (extremely rough) ideas pan out. With a bit more work, it will be at the stage where I can start letting people play with it, and then comes the problem with the code-now-plan-later strategy – what do I really want it do?
Here’s my take on things…
Ask yourself this question:
Why are you doing it?
Only start a project if it is something you really want to do. Not because you think others will use it or do the work for you.
Now you need to…
Know where you want to go
If you’re got an itch, write down some ideas before you scratch it. It doesn’t matter how pretty or well laid out they are – you don’t need a complete requirements document here, just as rough idea of where you’re going. In Mike Gunderloy’s book Coder To Developer he describes the idea of the Elevator Pitch – essentially describing your idea in as brief, but complete (and compelling) way as possible. We’re not talking a one-liner here, but simple, brief bullet points that describe the main reasons the software should exist. Not “Create a new IM client”, but “Create a new IM client that supports A/B/C protocols, and X/Y/Z features”. The original idea behind the Elevator Pitch is that you only have a thirty second or so ride to sell your idea, but you should also see it as an opportunity to define an initial vision or (shudder) mission statement for the project – something that instantly gives people an idea of what you are trying to achieve and something you can refer back to when you feel you’re drifting off course.
Now it’s time to…
Get started
Now you know exactly what you’re trying to achieve, you’ve got two options:
If you’re an organised person (I’m not, though I’d like to be) you’ll prefer the first option, but most people will take the second. That’s fine, just make sure that a) you’re still focusing on your original idea and b) you’re not getting distracted by implementation details. The main disadvantages to coding before planning are that you’ll rarely create the plan (as there’s far more interesting things to do), and if you do, you’ll most likely discover that you could have done things much better so you then have to go back and change things. You’re also far more likely to become of victim of feature creep. This is different from scope creep where the requirements keep expanding – this where you’re adding features to the project without any clear idea of how they or evn if they fit in with your original idea.
Of course, the best advice is to do both – plan and implement your application at the same time. The secret to doing this successfully is to keep them in sync – don’t let your coding get ahead of the plan, and don’t neglect the code to fine-tune details that may get discarded or prove unfeasible during implementation.
Now start talking
Unless you’ve got an idea that you really have no idea how to implement, work by yourself (or with one or two others, but make sure they are people you can work with – not strangers in IRC or on a mailing list) and quietly until you’ve got something people can play with. If during this time you discard the project, then you’ve not wasted anyones time but your own. Once you’ve got something tangible, then release it to the world and (hopefully) start taking contributions.
Don’t fall asleep at the wheel
My final piece of advice is that if others are contributing to your project, don’t ignore them or the project. People will only contribute as long as they feel their contributions are being paid attention to. Even if someone propose a feature that you don’t want to use, let them know why – don’t just discard it.
If – at a later date – you are no longer interested in the project, either let someone else maintain it or let people know it is no longer maintained.
Conclusion
So, in a nutshell – don’t talk about your projects until there is something to see/feel, and don’t neglect your project once it has been released.
Although I’ve really been talking about OSS projects here, the same ideas about the “Elevator Pitch” and simultaneous planning & implementation can be applied to proprietary/commercial projects. I make extensive use use of the latter in my day job, and when done properly works very well. Obviously it doesn’t suit all projects, but for smaller applications it produces results far quicker than traditional methodologies.
If you’re looking for a tool to help you achieve this, look no further than Trac. It’s tight integration of the wiki, Subversion, and tickets makes for a very organic development process, and allows easy maintenance of the plans and documentation by all members of the development team. Again this is a professional recommendation as I use it to manage all of my projects in my day job, as well as a few of my personal/professional projects.
