Meet Valérian Saliou, an Active Open-Source Maintainer
Valérian Saliou is the CTO at Crisp, a customer-support platform for small and medium-sized companies, where he manages everything from the servers to building apps. He is also the maintainer of about 50 open-source repositories, including Jappix, a XMPP web client that reached 100,000 users, and Sonic, a search back-end that, at the time of writing, has received more than 6,600 stars on GitHub. Here, he explains how he goes about creating and maintaining successful open-source projects.
When did you start creating and maintaining open-source projects?
Thanks to open source, I actually started coding when I was 16. My first project was a chat application called Jappix. I had almost 100,000 users, including at one point, the CNRS [the French National Center for Scientific Research] and CERN [the European Organization for Nuclear Research]. That’s how I fell in love with open source! In the beginning it was also a way of getting hired, as I was able to show that I could produce quality code. Open source was my online résumé, and it has so far got me multiple job offers and several freelance positions.
How many open-source repositories are you currently maintaining on GitHub?
About 50! Most of them are libraries we use for Crisp. The biggest one is Sonic, a search back-end that has more than 18 contributors and more than 6,600 stars on GitHub. I receive several contributions every day for this repository. A lot of people actually send pull requests to add new languages to the search system.
But Jappix is still one of my favorites. I spent almost two years building it, and not only did it get me involved in open source, it helped me familiarize myself with chat apps, which taught me all I needed to know to build Crisp.
What do you like about creating open-source libraries?
I like building tools on my own because I always learn a lot of stuff and it makes me feel like I’ve achieved more than if I had just used an external service. I also like it when companies use my tools. For instance, I know that the library node-fast-ratelimit, which I built for Crisp 3 years ago, has been used at some point by the French company Doctrine.
Open source is also a way for start-ups to get the tools they need for innovation. For example, they can use MySQL to store their data rather than Oracle, which is super-expensive and often out of people’s reach, and I like being part of that.
Finally, it’s also a way to share useful code, even if a project fails. For example, I worked on a social network for developers called Waaave. I was building the back-end while a friend of mine was coding the front-end. It didn’t work out but I open-sourced the code in Python, which had been built on the Django framework, because it provided a lot of good examples of code for other developers.
How do you manage to dedicate time to both your full-time job and your open-source projects?
My first job was at a service company, so I had time during the day to take care of my open-source libraries. But now I use weekends to work on my open-source projects that are not directly related to Crisp. They’re better than evenings because you can start fresh! I don’t have a precise schedule, I just work when I feel like it. It’s a passion.
Having said that, you also need to organize yourself to be as efficient as possible in a limited time. For 50% of the time, I write a lot of code, and then I spend the rest of the time debugging, testing at scale, and finalizing the readme. For example, with Sonic, it took one month of work to get a 1.0 functional version and another to get something perfect.
My advice to people who don’t have time to maintain a project is to share your work anyway, because people can fork it and fix what needs to be fixed.
What’s your advice if you want to attract contributors to an open-source project?
Tell the world about your repository by sharing it! With Sonic, for example, my cofounder at Crisp, Baptiste Jamin, published the GitHub page on Reddit in the /rust section. It generated a lot of discussion about the kind of license people should choose for open-source projects. Not all the comments were positive, but sharing it still attracted worthwhile contributions.
In addition, you should use the readme to promote your library. It should include a clear introduction, a quick start, a demonstration, the benefits and limitations of the tool, and an explanation of how to contribute. Describing the benefits will show the value of your tool and that you are serious about it. Don’t hesitate to perform some benchmarking to measure the reaction to your benefits. You need to collect proof. And don’t forget to mention the limitations as well! You will always have some—even a well-known tool like MongoDB has some huge limitations. If you only show the shiny part, you can be sure that people will complain at a later stage.
Also, make sure your project is super-easy to install and integrate. It shouldn’t take more than 5 minutes. And finally, comment on your code. Make it clear and don’t build obscure code just because it makes you feel smart.
What’s your advice for retaining contributors?
Be nice to people and stay open to discussion. A mistake I made on my first project was being very assertive.
Also, try to communicate clearly about where you need contributions. On Sonic, for example, I made it very clear which languages I needed contributions for, so I only built the Node.js library and the community built the libraries for other languages such as PHP, Elixir, Python, Rust…
And don’t forget to recognize contributors! Tag them in your readme. It may sound obvious but it doesn’t always happen.
This article is part of Behind the Code, the media for developers, by developers. Discover more articles and videos by visiting Behind the Code!
Want to contribute? Get published!
Follow us on Twitter to stay tuned!
Illustrations by WTTJ
- Add to favorites
- Share on Twitter
- Share on Facebook
- Share on LinkedIn