Open-Source Software starts at Day 1

Tips by the Dailymotion Open-Source Team

Many successful open-source projects have their source code published from the very beginning. This is what we did with Dailymotion’s Tartiflette: the SDL-first GraphQL engine which is powering our internal API. Starting with open-source in mind allowed us to build a community, get early feedback and guarantee a smooth release.

It’s often considered a safer bet to only publish the source code after you’ve reached a stable version. This has been done by many successful open-source projects such as React from Facebook or Atom from GitHub. Doing this can reduce the stress of having every coding mistakes being shown to the entire world. It can also help your team keep control of the direction in which the project is going during the crucial MVP phase. Last but not least, not publishing your work too early help you avoid any negative publicity if you have on pause, or completely cancel development at some point.

Alternatively, being open-source from Day 1 can also benefit your project. While publishing code can be intimidating for some developers, it’s also a big source of motivation for many others. Having early releases of the code can allow you to receive feedback and contributions from the community, for example, the developers of the plugin tartiflette-starlette started working on it long before Tartiflette hit 1.0.0.

In both cases, what’s important is to start thinking about open-source from the first line of code you will write (and probably even before that). If you want your project to succeed and the GitHub stars to start raining, you will need to make your code generic and reusable while also building a strong community around your project.

Build reusable software

The first mission for open-source developers should be to write code that everyone can use. A lot of developers are used to only writing software that will fit their very specific business need, while open-source software needs to be usable outside of your company, by people who might have very different businesses and tech stacks.

This can be achieved by following the Unix philosophy, as summarized by Peter H. Salus:

• Write programs that do one thing and do it well.
• Write programs to work together.
• Write programs to handle text streams, because that is a universal interface.

Let’s take Tartiflette as an illustration of those principles:

• Tartiflette only serves one purpose: it is used to resolve GraphQL queries by providing an SDL-first schema
• Tartiflette is meant to be extensible and work with any other python library
• Tartiflette itself works by parsing raw text, plugins can be used to feed it text from sources like HTTP

Of course, following these principles will be much easier if you have them all in mind from the first day of your project. The good thing is that even if you cancel open-sourcing your code, following this philosophy will help your organization build easier to maintain systems. This will directly translate into saving money for your company. Having to refactor tightly-coupled code into something more flexible when a project is very advanced can easily take a team of developers a few weeks, or even months for larger projects.

Gather a community early

No matter how late you chose to release the source code, the earlier you start communicating about your project, the better. Not unlike commercial software, open-source projects function best with an active community around them. This community will both help improve your project through feedback and contribution while advertising by word of mouth.

Finding early adopters can be tough, that’s why you need to start looking for them right at the start of your project. You can start writing articles and talking about the problems you’re solving long before you have a stable production ready version. Showcasing your results on Product Hunt and Hacker News can also be done even if you don’t feel like your code is good enough to go public. Having work to show can also be a huge motivating factor for the project team. Seeing that other people are using the software you built after months of work is a one of the best form of job recognition. This will lead to major performance improvements for the team.

By the way, are you sure your project should be open-source? Open-source software has many benefits, but it’s not a solution to everything. Before releasing your source code everywhere, take time to think about things like future maintenance, licensing issues, etc.

The essential thing you should retain from this is: open-source software is not just code. If you want to build a successful open-source project, you have to do more than just push your code on GitHub. You need to think about community, maintainability, and re-usability right from the start.

Naturally, you need to keep in mind your company objectives while doing all of this. For example here at Dailymotion, Tartiflette is used internally and has helped us build a faster, easier to maintain and more scalable GraphQL API. If you’re interested, you can start using it or contributing to it, by checking out the code on GitHub!