I've been making public releases of Unworkable, a simple and efficient from-scratch BitTorrent implementation written in C for a couple of months now. Prior to that, I had been working on it for about 18 months on and off. While I wouldn't claim it to be highly successful at this early point, I make an effort to try to manage the project well, and I intend to write about some of my ideas and the things I have learned along the way. Here are some of my thoughts so far: Release early, release often. This advice was, to my knowledge, first phrased in this way by Eric S. Raymond, but its a pretty straight-forward observation. I attempt to put out two releases per month - roughly one every fourteen days. A reliable release cycle sends a great message to users. It shows them that you care about your project, that it is actively and reliably developed and it pushes you toward an evolutionary, as opposed to revolutionary, approach to development. Focus on incremental improvements. This is closely related to the above point, and is something I greatly admire the OpenBSD project for adhering to so strictly. Reliability and stability are far more important in the long term than having the latest whiz-bang feature. There is no shortage of low quality software in the world - concentrate first on doing a small set of things very well, gradually adding new features as existing ones stabilise. Strive to make your project as portable as possible. This is sadly often overlooked. A depressingly large amount of open source software today is written with the assumption that it will only ever run on Linux on the i386 platform. First of all, your goal should be to attract as many users and contributers to your project as possible. The more platforms you can support, the larger your potential pool of feedback and support. Secondly, supporting multiple platforms forces you to write code capable of dealing with both little and big endian architectures, different pointer sizes (32bit vs 64bit), and differing alignment requirements (for example sparc64 is rather strict about this). All of these differences can expose nasty bugs in your software, and its great to squash them early on! Thirdly, it pushes you in the direction of increased modularity and almost certainly necessitates a well-maintained build system - both of which are important in the long term. Embrace criticism. One of the most terrifying things about releasing your code as open source is that other people are able to look at it, pick it apart, criticize it. Many people are very afraid of this sort of negative criticism - they feel that it is a personal attack. Instead of dreading criticism, learn to embrace it. Realise that negative feedback is completely disconnected from you - it says nothing about you as a person. See it as extremely valuable input, use it to drive yourself to make improvements. Commercial software developers pay top dollar for QA departments, third party audits and analyses, user surveys and so on - you are getting this stuff for free! Furthermore, the ability to constructively accept criticism of your work is a great asset that will make you highly attractive to potential employers. Encourage feedback and contributions. I like nothing more than a detailed bug report, or a bunch of suggestions about features to implement - or even if someone submits my software to a compendium on my behalf, thats great! Some people are sadly completely incapable of dealing with users of their software. They are unable to see that just because someone emails you asking for support on an old version in a rude way, you are free to ignore them. If someone submits a diff that you don't like, you don't have to accept it. If someone emails you a list of features you "must implement", you are not compelled to do what they ask. Sometimes user contributions are imperfect - I've received diffs that I haven't committed, and I've received feature requests which I have no intention of implementing. However, I've gotten some great ideas, some nice diffs, and just generally gotten a feel for what people are interested in - and I didn't even have to pay to conduct a market survey! Thats it for now. Next time I will write a bit more about my thoughts on documentation, promotion and distribution for a highly successful open source project.

Niall O'Higgins is an author and software developer. He wrote the O'Reilly book MongoDB and Python. He also develops Strider Open Source Continuous Deployment and offers full-stack consulting services at FrozenRidge.co.