6 Proven Guidelines on Open Sourcing From Tumblr
#10: Check This Out - Incredible Open Sourcing Techniques (4 minutes)
Get my system design playbook for FREE on newsletter signup:
Open-source software offers its source code to the public to study or modify.
According to Wikipedia, there are more than 180 thousand open source projects.
This post outlines the open-sourcing guidelines from Tumblr. If you want to learn more, scroll to the bottom and find the references.
Share this post & I'll send you some rewards for the referrals.
You are not interested in open-sourcing a project. But want to design a reliable system using an open-source project? I think this post will help you to choose the right open-source project for system design.
Open Source Guidelines
6 proven guidelines on open sourcing from Tumblr are:
1. Reduce Dependencies
A common reason to create an open-source project is the need for a reusable library.
An open-source project must contain minimal dependencies. Because it reduces bloat and improves portability.
So a best practice to build an open-source project is by creating a separate repository or a module. Because it prevents accidental dependencies.
2. Focus On Quality
The number of bugs must be low. The common techniques to reduce bugs are:
Write tests
Cover all code paths
User testing
Also it is important to gather feedback from architecture and code reviews.
3. Keep a Minimalistic API
The single most important factor that distinguishes a well-designed module from a poorly designed one is the degree to which the module hides its internal data and other implementation details from other modules.
- Joshua Bloch, Effective Java
An existing functionality of the open-source project shouldn't break with newer releases. Put another way, backward compatibility is important. Otherwise it will break projects that rely on it.
A common approach to maintain backward compatibility is through creating a minimalistic API. Because it allows to change the inner implementation without affecting the external interface.
4. Keep the MVP Simple
MVP (Minimum Viable Product) is a product version with enough features. And usable to early customers.
Keep the MVP simple - a low number of features while building the open-source project. But not compromise on the quality.
And release the MVP and build further based on feedback.
5. Grow the Community
An open-source project without a community is like a light bulb without electricity. It will not succeed. And the types of users participating in an open-source project are:
Users who expect things to work out of the box. Because they have no time to fiddle with code
Users who want to build on top of the open-source project
Each user is important. So it is crucial to listen to the community.
6. Must Haves
Other must-haves for an open-source project are:
Good documentation
Demo application
Legal compliance
Security approval
Do you think there are further important guidelines not covered in this post? Leave a comment.
Consider subscribing to get simplified case studies delivered straight to your inbox:
Thank you for supporting this newsletter. Consider sharing this post with your friends and get rewards. Y’all are the best.
Do you want to be a rockstar engineer? Or are you looking for a mentor to level up your career? Techlead Mentor Newsletter by
might be helpful to you. He is a Staff Software Engineer at Meta. And offers great career advice for engineers. Consider subscribing to his newsletter.References
Tumblr Engineering. (2016). The Art of Open Sourcing. Tumblr Engineering Blog.
Alvi, S. (2016, October 20). The Art of Open Sourcing. Medium.
Tumblr. (n.d). PermissMe. GitHub.
https://en.wikipedia.org/wiki/Open-source_software
Thanks! The people who are doing that work... You are our angles! People often complain about Open Source libraries, how they are not maintained properly or having lacking documentation. I say that unless you maintain one library on your own, you have no right to complain :) (and I don't)
Very interesting to start with an "open-source first" mindset instead of trying to move code around later to release to the public something tightly coupled
Definitively this is a checklist for any library that *may* become open-source later.
Thanks for sharing NK!