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'll be sharing my perspective as an advocate of open source. Partly because it's the realm where I have the most experience and can shed light on the challenges I've personally encountered. However, my main motive is to emphasize that transitioning from a contributor to an author can be as simple as a single commit.
There's a notable distinction between the experiences of a contributor and an author in the open source realm. Contributing to a park's maintenance as a volunteer on weekends hardly compares to being the park's dedicated caretaker, responsible for daily tasks like mowing the grass, arranging repairs, and nurturing the resident animals. It's like inhabiting two different worlds that inevitably overlap.
I want to clarify that my intention is not to dissuade you from exploring open source and deciding which role suits you best. Open source offers a wonderful opportunity for learning and building connections—this is accurate advice you've received. It has been my primary avenue for learning for the past five years, and it would be remiss of me to discourage your own learning journey. So, if you're contemplating making that initial contribution—by all means, go for it. I'll meet you again at the end of this article.
Enjoy being undiscovered
I genuinely mean this without any hint of sarcasm. Treasure the time when your projects are solely yours, for it holds a truly enchanting quality. Once they are discovered and gain traction, things will change based on the rate of adoption. So, don't overlook the refreshing air surrounding a new project that remains unknown to others.
At this point, I'm tempted to say, 'Build something remarkable, and people will follow.' However, that notion is far from the truth. It's akin to making a name in the music industry—it has nothing to do with the genre or quality of your music. Rather, it boils down to a series of fortunate encounters, repeatedly. Convincing people to take notice of what you're creating requires an immense amount of effort, let alone persuading them to adopt and contribute to it.
Once again, relish the experience of being undiscovered. There's a unique charm in playing your songs from your garage, perhaps even with a band of friends. Not everyone needs to fill large stadiums or sell platinum records. The life of a famous musician entails more than amassing wealth and consuming copious amounts of wine. It involves challenges and struggles. So, appreciate the absence of those on your daily list, for now.
If, in the end, you choose to go all-in and seek attention, utilize any available tools at your disposal: social marketing, speaking at conferences, joining existing communities, and building connections online. Personally, the latter approach has worked best for me, and I've had the incredible fortune of having my work featured multiple times by remarkable individuals in the community. However, your journey is entirely yours to forge.
Promoting your open-source work will teach you a great deal about marketing. It's not surprising, really. In all honesty, you won't be promoting open source per se; instead, you'll 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.
Enthusiasm is great but it makes for a poor dinner.
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
Whenever I bring up the topics of "money" and "open source" together, a sudden hush falls over the room. It's as if there's an unspoken taboo surrounding the association of something that is legally and infinitely free with the notion of money, often considered a dirty subject. Frankly, I find this puzzling. How can we attach a taboo to something that doesn't inherently exist in the first place?
Because there's no money in open source.
Undoubtedly, contributors don't engage in projects with the sole intention of financial gain. Open source has never revolved around money either. However, as an author, the absence of funds to sustain your ideas and compensate for the significant time you invest in them can be, to be honest, devastating. While it may not be an immediate concern, it inevitably becomes one as your ideas gain popularity, demanding far more time than the hours available in a day.
With that said, there are rare unicorn projects that receive support from their users. Whether your project will become one of those is a separate discussion. I would say that your chances of winning multiple lotteries in a row are higher than attaining stable financial support through voluntary sponsorships. The entire open source culture is structured in a way that eliminates the need or desire to sponsor creators, and this approach has remained unchanged for decades. Like a windmill standing still on a windless day, the financial aspect of open source remains unresolved, unexplored, and stagnant.
Consequently, nearly everyone builds a product based on or around their open source ideas. I can't personally say that I align with this direction, but it is certainly the only viable option available to all. However, I believe that transforming ideas into products often leads to a shift in priorities, resulting in decisions that prioritize the product itself rather than its users. Ultimately, in the realm of products, it is revenue that drives the decision-making process, trapping everyone in an endless tug-of-war to attract users exclusively to their own product.
Plan your exit
The sooner you start viewing your ideas as products, the more balanced your open source (and personal) life will become. And like any product, it's important to consider your exit options. In the context of open source, these options are what will keep your product sustainable and nurture your creativity.
It's not a coincidence that most of the projects I can think of have a clear maintenance strategy in place. I'm not suggesting that you go and create a SaaS (Software-as-a-Service) alongside your other ideas, but if you have the capability, then by all means, go ahead. In other situations, contemplate the future of your project and explore ways to prevent it from becoming your second job. If I managed to convey my point in the previous section, you should be able to determine for yourself how well that job will be compensated.
To add a level of complexity, not all ideas can be monetized as paid products. You may develop exceptional tools that don't sell well either individually or as part of another product, leaving you in a state of uncertainty. Don't wait for that situation to arise; establish a sensible maintenance plan for your projects early on and stick to it.
I would love to offer specific recommendations or provide a sense of direction for sustainable open source. However, I cannot do so—not because I want to withhold the universe's secrets from you, but because I haven't fully figured it out myself (greetings from the limbo! 👋). My projects are stagnant, and I'm experiencing burnout from investing so much of my free time into them. Once I gain clarity, I will write another piece. For now, the best I can do is caution you and hope that you will be better prepared than I was.
Establish a healthy balance
Even from the earliest stages, when you're building something for the joy of it, without any expectations or hopes of it being discovered by others, it's important to maintain a healthy balance in the time you dedicate to open source. When your project eventually gains attention and people start demanding more, it will be too late to consider these matters.
Open source is like a vast ocean of possibilities, and it's easy to become engulfed in it, losing track of hours and weeks as your ideas gradually take shape. It's captivating and, honestly, addicting to engage in open source activities, but it's crucial not to sacrifice your personal time and neglect your family due to this addiction. It may sound trivial, but I understand how easily one can experience a slight panic upon seeing someone reporting an issue with their project. It can be unsettling to realize that you can't progress as quickly as you desire with your ideas simply because there are too many of them. Mental health is a serious matter, and various factors contribute to our happiness, sadness, nervousness, or upliftment. This is where maintaining a proper balance and adopting the right attitude towards open source becomes essential.
Honestly, I would suggest setting a time limit for your open source activities during the day. For instance, saying to yourself, "Okay, it's 5 PM, and I have an hour and a half to dedicate to open source." This is where a healthy balance begins. Certainly, as you progress, you might be able to allocate more time, but the concept of setting clear boundaries for your activities promotes a healthy approach. Avoid working in the evenings or at night. Don't forget about your friends and loved ones. Believe me, they matter more than any code in the world.
And once you achieve a certain level of success, try to keep things simple. Don't let it get to your head. Avoid stressing over trivial matters. Yes, the code we write is important, but in the end, it's just a collection of bytes on a computer. Interestingly, adopting a more detached attitude can also have a positive impact on your work. It's a win-win situation when the creator is in good health.
Closing thoughts
Open source is an unparalleled learning environment for engineering. However, it's also a realm where sacrificing your personal life and mental well-being can easily occur. The key to balancing these aspects lies entirely in your hands and the culture you cultivate around your open source work. Bring your ideas to life, assist others, and most importantly, don't forget to take occasional breaks from open source. It will ultimately yield benefits in the long run.