How to grow a popular open-source project?

Story of Rambda - Javascript FP library

by: Deyan Totev

How can you explore the need of remaking a library with less code and the best Ramda methods? Rambda is a more compact and faster alternative to the well-known functional programming library Ramda. In comparison to Ramda's custom design using the same techniques, it is three times smaller. Designed in 2017, the library is now being used by an increasing number of users, reaching 251 000 weekly downloads.

Why building an open-source library?

Before going into how to build a popular open-source library, we need to ask ourselves why we need this in our lives. I asked that myself when I started working on Rambda, but in retrospection, I find that the main reason is to have a stronger insight into why perfect software cannot exist. Also, when building OS projects, it is easier to understand why simple bugfixes are not that simple to be released because every popular OS library should have a rigid system of checks. Another reason for building an OS library is to provide yet another solution to a common problem. While this goes against the "Don't invent the wheel" principle, it creates a competitive environment, which can only help in solving the common problem.

How to build a popular OS library?​

Building an OS library is easy, but if you care about receiving feedback, then you will need to focus on a more popular problem. In other words, your library should be a missing link, a link similar to a bridge that connects two sides that want to meet each other. Then you should check if any of the popular solutions have obvious drawbacks, and if that is the case, if it is possible for you to create a proof-of-concept solution in a reasonable time. For example, 'React.js' solves a problem that most front-end developers face, but building an alternative cannot be done by one person in an imaginable amount of time. After you have your basic version of your library, you should use it to build other projects, as it makes little sense to build something to solve the problems of somebody else. By becoming the most active user of your library, you can also find issues before anyone else.​

The initial idea of Rambda

I liked the idea of using functional programming in front-end projects. At that time, 'Webpack' was the main tool for front-end development. I noticed that the FP library Ramda didn't work well with the tree-shaking feature of 'Webpack', so I thought that I could fill this gap by providing a tree-shakable FP library that takes all the important methods of the Ramda API. This is how Rambda was born in January 2017.

Advertising JS open-source library

Once I had a basic but working library, I focused on making the library more popular.I wanted to allow visitors to easily test it out, so I built a REPL application. Then I started changing the beginning of the README.md file to make it more understandable for first-time visitors.

After I was happy with the documentation, I started applying to various Awesome type of lists (such as Awesome FP JS) in order to create inbound links to the repo. The final part of my marketing plan was to aim for a fast resolution of any new issues. This helps in proving to the users and the Github bot that the project is very much alive.​

One of Rambda's selling points is in using R.compose to generate readable chain of actions:

You can test this example here

You can test the example in Ramba’s REPL application here.

The correct way of moving forward

As Rambda is now an established library, I still need to think about how to improve it further. I want to make it impossible for bad code to be published, i.e. there are sufficient checks before MR approval that prevent slow code or code that fails when used with popular build tools.Also, a new name is appropriate in order to make it easy for people to discuss Rambda. Now, the name is too close to Ramda and that creates confusion among users.

Previous
Previous

Next
Next