I often encounter software projects, particularly in academic publishing, that hesitate to release their code as open source until it's polished and presentable. Some also prefer to establish governance structures before taking any further steps.
It's not unusual for me to engage in discussions about this topic with such projects once or twice a month. The people involved are usually kind-hearted and well-intentioned, but they may not fully grasp the workings of open source.
There is a widely acknowledged principle in software development that is applicable across the board, but especially relevant for open source:
Release early, release often
I would slightly modify the advice and recommend releasing the code now.
Releasing now is critical in the open source realm for several key reasons. Firstly, it demonstrates your commitment to open source to those interested in using or contributing to your project. Holding back the code, on the other hand, suggests that you may not truly understand open source. This is not a favorable impression to give.
Seasoned open source contributors will be particularly cautious of claims like "we will release it" or "it is open source, but we haven't released it yet." Even if you genuinely believe this, such statements sound like promises that can be easily broken. Trust is crucial in successful open source communities, and starting off on the wrong foot can make it difficult to rebuild trust once you finally release the code.
Secondly, the power of open source lies in its capacity for adoption. Open source can out-compete proprietary products by offering a lower barrier to entry (i.e., free to try, install, and use). By delaying the release of your code, you miss out on the opportunity to garner interest and adoption during the early development stages. Early adopters can become your project's biggest advocates, attracting more interest and involvement. They can speak with authority about the project because they've been there from the start. Don't let this invaluable resource go to waste by waiting too long.
There is another type of project where the code is already mature and may even be in production, but the people responsible claim they want to clean up the code since it's quite messy before releasing it. The key point here is that if the code is indeed messy, then two questions arise: 1) Why should I use your project? And 2) If it's truly messy, wouldn't it be more beneficial for users to see the code and understand the potential issues? Perhaps users could help to identify the issues and clean it up. In short, I don't know that I have ever seen a project that claims this actually open the project so I wouldn't trust this by default.
One last point - there is no need to wait for governance structures to be in place before releasing your code. In the initial stages, the community is small and manageable. Focus on building the community first, then address the necessary infrastructure to support it. Governance should be centered around managing the community. So, it makes sense to first see who joins, then determine the most suitable governance structure. Additionally, involving your community in shaping the governance ensures a more inclusive and effective approach. Although common in various domains, initiating governance from the beginning is a top-down strategy especially common in academia. Nonetheless, it is crucial to acknowledge that even when academics develop software, it is more appropriate to employ software development methodologies rather than strictly academic approaches.
In summary - release your code now.
© Robots Cooking, 2023, CC-BY-SA
Image ('Freedom') public domain, created by MidJourney from prompts by RC.