So I received this question from Alex Voss the other day:

“As I am just embarking on a software development project, I would like to know from Steve what the benefits and risks are of developing a piece of software in a completely open way? Should I make all my source code available from the start to attract potential collaborators and to solicit contributions or should I keep it close initially to avoid getting locked into early solutions that have been taken up by others? Are there examples of how people have gone about this that I might learn from?”

Certainly a challenging and quite wide-ranging question, but one that applies to many people who are considering open sourcing their software, so definitely worth a look. I’ll be answering this in two posts, so let’s take a look at each question in turn…

“What are the benefits and risks of developing a piece of software in a completely open way? “

By developing your software in an open way, you can build a community that will help to sustain your software beyond the original project. Open sourcing your software can raise its profile which can increase uptake, and it provides an organisational structure for developer contributions and feedback, which helps to improve it. A user community can also offer perspective and steer on your decisions. Focusing on the needs of an open-source community will allow you to develop software that can be used and developed by others.

But of course this approach has its risks. There can be a lot of effort involved in managing contributions, ensuring the code repository is usable and up to date, building public releases, dissemination, and continuing to engage the community as it develops. And of course, as this occurs, software support can become an issue. You risk spending more time handling the open-source and support aspects of the software, than you spend on core development to meet the goals of your project. You must select an appropriate licence that permits open development in the way you want, whilst protecting the software rights you wish to retain. A too restrictive licence may stifle the community development, and a too permissive one may not protect your interests – OSS-Watch provide a very useful discussion on this. If your software uses other open-source software you wish to distribute (such as libraries), you must also ensure your licence is compatible with those licences. OSS-Watch can directly advise on selecting a licence.

So you can get a lot from open sourcing your project, but these benefits are not without overheads and risks which must be considered. Next week I’ll be answering the second part of this – looking at how, and when, to open source your software and some good examples of how this has been done.

‘Till next week!