DEV Community

Cover image for Four lessons I learned from maintaining a 10k stars project on Github
Danilo Woznica
Danilo Woznica

Posted on • Updated on • Originally published at danilowoz.com

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 have happened with react-content-loader (a React skeleton package) and it reached a status that I could never have imagined. It has had countless contributions, suggestions and discussions, and I’ve had the opportunity to interact with many awesome developers around the world.

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

The open-source potential

As the source code is available to any person in the world to check out, different perspectives and opinions come 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.These issues are also very important to build 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, I came up with create-content-loader to introduce presets, add examples from the community, include documentation and third-party tutorials. From that moment on, the main project improved significantly and became much easier to use. Consequently, more developers can use the project and also contribute to it, creating a sub-community around it.

Focus on one problem and solve it

While the product is growing, it's easy to lose sight of the original goal, which makes us add more and more features in the main project. Edge cases, bugs, alternatives, among others, might come up during the development process, so it's essential to keep the scope defined (but not closed) to keep the purpose of the project clear.

Also, you should try to design APIs as generically as you can. You should try to solve the biggest part 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 being solved by publishing 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 so many things such as different builders, testing libraries, framework support and automatization of a few processes. Indeed, my open-source projects are my lab, where I'm able to implement, test and publish improvements which can be tested by 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 process, and the community is there helping 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. There are a lot of concerns, such as 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 welcomes suggestions and changes. Personally, I feel like 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 to me, but to the entire community as well.

Also, you need to be responsible. Every proposal, every push to the main branch and every new contributor added need 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. Besides, a successful open-source project is the opportunity to show your hard and soft skills, since managing a project is not only pushing code to branches, but also organizing, prioritizing, describing, and planning features and bugs.

Success isn't measured in Github stars but rather in complete user satisfaction. To be honest, I still don't know if I've reached that, but I have no doubt that I’ve learned many lessons so far.

Read more on danilowoz.com

Oldest comments (8)

Collapse
 
liyasthomas profile image
Liyas Thomas

I’ve learnt many lessons so far.

I feel you. I firmly believe open source is the future of software industry. And projects like yours are an example of how relevant it can be.
I would like to quote a paragraph from one of my articles:

The number of stars of a GitHub project is yet another indicator, because it means people are adding the project to their list of favorites.

Milestones like this are proud moments for the developers & community, help motivate more work & new developments.

Wishing you and all community members a happy life 💚

Collapse
 
danilowoz profile image
Danilo Woznica • Edited

Really awesome, thank Liyas for leaving your post here.

May I ask you a question?
How were you able to achieve such amount of stars? Is there any plan you follow or a goal you've set?

Collapse
 
liyasthomas profile image
Liyas Thomas

Well, they came organically. Mostly from the articles I wrote here at Dev.

Collapse
 
oguimbal profile image
Olivier Guimbal • Edited

Quite a nice lib :)

I however would like to point out the fact that you might be a bit victim of the survival bias.

The reality is that it is really hard to get a library known (there is a LOT of non deterministic things that make a lib popular, I've encountered plenty of wonderfull libs that are almost unknown, i should know, i'm trying to promote one ).

I would also mention that however nice most of the people are, there always are some which are kind of being arses: you'll see plenty of comments like "meh, this is useless, I can do the same thing using X and Y" (why do they care, then ? I do not know). These people are IMO a bit toxic, and their comments can sometimes be hurtful and discourageing when your lib is not big enought so you dont yet have the rewards you've mentioned.

So working on new opensource libs can also be a danger to your mental health, beware not to take things personally !

Collapse
 
danilowoz profile image
Danilo Woznica • Edited

I agree, there are a lot of guys out there who instead of encouraging to release and trying out a new open-source project, would rather put you down.

But I would say, it's a good sign when people waste their time talking about this shit, like "meh, this is useless, I can do the same thing using X and Y" ; because as I could see, they don't have a similar project, they can't do the same using X or Y, they just want to discourage, because they would like to do the project instead.

In fact, I usually suggest to my friends to release open-source project regardless if it's a "copy" of an existing one, or it's just solving a small problem. The rewarding parts might come even if there are no stars at all in your project.

As I said, the measure of a successful project is not only stars but also how you feel about that.

Collapse
 
oguimbal profile image
Olivier Guimbal • Edited

Totally agree. Go tell Evan You that he shouldnt have started Vuejs because Angular or React was already a thing... I'm pretty sure he faced that same critique back then.

It is nonetheless not pleasant to read. So you just have to be prepared to face:

  • A substential amount of potentially soul destroy critiscism (even though you're working for free)
  • A somewhat dehumanized ROI (very few people actually say "thanks")
  • A non negligible amount of work in order to communicate around your project (or have luck to see it go viral)

But yes, apart from that, if you're not misplacing your hopes in seeing your hard work becoming the next React, working on OS is very cool. You just have to be aware that there is little relationship between quality of your work and stars.

ps: thanks for your ⭐😏

Collapse
 
ikirker profile image
Ian Kirker

they just want to discourage, because they would like to do the project instead.

"The imaginary package I have half-designed in my head is so much more elegant than yours."
-- someone who doesn't actually need to solve this problem

Collapse
 
kataras profile image
Gerasimos (Makis) Maropoulos

I couldn't agree more, I have developed a 20k star project too (github.com/kataras/iris) and I've learnt so much in that wonderful path...large open-source projects are hard to maintain though - it's not only the code part, it's the support that we have to provide to our users (very important) and financially speaking, it doesn't worth it. However, popular open-source projects gives you the recognizability you need to accept pretty decent job offers.