Owning an Open Source Project: Part 1

Intro or where the journey begins

Have you ever thought of having your own open source project?
I bet you have — you’re reading this article. Maybe you are thinking about it right now. Maybe you came here to better know what to expect, what challenges you’re going to face and how to deal with them.
Well, you’ve come to the right place.

In the following series of articles I’m going to share my personal experience in owning an open source project. Owning. Not contributing to an open source project but owning one. There is a big difference and in this series we’re going to learn why.

Table of content

• Intro or where the journey begins

• Starting an open source project

• Documentation

• Spreading the word (WIP)

• Getting collaborators (WIP)

• Managing issues and pull requests (WIP)

• Automation (WIP)

• Breaking changes and back-ports (WIP)

Who I am

My name is JeB and I’ve been maintaining a few open source projects for a couple of years. The most popular one and the one from which I’ve learnt the most is @angular-builders. At the moment of writing this article it has ~600 stars on Github and about 400k monthly downloads.

Yes, it’s not even close to huge projects like Angular or React but I feel that I have enough experience to share with you in order to help you avoid the same mistakes I did and more important — to understand the cost of owning an open source project.

So what is open source?

Let’s first establish a common language and align on key terms and definitions.
What is open source? Here is a very generic definition from a well known Open Source Encyclopedia (aka Wikipedia):

Open source is the concept of the information allowing the replication or modification of something being open to the public.

or, in terms of software development models:

The open-source model is a decentralized software development model that encourages open collaboration.

A main principle of open-source software development is peer production, with products such as source code, blueprints, and documentation freely available to the public.

In the case of Wiki we have those who edit the articles (contributors) and those who approve the edits (more experienced members, moderators). If we project it onto the software world the editors would form a core team of an open source project and the contributors would be, well, contributors.

Wikipedia is a huge open source project but it has all started from something small. Wikipedia was born from Nupedia and it was born for a reason:

Despite its mailing list of interested editors, and the presence of a full-time editor-in-chief, Larry Sanger, a graduate philosophy student hired by Wales, the writing of content for Nupedia was extremely slow, with only 12 articles written during the first year.

So here’s where the first question comes:

Why bothering with open source

As you can imagine from the previously read one of the main reasons for opening something to the wider audience is to gain collaborators.

Together we’re strong

(Zarya, 2016)

At the moment of writing this article Wikipedia has 37,899,499 registered accounts of which 134,022 are actively editing.

Just think of it… 134,022 active collaborators. Oh, and it has 6M content pages!

Would the numbers have been the same if Nupedia didn’t move to open source model? I highly doubt it.

Nothing is different when it comes to the software. In order to solve a certain problem you have to write code. In order to solve a big problem you have to write a lot of code. In order to solve it properly you have to write high quality code, make a high quality design etc. All this requires resources, which, let’s be honest, you don’t have. You have a rent to pay after all.

While gaining collaborators is a reasonable incentive, almost no one starts a new open source project solely because of it.
Obviously the reasons might be different but let’s talk about most popular ones.

Careful what you wish for

A few scenarios that come across my mind are:

1. You face a problem, there is nothing out there that solves it for you (or there is something but it costs money) so you have to solve it yourself, you manage to solve it, you’re really excited about your work and you think others can benefit from it.

2. You want to be recognized as founder of an open source project, you want this fancy line in your CV, you have an ego (we’re all human after all). If this is the main reason for you then I promise you, after reading this series you’ll reconsider — it’s not worth it.

3. You face a problem, there is an open source project that actually solves it for you but it’s not good enough (in your opinion) or doesn’t have the exact feature you need. If you create a new open source project solely because of this then most probably you’re at #2 (ego). Make yourself a contributor, create a PR to the existing project instead.
   If the existing project has a different vision and making a PR is not an option you should consider either extending it by reusing its functionality in your project or forking it. It may save you a lot of headache later.

4. You face a problem, there is nothing out there that solves it for you and you think that starting the solution as open source from the very beginning is a very good idea.
   It’s not.
   Solve the problem, make sure it works for you and after that go to #1.

These are the 4 incentives I find most popular for creating a new open source project but in this series we’re going to focus mainly on scenario #1.

The reason is simple — I believe that if the main reason for starting an open source project is other than eagerness to share and contribute then this won’t hold.
For quite a long time the fact that you’re helping someone might be the only reward you get. And if this is not the kind of satisfaction you’re looking for then maybe you should stop here and not waste your time.

There is another quite popular scenario which is worth to mention.
There are companies that open part of their code to the community.
For example, Angular (maintained by Google), React (maintained by Facebook), VSCode (maintained by Microsoft) and more.
The reasons for them to do that may vary but gaining collaborators and contributing to community are surely among them.
While I can’t argue with the importance of this practice, this scenario is quite different from the others because employees that maintain such projects get paid for their job.
If you work at a company that considers the possibility of creating an open source project, the majority of the content here will be still relevant for you, however the incentives might be different.

Wrapping it up

If I had to summarize this part in one sentence it would be:

Make sure your intentions match your expectations

Believing that you want to have an open source project is not the same as actually having one, as you will see in the following articles.

Thanks for reading, make sure you follow me here or on Twitter if you don’t want to miss the next part in which we’re going to talk about actually Starting an open source project.