Lessons learned doing open source
An introspection on my OSS work
Build good looking demos
It’s fine to be inconsistent
I used to beat myself for being inconsistent. Not anymore. Github is my lab, not my job. I make sure to have a stable, working version on master and move on. I come back once motivation strikes again. I play it long term.
Build framework-agnostic libraries
Write framework-specific recipes
Whether you do backend, frontend, ML, or whatever, chances are your users are using frameworks. Write easy-to-follow recipes for how to plug your library into any of these abstractions. It’ll boost adoption.
Have a clear scope
Devs complain about clients asking too much yet we do the same on Github. You’ll get a myriad of feature requests if your OSS project takes off. Communicate your scope. Learn to oblige. Learn to decline.
I’m not a marketer so launching is always a gamble. What I’ve learned, though, is you must relaunch. People might have not seen your stuff the first time. Release a new version and write a blog post. Tweet about it.
Sneak in to understand usage
Use the Github’s Dependency Graph to see who’s using your packages (lots of supported ecosystems). Then visit your users’ repos and analyze usage. Are they hacking it to fix a hidden bug? can you improve the API?
Use badges but don’t oversell
Scientific research has shown that badges are positive signals for contributors and users. Adding a badge doesn’t change popularity but popular projects are more likely to have badges. Use assessment badges.
Use a GIF
You have just a few seconds to convince users to try your library. Put a GIF at the top of your README to help them quickly jump in. You can use terminal screencasts, GIF recordings or screenshot sequences.
Yes, build it again
Unless you’re a seasoned OSS developer, you need to build yet another version of popular things. This will ignite your curiosity to try bolder things later. Don’t try to code the next big thing. Just build something. Today.
I have unpopular projects with little to no installs. I’m proud of them, though. I learned a lot from building them. I use them myself. I’m getting better and enjoying my projects. That’s my ultimate bar for success.
Be aware of moniker naming rules
This is a personal journal for things that have worked in my open source work. I’ll keep updating this as I come up with new findings.
Do you have any advice to build good OSS projects? Let me know!
Join the newsletter
I write about remote work, software and personal growth. Subscribe to enjoy my articles every once in a while.