The wheels of open-source

In 2015 I have published an NPM package “sister”. Sister is an event emitter: you are able to attach event listeners and emit events. If it sounds like a familiar pattern it’s because it is.

In the I have included a list of 200 similar libraries. The package is a satire of course.

This is not good. Everyone’s time could have been spent on something more productive, more valuable.

We can blame poor tools or lack of documentation all we want. But the problem is our inability to plan and lack of community.

Putting the blame on someone

In part, is to blame. npmjs never provided tools for advance search of the packages, a tool to compare packages or documentation versioning, etc There are many things that npmjs could have done to promote collaboration in the community. The good thing is that npmjs does recognize these issues.

Instead, these tools were developed by the community. Today we have for search, for comparing packages, (not specific to JavaScript) Stack Overflow Documentation for community driven software documentation and to discover whats trending. These services enable you to find the right package for the job.

However, it has been a while that these services exist. Nevertheless, the problem persists.

Talking numbers, in October 2014 NPM search for “event emitter” returned ~200 results. Today, it returns an astonishing 1289 packages.

Planning fallacy

There is an elephant in a room that needs to be addressed — it is how we approach problem solving. To continue with the event emitter example, most of the authors written the package because:

  1. There was a problem that required an “event emitter”
  2. Google search for “event emitter javascript” turned up
  3. The thinking goes: I am not familiar with Node.js event emitter.
  4. This is a long document — it is going to take me a lot of time to study it.
  5. This probably does not work in browser.
  6. I need something lightweight.
  7. The API is ugly — emit and addListener . I am used to jQuery’s trigger and on , or [put a framework you are familiar with] API.
  8. I can do it better. After all, my use case is simple.

15 minutes later you have a prototype. 30 minutes later you have came up with a name for the project. 45 minutes — you have it integrated it with travis, coveralls, etc.

You continue to integrate the package with your main project and discover memory leaks, infinite loops, events being sent twice, etc. you continue to write the test cases and cover these use cases.

If you are a scrupulous developer, you took time to write a thorough documentation.

Combined, it took you several hours to get here. Would it have taken you several hours to study the documentation of Probably not.

The difference between inventing a car and inventing a wheel

I enjoyed reading Juozas Kaziukėnas article How to ship side projects. The key takeaway is — to deliver, you need to separate the process of learning (or developing) a tool from delivering the end product.

You can write all of the tools yourself. However, it is going to take you a lot more time. The easiest way to deliver is to learn how to use the existing tools.

I’d like to share an allegory that I use to evaluate whether what I am working on is a good investment of my time.

Inventing a wheel

One morning you came up with a startup idea, e.g. I am going to create a social network that allows people to share fragments of information restricted to 140 characters.

When asked a specific question about how X is going to work, you can improvise an answer, e.g. you can describe how people are going to send the message, how people are going to read the messages, how messages are going to be shared, etc. However, until this idea is in your head, it is only an abstract, blurry, constantly changing thought. Adding the pieces together without forgetting what you are building is hard.

On the other hand, developing individual components of the application is easy, e.g it is easy to create a form that once submitted stores information into a database. This is the reason why software developers end up reinventing the wheel a lot — it makes us feel like we are delivering the product; it gives that instant dopamine reward that keeps us motivated.

This is demonstrated in a vast proliferation of open-source projects that solve the same problem. search for “event emitter” returns 1289 projects.

This goes back to Juozas article about building a side-project. Focus on the idea and use the tools that do not distract you from the main goal of delivering the project.

Writing an event emitter is not the end destination.

The change needs to happen from the top to bottom

As an established open-source community we can improve the collaboration. All you need to do is to invite people.

If you have a well established package and you see that someone is creating an alternative — reach out to the author and talk. Find out what is his reason for creating the package, congratulate him on the effort, collaborate on capturing his requirements, invite him to contribute to your project and assist him to get started.

Here is an email template for you to get started:

Dear {package author name},

What a great job you’ve done with with {package name}! I see you have unique ideas how to solve {problem that your package solves}.

I am the author of {your package name}. I have been working on this project for a long time, focusing on capturing every use case and fixing all the bugs that arise along the way. There is a growing community of contributors who help to maintain the project.

I would like to invite you to become part of the {package name} community. I am happy to help you to understand how to use this project to solve your problem. Furthermore, there are quite a few open issues that we need help with.

If you choose to develop in your own direction, let me know if I can be of assistance. I’d like to share ideas for the benefit of both projects.

Thank you,

{your name}

It takes time, it takes a lot of effort, but this is how you create healthy communities.

Don’t work in isolation. Be inviting.

Tech / Product Founder — building