A major problem with open source projects is, that, most of the time, it is not clearly visible in which state the project is. At least not for a casual user of the software, for example a guy like me wanting to try the software.
A version number can be a way to express a certain stability, especially if
the project uses semver, though even a
1.0 in semver does not express
the state a project is in, only that you won’t see breaking changes between
(minor) version upgrades.
This is my attempt for defining a scale which can be used to define the maturity of a open source project.
In the following, I’m defining Levels for the stability of an open source project.
I define them based on my experiences and views. This means that you might disagree with their definition or maybe even with the need of such a scale. This is fine. I wrote this article because I think we need a discussion about this and I’m more than happy to hear your opinion! Maybe though, we should not do this in a closed manner but on a platform where everyone can participate, for example on a community board like reddit.
Computer Scientists start with zero. Projects also start at zero. So am I.
Level 0 is the fundamental idea of a software. You think you, your companion or maybe the whole world needs a tool for a thing. You did not think about this idea that hard, you have no plan how to implement it or even thought about which language to use.
Then your project is in Level 0.
You wrote some code. That’s awesome! But anyways, the code might not even compile / the interpreter might complain about invalid syntax. The code is just a basic concepts - an expression of thoughts in a textual manner.
Maybe it does compile / the syntax is valid, but still the tool does not yet do what you’re planning to do.
Wow, now the tool works. At least for you. You know how to build and use the tool.
This is fine. You might be the only developer by now and you don’t care that much about other developers, because you’re still playing around. You reached Level 2.
If you did not share your code with others you might want to do that now, in Level 3. Because now, your code works for you and maybe even your neighbor programmer who thinks you did something cool and wants to try it out.
Still, your code is hacky, you might not even have documentation how to use it or how to build it, but you’re confident that you could at least show the world that you’re working on something which does something.
(I would say this is the level where most small projects on github are when they’re published).
Now you care about contributions. You include a basic guide how you did your build, how others might be able to reproduce the build and get a working software package.
You might respond to issues and pull requests and you start interacting with other people when they ask questions. Maybe you even posted your tool on reddit, hackernews or another site of your choice.
Community is important. You try to help everybody getting their first contribution merged. Your tool has grown a lot since Level 0 (or Level 3). You think about coding style, development flow and all these things which have to do with your project, but not with solving the problem you’re actually working on.
Welcome to Level 5!
This also means that at least some people with a technical background are now able to understand what you’re doing and why you’re doing it. They might even be able to build your tool to try it out. Maybe even on another platform than you initially started developing.
The community around your project is more than just your friend or fellow student hacking on the thing, but people from the internet start watching your project and from time to time, an anonymous person opens a pull request to help you implementing a feature or bugfix.
This is awesome and it really feels good getting other people involved in your codebase!
A major event in your project is the first issue/bug report/change request/feature request from a person who is not involved in development of the tool itself and does not even want to - but still wants to use or at least try the tool.
This is when you entered Level 7 - you should now start thinking about how to talk to users of your software!
You have a small but dedicated group of users. That means that there are people on this planet using your software. And these people might not even know the programming language you’re programming your tool in!
You have people answering questions on IRC which are also developers of your software and you don’t have to answer them yourself.
Welcome to Level 8.
Now you have a certain responsibility to these users to keep your software running, because they are interested in using your software!
You commit to stability, good documentation and bug fixes as soon as possible.
This is because your community has grown. There are people on your IRC asking questions you can’t remember whether you’ve seen them before in the IRC. You’re maybe even getting mails about how to use your software.
Everyone in your community knows that this is still a hobby for you, so you might be unresponsive for a certain amount of time, but anyways they are hoping to get bugs fixed, functionality implemented and questions answered - better sooner than later.
At this point, the development of your software is not the main point anymore. The users are. The support truly is. Development slowed down a lot - not only for but also because your commitment to API stability.
At this point, your software (hopefully) is not in pre-1.0 version anymore. This is because you have a really large user base by now. You have IRC channels, maybe a forum, a message board, maybe even a subreddit, google groups or facebook groups for supporting users.
Other developers are heavily involved in your software. There are people around who can do magic with your software. Maybe even people who help developing the software, but never contributed a single line of code because they only contributed translation, style and design, documentation or tutorials and guides. These things might even pop up in the internet without you noticing.
Welcome to Level 10 - where our journey ends. Your software is now used by a lot people and hopefully your bus factor has grown to at least 2.
Where the journey ends
After writing the 10 Levels of open source project maturity, I could rewrite the title of this article to “Open source project community size definitions” or something like that. But I won’t do that, because it would not express what I was thinking about before writing these words down.
Overall, one might disagree strongly with these points. As said above, this is okay. The scale might be extended as well. Maybe there are Level 11, Level 12 and Level 42 as well? I don’t know, I did not think further than Level 10.
Examples for the Levels
The levels from above do not have any examples stated. That’s because I want the reader to make their own thoughts about this.
Either way, I’m providing some examples that I’d define for these Levels. I hope they match the readers view:
- Level 0 - No example necessary I guess.
- Level 1 - No example necessary I guess.
- Level 2 - No example necessary I guess.
- Level 3 - No example necessary I guess.
- Level 4 - Maybe my tool nixos-scripts is a good example for this Level.
- Level 5 - This is where I actually think my own project is: imag. Besides that I’d include khal here.
- Level 6 - I guess bjoern is a nice example for this.
- Level 7 - I failed finding a good example for this. Feel free to suggest one.
- Level 8 - tig might be a good example here
- Level 9 - Tools like dwm, surf and other tools from the [suckless] community would be a nice example here, I guess.
- Level 10 - This is where tools like git, libreoffice, KDE and other “big” pieces of software should be placed.
If anyone feels offended because I categorized their tool in a level which is inaccurate for their tool, feel free to send me an email and I’ll remove the link to your project.
You always can argue about “size” of a community as well, so these points are all from my perspective and might not be that accurate from your point of view.
Thanks for joining me on this journey. I hope we can have an open discussion about this.
As stated above, discussion these things via email might not be beneficial, as discussion is not a two-way communication in my opinion, but a multi-directional one.
So, if you care at all or maybe even want to write about these things, feel free to submit a link to your blog post about this and I’ll link them here - maybe we can have a discussion on reddit or somewhere, but I’m not sure where to post a thread for this topic.