I come across a lot of projects (especially in the academic realm) that don’t like releasing ‘open source’ code until the code is all nice and pretty. Some also want to get governance structures etc in place before doing anything…
It is almost once or twice a month that I find myself in discussion with a project about this. They are usually very nice people, well meaning, but don’t really have a good handle on how open source works.
Firstly, there is a well-known mantra in software development that is true in general, but particularly true for open source:
Release early, release often
In the open source world, there are very special reasons why this is a best practice and baseline premise. First, it tells people that are watching, the people that will want to use and/or contribute to your project, that you are serious about open source. If instead, you hold back the code, it sends the signal that you ‘don’t really get it’. I can’t recall a single conversation with an open source advocate that argued for holding back the code until it’s all nice and neat. So, you’re sending out a signal that you don’t really understand how open source works, and that is a bad look.
This is especially true if there is anyone among your potential target collaborators/partners that have been around the open source block a few times as they will be extremely wary of anyone saying ‘we will release it’…or (worse) ‘it is open source, but we haven’t released it yet’… you might be stating this because you ‘know’ it to be true… but from the ears of the listener (especially and old hand) there is nothing different between what you are saying (which you consider fact) and a promise of sorts. You are asking people to trust you to do this sometime in the future – and people like me, who have heard this a lot, will automatically tend not to believe you. Not because we don’t think you believe this to be true, not because we are inherently distrustful people, but because we have heard so many, many, people say this that have not gone ahead and done it.
If you say it is open source, prove it by handing out the repo URL. Otherwise, don’t expect anyone to believe you or trust you – and trust, as it happens, is the most important ingredient in successful open source communities. If you wrong foot it at the start, you have just created yourself an unnecessary uphill battle to rebuild trust when (if) you finally do release the code…
Secondly, open source models are all about adoption…. that is the entire market-killing model of open source. Adoption. Open source can kill proprietary products just simply because the threshold for adoption is lower (ie, free to try, free to install, free to use etc). If you wait until everything is in place, then you have just killed one of the most important moments to build interest and adoption – early stage development. Interested orgs/individuals can download the code and see what is about as soon as they hear about it… that way they can see where you are going, and if it is the right direction for them, they may decide to adopt the product (even in early stages) and/or contribute to the project. It is very good if this happens as these early adopters will be the product’s main advocates, drawing in the next layer of interested parties… they become the project’s salespeople. They will be especially good at doing this because they have been in there from the beginning, following and (hopefully) participating in all the discussions and decisions, and so they understand the project in detail and can talk to it with authority. That is invaluable.. .why wait? Don’t wait…if you do, the threshold for getting involved is going to be a lot higher (since there is more to understand) and the burden of helping people understand the project, and ‘selling’ it, will fall entirely on your shoulders rather than being nicely distributed upon the shoulders of the early adopters…
Lastly… all open source projects grow organically and respond to the needs of the moment. So don’t wait to build governance structures etc before putting the code out there. This is not only bad for the reasons discussed above, but in the early phases of the project, there is nothing to govern… It is just you (you, literally, or your org)… so first build the community and then look at what infrastructure you need to put in place to run that community. That is what governance is all about ..running the community. So, why not wait and see who shows up, and then decide what the governance structure (etc) should look like. Also, as a last word, make sure your community is involved in discussing and deciding the shape of the governance…
anyways…just a few thoughts on this from Rarawa beach!