Don’t call it “open source” unless you mean it Monday, October 22nd, 2012 at 6:36 am

In terms of releasing code into the wild we live in terribly exciting times. Products like GitHub, Dropbox, online collaboration tools like JSFiddle, JSBin, Codepen and Dabblet make it very easy to show our code to the outside world. Furthermore, a lot of products are build in a modular manner which means you can simply participate by writing a plugin or add-on instead of coming up with your own solutions. jQuery and WordPress are living proof of that.

Quick release, moving on fast

One of the biggest dangers of a very simple infrastructure is the one of inflation. When it is easy to release something, a lot will be released. This means it becomes much harder to find good quality content and we are tempted to release more rather than releasing a few things we really care about and are ready to also care for in the future. Much like we write shorter, and less thought-out emails than letters we tend to get into a frenzy of releasing smaller, shorter and less documented products.

This is open source – or is it?

This is where we run a current danger of cheapening the term “open source”. Releasing an open source product is much more than making it available for free. It is a process, an ongoing commitment to nurturing something by sharing it with the world. Open source and its merits can actually be a blueprint of a much more democratic world to come as Clay Shirky explains in How the Internet will (one day) transform government.

During the Fronteers conference, David DeSandro gave a talk about monetising jQuery plugins and how to keep your sanity at the same time. His main concerns were that his plugins (mostly Masonry) cost a lot of his time and didn’t bring in enough to make a living off them. Several times during the talk he explained that he does have a job and that he has no time to answer every email. After all, there should be no need to ask questions or get support as the code is available and on Github and people could help each other and be happy that the code was released as open source. How come there was no magical community appearing out of nowhere that took care of all this?

Open Source is more than releasing code

Well, this wasn’t an open source project. The code was released in the open and is available on a repository, but it is not open source. Open source means – at least to me and a lot of people I talked to – that products are produced and maintained in the open.

This encompasses much more than just putting the code on GitHub. It means:

being ready to take on pull request and patches and communicate to the people who do them when and if they are released

helping people to get involved

communicate changes to the outside world

reacting to security issues and performance issues

answering feature requests

dealing with licensing issues

ensuring that the product evolves and changes as a reaction to new environments and market needs

encouraging people to contribute and help others

recognising people for helping out others and sharing the fruits of the labour with them

Open source is a lot of work and needs a community

This means a lot of work and it is the reason why a true open source project is not done by one person but from the very beginning should be planned around a group of people. People who are happy to share ownership and responsibilities as much as the benefits and the income from the project with others. People who are ready to hand over responsibilities should they get tired of them and to train their predecessors with that in mind. To be truly open source you should think about the maintenance and the future of the project before you release it. It is a group effort and the very tricky part is finding the group without hiring them.

A lot of what people call open source these days feels like “Tada-source” or “Pasture-source” to me:

Ta-da source – products that are released as a final commercial version as-is and get a source release to the world later. Instead of making the world part of the creation process it becomes maintenance staff to fix bugs and add the things they need to the product. This allows you to say you are open without having to deal with people’s needs and to stick to your own agenda when it comes to core functionality.

– products that are released as a final commercial version as-is and get a source release to the world later. Instead of making the world part of the creation process it becomes maintenance staff to fix bugs and add the things they need to the product. This allows you to say you are open without having to deal with people’s needs and to stick to your own agenda when it comes to core functionality. Pasture source – this is when products were financially viable and interesting but became a nuisance. Instead of maintaining them they go to the pasture of open source where kind shepherds without pay will ensure the products will live happily ever after. Pasture source happens either because of the workload of communication getting too much or because the business you work for doesn’t see the product as something they should pour resources into. A lot of times this is a PR exercise – “hey this product didn’t do well, but now that it is open it will be the next new cool thing for the open source community”

Brackets – a positive surprise

When Adobe said they’ll release their editor Brackets as Open Source and have it as Edge Code in their new set of tools for web developers I was not alone in being wary about this. It sounded like a closed source company trying to play with the rebel kids. Technically this is not new, as Adobe already did a lot of open releases with Air and even released the books under Creative Commons but it still felt “well, let’s see what is coming there”.

When seeing Adam Lehman talk about Brackets and their approach at the Adobe event in London I was very impressed to see how the project is run as an open source project. The code, of course, is available on Github, but that is not all. The project is following an Agile process using Scrum, pull requests are being reviewed every day, it has a 2.5 week release cycle and external contributions take priority. A detailed blog with release notes of each sprint is also available.

The project is managed in the open on Trello and a very clever way to get new contributers is to triage simple bugs as “quick wins” for new contributors rather than having more advanced developers spend their time on fixing them.

This is a great example of approaching an open source release of a product with the right tools and the right mindset. Yes, it is a lot of work, but I am quite confident that this means Brackets will be around for a long time, even if the Edge suite failed.

Don’t stop releasing

I am not saying that we should stop releasing things and making them available on GitHub and others. I am simply saying that open source means much more than that and that we shouldn’t be surprised if we get less contributors than we think if all we do is throw some code out and wait for magic to happen. Open Source means we get people’s time to build with us, not for us.

So when you release things, don’t call it an open source project, unless you are ready to go the full distance. Just put it out there and tell people that it is free and available, and that it is up to them what happens with it.