February 7, 2018
If you have every written an open source library of any significant size, you know there is so much more than simply publishing your brilliant code to Github and expecting people to use it. You’ll also quickly find out why some call open source maintenance a full time job. Once you’ve done this a few times, you start to understand a lot more about yourself and how you might apply the things you learn during this process to running a tech startup. So what does it take to build a successful open source library?
As a passionate user in the open-source world, I am evaluating and using open source projects and solutions literally every day. I see so many of them so often that I can now quickly and easily spot the trends, warning signs and promising characteristics just by looking through a library’s documentation, source code, and issues. This skill becomes indispensable when addressing the pain that other developers might be feeling. How much does this problem hurt? Is this pain wide spread? How many other libraries are attempting to solve this problem? The only way to know this is to be well versed in the open source marketplace. So naturally, as a frequent customer and explorer of my market, I am better fit to identify solvable problems in it.
With all of this noise, it’s a very real challenge to identify if a problem is worth solving or not and if the solution I have in mind will be accepted by those in the community. I know too well how easy it is to assume everything should be magically turned into an open source library, but knowing when to pursue an idea or when to pass is easily half the battle. To help in this quest, I always self-prescribe this advice:
Implementation. It’s very hard, which is what makes it insanely fun, at least for me! Actually realizing my idea into something tangible and usable is both exciting and intense and can sometimes require a lot of architecture decisions, rewrites, and time. I think its commonly known by software developers alike that its normal to multiply a delivery expectation by 3, then do it again! Technology is hard, and no one said that writing an open source library was any easier. There are universal concerns I have learned to consider like design, user experience, cost, flexibility, durability, use cases, maintenance, appearance, etc. After all, this is a developer product. These are just a few things among many that make any product great, including open source software.
Integration is also key to fitting your library snuggly into it’s correct place in the open source world. I am always making decisions on what framework I will support (if any), and the level of abstraction my libraries will provide to my users. If I plan on a library being an integral piece of my users software stack, I always make the best effort to have it play nice with the other technology they actively use and care about.
The existence of a great product is not enough for it to be a success.
Any library you may set out to build needs to be persuasive, attractive, and easy. Here are some things I consider for myself when marketing a library:
Congratulations! You made it! You’ve built and released your open source library and you’re proud of it! It has amazing docs, a great logo, it’s lean and scrappy and already making the world a better place!
Until it’s not…
Maybe you forgot a semi-colon or didn’t cover an edge case. Maybe you zoned out during that security presentation at your last meetup or didn’t make some part of your solution 100% customizable to someone’s liking. Whatever it is, you’re going to have problems, and your users are quickly going let you know about it. Usually the feedback you get is polite and nice (considering that using open source is \$FREE.99), but the world is not a perfect place, and neither are developers.
The more your library grows in popularity, the more support you’re going to need for it. You might even petition the help of some of your most passionate early adopters to help you out. Either way, the inevitable and sometimes difficult interactions you’ll have with some of your users are going to test your patience and demeanor. If there is any point during your open source journey where you will question why you even started in the first place, it’s going to be during times of support. Patching endless bugs, writing boring migration guides, doing damage control, and appeasing disgruntled users are things that not nearly as exciting or as fun as trail blazing with cutting-edge, innovative code. It’s probably not what you envisioned in the beginning, but these seemingly boring and tedious actions rightfully comprise a large portion of the “non-sexy fundamentals” that will ensure the long term viability of your library by keeping your users coming back for more. If you can succeed here, you will be rewarded with a good brand that is truly loyal to its product and users.
Eventually and hopefully, things might settle down and you may even briefly bask in the sunlight of your hard work and efforts. You can feel good about yourself with the Github stars and uplifting feedback you’ll hear from your users. People might even begin to ask if your library could do more for them. They may request new features from your library that could help them tackle related (or sometimes new) problems. This is a great sign! It means you have succeeded! You have built a library that helps people in their daily lives to be more efficient and happier with their job. But it’s still up to you to know where to go next. Will you expand the features of your existing library? Will you build another? If you do, who will take care of this one?
If you haven’t caught on already to my very obvious foreshadowing, I’ll tell you now that building and maintaining an open source library is so very similar to running a technology startup. The challenges and rewards involved in this recipe are almost identical in nature, with only a few changes to the ingredients and the return on investment.
In both scenarios:
The core differences:
In the end, the skills needed to build both an open source library and a technology startup don’t seem all that different. The former may be a microcosm of the latter, but it can definitely teach us a lot about ourselves and how we may handle running a tech startup.
So, go try it! There are new libraries being built ever day by people just like you. More than likely you offer a unique perspective to the problems you experience every day and can use that perspective to both practice these skills, learn more about yourself, and make the world a better place.
Just be aware of the risks. Entrepreneurship is highly addictive 😉.
If you like to use or build open source software, let’s be friends! I’ve written and maintained libraries like
chart.js, all while co-running a startup called Nozzle. I would be more than happy to chat and help you in your own open source endeavors. Good luck!