Four lessons I learned from maintaining a 10k stars project on Github

In 2017 I started a new project with a single goal: learn unit testing. Since then a lot of things happened with react-content-loader (a React skeleton package) and it reached a status that I could have never imagined. It had countless contributions, suggestions and discussions, and most of all I had the opportunity to interact with many awesome developers around the world.

Along that, the open-source community - especially the React one - taught me a couple of lessons that I'd like to share for present or future project maintainers.

The open-source potential

As the source code is available to any person in the world to check it out, different perspectives and opinions are brought up, and that's amazing. I have no idea how many times the codebase itself and the build script were rewritten from scratch, in order to improve legibility, performance and/or compatibility. Also, contributions are not only about coding, but issues with documentation, bug reporting, doubts, and examples are also very important to produce a successful project.

In one of these issues, I realized that sometimes a product needs support to make it more usable. So, I figured out a way to create another new tool which would help the main project; as a result, create-content-loader was born to introduce presets, adding examples from the community, including documentation and third-party tutorials. From that moment on, the main project increased its audience significantly. Consequently, more developers can use and also contribute to the project, creating a sub-community around the project.

Focus on one problem and solve it

As long as the product grows, it's easy to lose sight of the original goal, adding more and more features over the main project. Edge cases, bugs, alternatives and so on, might appear during the development process, but it's essential to keep the scope defined (but not closed) to keep the purpose of the project clear.

Also, try to design APIs as generically as you can. Attempt to solve the big picture of the problem, not all specific cases - that's why it's also important to say no. Sometimes, a small problem may be solved with a workaround instead of delivering more extra code for everybody else.

Keep yourself up-to-date

Once I solved the main problem in my project, I was able to try out so many things, from different builders, testing libraries, frameworks support, to automatization of a few processes. Indeed, my open-source projects are my laboratory, where I'm able to implement, test and deliver improvements, which will be tested for many users and websites. Even when some of these changes introduce new bugs or break the whole project, I know that it's part of the learning path, and the community is there helping you with solutions.

Be welcoming, be kind, be responsible

Regardless if you're a maintainer or a regular contributor of open-source projects, you've probably faced some situations where you don't know how "open" that project really is. As there are a lot of issues, pull requests that are still waiting to be merged, missing documentation or contributing guide, or even a maintainer who doesn't accept any suggestion.

A truly open-source project has its guides, and it's welcome for suggestions and changes. Personally, such behavior and approach in leading a project have made me much better as a developer, thanks to many discussions and change requests. As a consequence, at some point, I realized that the project no longer belonged only to me, but to the community itself as well.

Also, the responsibility comes with this whole pack. Every proposal, every push to the main branch, every new contributor added, needs to be done with certainty that no malicious script or bug is being introduced in the project.

The rewarding part

The benefits of having such a project on a Github profile are undeniable, from solving small problems (like react-content-loader) to big ones. Furthermore, a successful open-source project is the opportunity to show off your hard and soft skills, since managing a project is not only pushing code to branches, but to also organize, prioritize, describe, and plan features and bugs.

Success isn't measured in Github stars but rather in complete user satisfaction. Being honest, I still don't know if I've reached that, but I have no doubts that Ive learnt many lessons so far.

Read more on danilowoz.com