"Contribute to open source, it's the best thing that's happened to me!" I hear more and more often on Twitter these days. While I don't object to the statement itself, I feel that it unintentionally (or intentionally) omits a decent chunk of truth about contributing and authoring open source. It sounds like you're recommending a hiking route that, eventually, opens up to an unforgettable view but you fail to mention the number of challenges and the preparation this hike requires. I know there will be people who will take this route and will find themselves overwhelmed, if not unprepared, in the face of what a life of an open source maintainer actually is. As I've created this blog with the purpose to write about things I think people should talk about more often, it's time for me to touch the vast and alluring plane of open source.
Status check
I'm going to write from an open source author's standpoint. Partially, because this is where I have the most experience and can spotlight the issues I've faced myself. But mainly because I believe it's a matter of a single commit when a contributor becomes an author.
There is a significant difference between the contributor's and the author's experience when it comes to open source. Visiting a park on a weekend to do some voluntary maintenance isn't quite the same as being that park's keeper, cutting grass every day, arranging repairs, nurturing, and treating the animals that dwell in the area. It's like living in two different worlds that, eventually, will collide.
I should mention that I have no goal to discourage you from diving into open source and becoming whomever of these two you wish to be. Open source is a great place to learn and make friends—that's what you've been told correctly. It's been my primary way of learning for half a decade now, and it would be foolish for me to prevent you from learning yourself. So, if you're considering landing that first contribution—do that by all means. See you at the end of the article.
Enjoy being undiscovered
I say this without the slightest hints of sarcasm. Enjoy the time when your projects are just that—yours—for that is truly magical. Once they get discovered and picked up, things will change based on the adoption rate, so don't miss out on the fresh air of a new project that nobody knows about.
Here, I'm tempted to say "build something great and people will follow" but that is very far from the truth. It's like making a name in the music industry: it has nothing to do with the genre and quality of music you're writing. It's a matter of getting lucky once, twice, and then a couple of times more. Because it takes a tremendous amount of effort just to convince people to look at what you're building, let alone adopt and contribute to it.
Once again, enjoy being undiscovered. There's a unique touch to playing your songs from your garage, maybe even with a band of friends. Not everyone needs to gather big stadiums or sell platinum records. The life of a famous musician is more than hoarding piles of cash and drinking mega pints of wine. There are challenges and struggles, so enjoy while those aren't on your daily list yet.
If, in the end, you decide to go all-in and seek attention, employ any tools available to you: social marketing, speaking at conferences, joining existing communities, and making friends on the network. The latter was what worked the best for me, and I've got lucky beyond measure to get my work featured multiple times by incredible people in the community. Your journey, however, is yours to make.
You will learn a lot about marketing while promoting your open source work. Well, no wonder. You won't be promoting open source, to be frank, you will be promoting…
It's a product, not a feature
Think about an open source project that associates with "successful" in your mind. Now, what are the chances that this project is:
- Acquihired;
- Owned by a corporation;
- Serving as an entry point to a paid product;
- Won a lottery ticket of getting adequate number of voluntary sponsorships;
- Any combination of the above.
In the JavaScript ecosystem, the chances of that are roughly around 100%. And if it seems you've thought of an exception, then it's surely headed into one of these directions without you knowing.
Open source libraries are products.
It's even customary to brand them, drawing logotypes, designing unique styles, and indulging in other forms of branding of a product. This isn't bad, it's just something that can slip past your passionate eyes, and something I rarely see the authors of those projects mentioning.
Many of such projects are still built by enthusiastic and endlessly creative people but despite that, they are all destined to become a product one way or another.
In addition to that, any enthusiasm needs to be kept alive. And so, in the light of preserving the embers of their inspiration, it's natural that authors seek ways to sustain their projects financially. There's only one catch.
If you look at the list above, not a single point has anything to do with the actual open source work you're doing. The financial stability of authors comes from external sources—often built by themselves in addition to the titanic effort they've already put into their projects.
Money in open source
Anytime I mention "money" and "open source" in a single sentence everybody suddenly gets quiet in the room. For whichever abnormal reason, it's an unspoken taboo to associate what is legally and infinitely free with such a dirty thing as money. I, honestly, don't get this. How can we taboo something that is not there, to begin with?
Certainly, no contributors get into projects with the sole purpose to get a financial gain out of them. Open source has never been about money either. But for you as an author, the lack of funds to sustain your ideas and pay for even a small portion of the time you're spending on them is—I'm not going to lie—devastating. It may not be your concern at first but it will inevitably become one when your ideas gain popularity, demanding significantly more time than there are hours in a day.
That being said, there are unicorn projects that exist with the support of their users. Whether your project will become one of those is a separate discussion. I'd say you have a higher chance of winning multiple lotteries in a row than getting stable financial support out of voluntary sponsorships. The entire open source culture is designed so that there would be no need nor urge to sponsor creators, and there hasn't been a single shift in this direction for decades. Like a still windmill on a windless day, the financial state of open source hangs in the air, unresolved, unsought, stagnating.
That is why about everybody builds a product within or around their open source ideas. I can't say I share this direction but it's certainly the only one that is available to everybody. I do think that product-izing ideas leads to a priority shift, which often ends up in decisions that are best for the product and not for its users. In the end, when it comes to product, it's the revenue that's driving it, and so everybody is stuck in the infinite tug-o-war of attracting the users to their product and their product alone.
Plan your exit
The sooner you begin thinking of your ideas like products, the healthier your open source (and personal) life will become. And with any product, it's worthwhile to consider your exiting options. In the context of open source, those are the options that will keep your product afloat, and your creativity fed.
It's not a coincidence that most of the projects I can think of have a clear maintenance strategy in place. I'm not advocating for you to go and write a SaaS in parallel to your other ideas but if you can, then certainly go ahead. In other cases, consider the future of your project and think about the ways for that future not to become your second job. If I was able to carry at least some of my point across in the previous section, then you'd be able to answer by yourself exactly how well that job will be paid.
To make things somewhat more challenging, not all ideas translate to paid products. You may come up with fantastic tools that won't sell both on their own or as a part of another product, leaving you in a state of limbo. Don't wait for that to happen, devise a sensible maintenance plan for your projects early on, and stick to it.
I would love to recommend specific things or give you a sense of direction to follow when it comes to sustainable open source. But I can't. Not because I want to keep the secrets of the universe from you but because I haven't quite figured this out myself (hi from the limbo! 👋). My projects stagnate, and I'm burning out spending so much of my free time on them. Once I make sense of it, I will write another piece, but for now, the best I can do is to warn you and hope that you will be better prepared that I was.
Establish a healthy balance
Even from the earliest of days when you're building something for fun with no intention or hope that it will ever be discovered by anybody, keep a healthy balance in the time you spend on open source. When your project does get discovered, and people will start demanding more, it'd be too late to think about things like this.
Open source is a vast sea of possibilities, and it's easy to drown in it, watching as hours and weeks fly by, and your ideas gradually take form. It's captivating and, frankly, addicting to do open source but be careful not to sacrifice your personal and family time to that addiction. This may sound silly to you but I know how easy it is to get a light panic attack whenever I see someone reporting an issue on my project. It also gets unnerving to realize that I cannot move as fast with my ideas as I want to simply because there are too many of them. Mental health is not something to joke about, and it's different things that make us happy, sad, nervous, or uplifted. That's where a proper balance and attitude towards open source is crucial.
Honestly, I would recommend just setting a time limit on the open source activities you do during the day. "Okay, it's 5 PM so I have one and a half hours to contribute to open source," that's where a good balance starts. Sure, you may grow to afford more time, but it's the idea of clear activity boundaries that makes it healthy. Don't work in the evenings or nights. Don't forget about your friends and your loved ones. Trust me, they matter more than all the code in the world.
And once you get "big", try keeping things simple. Don't let it get into your head. Don't stress out about silly things. And yes, the code we write, in the end, is just a silly thing. It doesn't make it uninteresting or pointless, but it's just that—bytes in the computer. Funny enough, switching your attitude to a more distant one will also have a positive effect on the work you do. Everybody wins when the creator is healthy.
Closing thoughts
There is no better place to learn engineering than open source. There is also no better place to sacrifice your personal life and mental health than open source. And the way you balance between these two purely depends on you and the culture you establish about your open source work. Make your ideas happen. Help others. And, above all, remember to take a week off of open source once in a while, it will pay off.