Skip to main content

Ask Steve! - Developing software in an open way: Part II

Posted by s.crouch on 29 June 2011 - 4:06pm

So, continuing on from Part 1 of Developing software in an open way, let’s answer the last two aspects of the question from Alex Voss…

“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?”

You will have project goals to fulfil, so I think it’s always a good idea to start development internally. This means you can put your software firmly on the path to meeting your own project’s goals. When and how external involvement comes into play will depend on the project.

Firstly, it’s important to consider how you want to govern your open-source project. If you are worried about becoming locked-in to a solution chosen by others, you should stay away from the democratic/meritocratic systems, because you lose some control with these approaches (you can be outvoted). A benevolent dictator approach means that you alone have the final say on which contributions to include into your software – and which ones to exclude. You gain control, but benevolent dictators have to put in a lot of work (they’re doing all the work of the committee in a meritocracy) and require good diplomacy and community skills. Whatever approach you decide, you should always spell out the governance and contribution policy clearly so that your contributors know where they stand before they work on your project.

If your project’s success is dependent on collaborating with other people, you will want to start publicising your project early on. But before you start with publicity and getting people on board, it’s a good idea to familiarise yourself with of an open-source infrastructure, such as SourceForge or GitHub. After looking around and selecting a suitable infrastructure that meets your needs, this means you will know how to operate the infrastructure and will be accustomed with uploading your developing code on a regular basis. Once this groundwork is in place, you can start seeking out and engaging people to participate in your project.

It’s also a good idea to architect your software so that it is readily extensible by other people, whilst not precluding the development of other alternative solutions. Software designed as a framework allows you to develop an initial release that extends the framework to accomplish a task needed for your project. Contributors can then plug in their code, which might extend the framework to accomplish the same task in a different way, or a new task altogether. The trade-off here with extensibility is between the time taken for initial development and the ease of long-term maintenance effort. You need to decide the right level of extensibility for your software.

In short, it’s about the effort you put in.

“Are there examples of how people have gone about this that I might learn from? “

OSS Watch has some great case studies and examples of how this can be done.  Moodle is often held up as a good example of what can be achieved. OSS Watch also has an interesting case study on Wookie that you might find useful. The key is to pick and choose the right open source features for your software.


Share this page

We use cookies on our website to support technical features that enhance your user experience.

We also use analytics & advertising services. To opt-out click for more information.