2024-04-20 08:00:00
[[toc]]
It's not a secret that open-source projects are now a critical part of almost every software project. While most open-source projects are maintained by volunteers, the sustainability of these projects becomes a big concern. The recent xz/liblzma vulnerability accident is a great example that shows the importance of open-source projects and how severe the problem could be.
There are multiple ways to support open-source projects (another excellent article by Rob Mensching, highly recommended). Funding is indeed one of its essential aspects. I believe most open-source maintainers are not doing it for money. However, maintainers still need to pay their bills to make a living and spend time maintaining the projects. Unrewarded free work is not sustainable in the long run.
We are glad to see that more and more companies and individuals started to see the importance of open-source sustainability and have started to sponsor open-source projects. We also see that some companies have started to hire or support maintainers to work on open-sources projects full-time (for example, thanks {NuxtLabs} for having the Nuxt core team and me 💚. {Astro} {Stackblitz} {Netlify} {Vercel} and other companies are also doing it). We, as the maintainers, genuinely appreciate all that support.
However, today, it's still extremely hard for maintainers to figure out ways to get the minimal funds to work on open-source projects full-time, not even asking for returns that match the value they are providing. There are many aspects of open-source funding that need to be improved. In this post, I'd like to bring up some problems we have observed and propose solutions to improve the situation.
In open-source, there are different types of projects.
Some projects are more "front-facing" and are directly interacted with by developers and users on a daily basis. These projects often have short and loud names, well-designed logos, and a large community discussing them or even holding events around them.
On the other hand, there are also "underlying" dependencies that are used extensively but may not be as visible. The majority of the users may not even be aware that they are indirectly depending on them.
Whether a project is "front-facing" or "underlying", both types of projects are crucial to the ecosystem and deserve support. What they have in common is that they rely on people who invest their time and effort into maintaining these projects.
Among all the contributors and maintainers, there is a mix of individuals who have different working styles and levels of visibility. Some are more "high-profile" and actively share their work, while others prefer to stay low-profile and focus on their contributions behind the scenes. The different working styles should not diminish the value of their work.
Naturely, front-facing projects and high-profile maintainers are much more likely to receive attention and sponsorships, while the underlying dependencies and low-profile maintainers are often overlooked. To illustrate this, let me present you this famous xkcd comic again:
Imagine, with that critical dependency being removed, here we have a falling apart version by Adam Leventhal:
When you find a tool that has been helpful to you and you want to show your support, it's natural to look for a way to sponsor the tool or its maintainers. We greatly appreciate this kind of support. The problem of the unsupported dependencies is not usually the sponsor's responsibility.
However, it's important to recognize that when we develop a "front-facing" tool or framework, we often rely on other tools and dependencies to make our work possible. It wouldn't be fair for the "front-facing" projects to take all the credit. In reality, even those "front-facing" projects are often underfunded. That's why we are grateful to see many open-source projects forwarding sponsorships to supporting their dependencies.
For example, {ESLint} is forwarding sponsorships to its contributors and dependencies, {Astro} is giving funds to the ecosystem, projects that I am participating like {Vite|https://opencollective.com/vite/expenses} and {Elk|https://opencollective.com/elk/expenses?collectiveSlug=elk&type=INVOICE} are also started following similar approaches on their Open Collective. Many other projects are doing it as well.
{@nzakas|Nicholas C. Zakas}, the creator of ESLint, also wrote a great article Sponsoring dependencies: The next step in open source sustainability, explaining the importance of this.
I am honestly super lucky to have the opportunity to work on numerous front-facing projects and be a relatively high-profile maintainer in the community and on social media. I am extremely grateful for all the sponsorships I have received. As I mentioned in another post, I have received tremendous help from the community and contributors in creating the tools that you are using. I firmly believe that I shouldn't take all the credit and appreciation from sponsors alone. That's why I wrote this blog post - to find a way to give back to the ecosystem with the resources and influence I have.
I am already sponsoring a number of maintainers who I benefit a lot from. {GitHub Sponsors|https://github.com/sponsors} is a great platform. It covers the transaction fees, and provides great connections with sponsors, maintainers, and projects, making the discovery and sponsorship process smooth. However, while it is great for individual sponsors, it lacks the ability to forward sponsorships to other projects or maintainers. {@patak-dev} raised this feature request for GitHub two years ago, which is currently the top-upvoted request from the community, but unfortunately, it has not been resolved yet.
Here, let's do some simple math to see why this feature is essential:
For example, the tax I have to pay here in France is roughly 41%. Assume both maintainers have the same tax rate. This means that when forwarding sponsorship on GitHub Sponsors, the second maintainer will only receive
of the original amount, plus two months of delay in between (on top of the case that GitHub already covers the transaction fees). Sometimes, we even have circular sponsorships because we both want to show appreciation to the others. Ultimately, this is a significant loss, especially when there is not enough funding for open source already (it's also worth mentioning that GitHub Sponsors is not yet available in all countries).
Despite GitHub Sponsors limitations, a lot of maintainers are still forwarding part of their funds to others ({@danielroe|Danielroe's Sponsoring|https://github.com/danielroe?tab=sponsoring}, {@patak-dev|Matias' Sponsoring|https://github.com/patak-dev?tab=sponsoring}, {@kazupon|Kazupon's Sponsoring|https://github.com/kazupon?tab=sponsoring} and many more). While we really wanted to support more dependencies and maintainers, the current situation on GitHub is not very feasible in the long run.
Another popular platform for open-source projects to receive sponsorships is Open Collective. It provides great transparency on how funds are collected and spent.
For open-source projects, Open Source Collective is a commonly used fiscal host on Open Collective. It charges a total of 10% transaction and hosting fees upfront. The important part is that it allows funds to be forwarded to other projects on the same fiscal host with no additional fees. This makes it a much better fit for the sponsorship forwarding use case.
So, I came up with the idea of creating my personal collective: {Anthony Fu Collective}
Where you can sponsor my work across the ecosystem, including but not limited to:
{Vite} {Vue} {Nuxt} {Vitest} {VueUse} {UnoCSS} {Slidev} {Elk} {Shiki} {TwoSlash} {ESLint Stylistic}
The main difference is that I won't take the funds for myself;
(except for occasional expense reimbursements like hosting or domain renewal)
All the funds will be redistributed to the dependencies and contributors. Each month, I will select a few dependencies and contributors to forward the funds. Depending on the amount raised, I may also set up recurring sponsorships for high-impact dependencies in the future. You give the trust and support to me, and I will make sure the funds are well spent.
To allow differentiating easily, I will treat the funds on GitHub Sponsors and Open Collective differently:
I would generally recommend sponsoring on Open Collective first to support the entire ecosystem and open source. Well, I'd also be grateful if you could sponsor on both platforms :P
Recurring sponsorships are highly appreciated. They help provide a more consistent monthly income and contribute to long-term sustainability for the projects and maintainers.
This collective is my approach trying to see how I can help the ecosystem with the resources and knowledge I have. It also serves as an initiative to encourage more maintainers and projects to follow, by forwarding the support they receive to the dependencies and contributors they benefit from.
Since this involves money and trust, I think transparency is crucial here. I will try to answer honestly some questions you might have below. Feel free to raise more questions if you have any other concerns, I will try to update this post with my responses accordingly.
As I explained throughout this post, my intention is to contribute to the open-source ecosystem and make it better with my little efforts.
To be completely honest and transparent, yes, I couldn't say I am not doing this 100% selflessly. Despite the fact that I am not taking funds for myself, I might still indirectly benefit from this initiative.
I do undeniably have vanity and ego due to my human nature, and I am not ashamed to admit it. I do care about my reputation and influence to some extent. I see this endeavor as similar to contributing to open source. Does everyone do open source completely selflessly? I doubt that. But does that mean everyone is doing it solely for their own benefit? I don't believe that either. The beauty of open source lies in its non-zero-sum nature, where maintainers can derive benefits such as a sense of accomplishment, skill improvement, recognition, and reputation, while providing value to benefit the entire world.
Being part of the open-source community who also relies on it, I certainly have the incentive to help the community become better and more sustainable. I am not a materialistic person, and the sponsorships I have received are not huge, but they are enough for me to make a basic living. While I do believe there are other projects and maintainers who would benefit more from the funds at this time.
Ultimately, my goal is to increase the overall funding into the open-source ecosystem and develop robust systems to support projects, so that everyone can reap the benefits of open source and acknowledge the hard work put in by its contributors.
Regrettably, I don't think it's possible to design a "perfect algorithm" to "score" and distribute the funds fairly. Representing a project, a person, or their work with a single number to rank is unrealistic.
When it comes to equality and equity, I believe it's important to prioritize supporting underrepresented and underfunded projects and maintainers. This would involve subjective judgment, and while I can't guarantee complete fairness, I will strive to be transparent and sincere. I will actively engage with the community and openly communicate how and why the funds are distributed.
As mentioned above, there is no absolute way to distribute the funds fairly. In this case, it's based on my judgment and the trust you give me. As the starting point of this initiative, I believe it's easier and simpler to start with a personal collective and adjust based on the feedback and results. Meanwhile, a personal collective not bound to a specific project could be more flexible and better support the goals of this initiative.
This is certainly not going to be the only collective that forwards sponsorships. Maybe in the future, sponsoring multiple individuals collectively and group collectives would help make the distribution less opinionated and less biased.
For a related example, inspired by this tweet, we recently started an organization with several maintainers to improve the performance and quality across JavaScript packages. Later, we might set up a collective for this organization so you can sponsor the efforts on performance improvements. Stay tuned for a future announcement.
There are quite a few other platforms for open-source funding that also bring exciting solutions to this problem.
This collective is only one more idea, an attempt to help our ecosystem become more sustainable - feel free to explore other platforms and initiatives you think are making sense. The main difference between this collective and the others is that it has me working behind it, instead of just metrics and algorithms. The human factor also made it possible to reduce sponsorships waterflow, where on some platforms the sub-dependencies are harder to get enough funds. With this collective, I can reach the critical dependencies and contributors directly to support them. I will spend time doing the research and communications every month to find important dependencies to support.
This initiative is something I couldn't do alone. I would need your support to make it happen.
If I have convinced you this initiative is meaningful, use the buttons below to help me support the open-source ecosystem and make it more sustainable. Thank you!
I am eager to hear your feedback on this initiative. If you have any thoughts, concerns, or suggestions, please feel free to reach out to leave me a comment under this tweet or this toot. You can also mail me at [email protected].
Thank you for reading this long post. I hope we can take this initiative as a small step and make open-source better and more sustainable together. 💚
2024-04-06 00:00:00
2024-03-22 16:00:00
Made with
Slidev - presentation slides for developers.
2024-03-16 20:00:00
[[toc]]
TL;DR: I am doing great and not going anywhere. Having some pressure but still holding up and trying to improve. Thank you and don't worry!
This is the 4th year since I have started doing Open Source. To be completely honest, I began to feel things were getting out of my capacity more and more often. I am still not sure if I have ever been through actual burnout or not, but I surely have experienced the ups and downs of my productivity and motivation periodically.
This post is not a guide, or not even complaining. It's more like my personal diary, which I serve as a record for myself. I just think it might be interesting if I could share those with you.
If you are been through a burnout or feeling close to it, I'd recommend you to take some breaks, talk to someone, and seek professional help if needed. Here is also a nice article Maintaining Balance for Open Source Maintainers that you could reference. Take great care!
And so here, let me tell you some random stuff I have been thinking about recently
In a way, Open Source is still very new to me, even today.
Since I started to learn programming and knowing about open source, I have been dreaming about being a full-time open source developer. When I was in college, I was eager to get recognized by the open source community, trying hard to "figure out" some impactful work that I could accomplish. All of a sudden, you will reach a pivotal point, where your project might unexpectedly take off, or you have been invited to join a big project - in a moment, you will start to feel all those excitements as well as the responsibilities suddenly come along. In a few days, when the initial excitement starts to fade away, you start to realize that it also means so much responsibility and other things that you have never thought about. Despite that I have been trying all my college years to get into open source, when I finally stepped into it, I realized how much I was unprepared.
One interesting thing about Open Source is that one is probably never prepared. You might encounter tricky technical problems, or have to keep up with the new technologies, but there are also a bunch of things other than coding that you have to deal with. You have to be your customer support to answer questions; be a designer, a writer to prepare nice documentation; a project manager to keep the project on track; a team leader to onboard new contributors and keep the team motivated; marketing your stuff; speaking at conferences; and so on. Those are the "side-effects" of being an open source developer, many things come to you in a bundle, not only the code.
For me, it's so much a challenge. I am quite introverted, I am not good at chatting or making conversations. I was terrible on my English exams back in school, and wasn't confident at all to speak in English. I got stage fright even just in front of my classmates. And I suppose I don't enjoy team management either, even though I never led a team - so many things to be afraid of.
It doesn't give you the time to prepare for ready (or on the other hand, one might never be ready without taking the first step), as the project grows, as your responsibilities grow, you will be forced to learn and adapt. When it naturally grows a team, you have to learn to communicate, to lead. When someone invites you to do a podcast or give a talk, they won't wait 3 years for you to practice the language or speaking skills -- you either miss the chance or you fight your fear and do it. Because I love doing Open Source so much, I have to conquer them and myself.
Might be overwhelming it seems. But if you take those challenges and get through them one by one, gradually, you might find that they are quite fun and rewarding. In the end, I appreciate a lot about all those chances for pushing me out of my comfort zone and forcing myself to improve. Throughout these 4 years in Open Source, despite still being not perfect at many things, I managed to speak English much more confidently. I have given talks at many conferences, some of which even have thousands of attendees. I still get super nervous before every talk, but at least I am no longer afraid of doing it.
There are still so many challenges and surprises coming up. I am half fearful and half excited to see what's next.
Human adapts. That drives us to survive as well as keep improving, but that also makes us hard to stay satisfied.
I was so excited when I started my first few open source projects. I would keep refreshing the page, eagerly waiting for new issues, new pull requests, and new comments to show up. Every single star would make me happy, and I'll try to help with every single issue as much as possible. I set milestones like 100 stars, 500 stars and celebrate when I reach them. I still remember how proud I was when I told my friends that I had a few hundred stars on my projects and I was making some impact on the world.
Once you reach those goals, things start to become "usual". You will then start to expect more and set higher goals. At a certain point, I start to not care about those numbers of stars or downloads anymore. It's not necessarily a bad thing as they are not the metrics I should be focusing on anyway, but I sometimes miss the old days when I could get joy from those simple things.
I gradually realized, that the experience of so many things in our life has a direct relationship with our expectations. When we just get started, we have little expectations, which could be relatively easy to reach. As we go forward and stand on a higher ground, we start to expect much more, that might not scale linearly. Getting 100 more stars when you have 1000 does not sound as impressive as when you have nothing. When you have 1000 stars, you will look for another 1000, and only 100 can no longer satisfy you. That is odd to me, and I don't enjoy this "human nature" of mine.
I found that lowering my expectations and being grateful for what I have is a good way to keep me happy. When you start to realize you can't keep reaching your milestones one and another, it's a good way out to stop seeking higher, take a break and enjoy the view around you - maybe you have already reached high enough. Since I started to "not overly concerned about gains and losses", I found myself much happier trying different ideas even if they might not be successful - because I don't have high expectations of them, there is no such concept of "failure" to me. And if some of them later might turn out to be good ideas, it would be a nice "unexpected surprise".
If you are interested, I explained about my ideas-finding process in the About Yak Shaving post.
Expectations apply not only to what we are doing, but also come to myself. When I care about a project too much, I often find I am expecting myself too much in the role of being a kind and friendly maintainer. I will feel bad when I read people criticizing my projects, when a certain bug causes people trouble, or when I don't reply to issues in time, etc. The feelings become even stronger on popular projects, as you know there are a lot of people who depend on it. Those self-expectations put me under quite a lot of pressure and stress.
As I mentioned in another post, the ratio of maintainers to users is often unbalanced in open source projects. It's really hard to meet a new collaborator or team member, but there is basically no threshold to grow more users due to Open Source being naturally free.
I think it's hard for maintainers to make the mind shift and consider that they are not obligated to solve the issues for others -- because open-source software is usually served as-is. Especially for maintainers who care about their users and community, it's hard to ignore when we receive new issues. But in another perspective, one person's time and energy are limited. When the amount of work grows out of one's capacity, it's better to set priorities and focus on the most important things first.
I wish someone could tell me this when I started maintaining high-traffic open source projects (you have great resources online like this) - it took me a long time to realize that I don't have to be perfect, and it's okay to do things at my own pace. Instead of receiving notifications passively, it's better for me to turn off the push notifications, and to proactively check the issues and pull requests when I feel ready to do so.
I made a talk about How I Manage GitHub Notifications, if you are interested in more about the methodology.
Lowering the expectations of yourself - no one is perfect, and no one is a machine. Don't let them become a burden to you. It's more important to maintain a healthy and sustainable pace, and to keep yourself happy and motivated to have more positive impacts in the long run.
It's awesome to live in your own dream, and honestly, a privilege. But also, to be realisistic, having a dream is quite different from living in it. Dreams are always idealized, excluding all the boring details. My dream is to be a full-time open source developer. Yes, it sounds great to be independent, to work on what you like, to have a flexible or no schedule at all, to work from anywhere, and to benefit the world, etc. But in reality, things are not that simple.
It's quite similar to "Make your hobby your job". It indeed has a great amount of benefits, like you will be more enjoyable and productive, but it also comes with obligations and responsibilities. When a hobby becomes a job, you lose the freedom to choose when and what to. Before, you would do your hobbies as after-work relaxation, but now when you want to relax with your hobbies, they become work.
I was lucky that software development is a big field with many different things to do. Outside of the "main" open source project maintenance, I sometimes do some small projects (Generative Art, Stable Diffusion, some little experiments, etc.) for fun to refresh my mind (as a kind of "relax" from main projects). I also enjoy playing indie games a lot, while I keep thinking of getting serious about developing some games - but that's another story - at least now I still have some ways to escape when I really want to stay away from code.
I probably enjoy programming too much that I don't have strong feelings about this. The line between "work" and "fun" is quite blurry on my side. Sometimes, a fun project can become something serious that people rely on.
This is actually the topic that drove me to write this blog post.
Let's start with this "Iron Triangle" of Velocity, Scope and Quality.
(typicall they are Quality/Speed/Cost where I made a few adjustments here)
Usually, people would say -- in these three factors, you can only pick two. If you want to deliver a project faster, you might have to sacrifice the quality or have a smaller scope of features. If you want to have a high-quality and feature-rich product, you might have to sacrifice speed to deliver good stuff slowly, and so on.
To my personal standards, having high-quality software in Open Source is an unbendable standard that I would never compromise.
While also, keep a certain velocity and momentum is also very important to me. The majority of my motivation is driven by the feeling of accomplishment after I have finished something. I could be in an excellent flow when I can create the feedback loop of iterating things out then delivering.
So, to say, I usually pick Quality and Velocity. In the beginning, the scope of my projects was quite clear and small. I managed to keep the quality high, deliver things fast, and get feedback from the community quickly. At that time, I was able to stay productive and motivated to keep working on those projects.
I was "accidentally" able to keep that momentum and velocity for quite a long time. I started getting into Open Source with {i18n Ally} and {VueUse}, and since then, I joined Vue and Vite teams. Within 2021 alone, I came up with {Slidev} (April 2021), {UnoCSS} (October 2021) and {Vitest} (December 2021) -- Everything went almost too smoothly that I barely realized the capacity of having larger scope will have a certain limit.
I continued doing so with the "velocity" ignorantly since then. I am super lucky to meet the amazing teams and community, and get help from them:
It's a shame I couldn't list all of them, and many of them are actually overlapping across projects. What I am trying to say is that, I am not working alone, and I can't do all of these alone. I have borrowed so much help from the community and the teams to have all those projects. I am truly grateful for that. On top of Quality and Velocity, it seems that I also work on a wide Scope of projects - looks like it broke the rule of the iron triangle - but actually, the awesome community behind the scenes is the "magic" that makes it possible.
The amount of work required to maintain multiple high-traffic open source projects is honestly massive. I should have reached my limit a long while ago without help from the community. While the community helps me a lot, it still, takes a lot of energy to communicate, coordinate, as well as consistently context-switching. Over time, I accumulated many things I had to do myself, many ideas I wanted to try, and many things I wanted to improve.
I want to keep those projects alive and keep them moving forward; I want to write more blog posts to share my thoughts; I want to do more talks, to travel and meet people; I want to do more live streams as I know many are waiting for it; I have to clean this thing up, to do that release; I also want to learn French; And spend more time with my family - I mean, this is probably just life. People have their own concerns and responsibilities, I ain't any more special or busier than others.
"But somehow, there seems to be something,
something makes me hard to breathe."
I am probably reluctant to admit my potential burnout. Not because I am afraid of it, but more like, I don't want to give up and handle it passively. I know to take rest when I need it, but calling myself "burnout" and giving up is an "easy way out" to escape from the responsibilities. I want to find out the "root cause" and try to improve the situation instead of just "workaround" it. As we talked about previously, the shift of "expectations", and the re-evaluation of my "unpreparedness" and "self-expectations" are my solutions to the moments when I was close to burnout for different reasons. By adjusting myself and adopting, I was usually able to recover from the low points in roughly a week and keep moving forward.
The case this time is a bit different, it's not about me being unmotivated, but rather, there are too many things I wanted to do but I am running out of capacity. I started to think, that maybe it was that I expected myself to keep delivering everything with the same Velocity, I was anxious about not doing enough and not doing fast. Getting quick feedback is awesome and quite productive, but I am probably growing some impatience because I am too used to being quick. Combined, they make me easy to get frustrated when working on something that requires mid-to-long-term effort.
For example, writing. I am not good at writing, and I don't honestly enjoy it. Documentations, blog posts, tutorials, and talks -- all require a lot of time, and also, something I have to do. I easily get distracted and lose focus when I am writing or giving up in the middle. So I asked about it on Twitter and got a lot of great advice from the community (check the comments out and you might find something useful for you too). I started trying to take it easy and doing it slowly, trying to shift my mind to not expecting immediate results and enjoying the process. This blog you are reading took me roughly a week to write (that's a pretty long time for me), fragmented into multiple sessions. I feel also helps me to rethink and reorganize my thoughts and feelings, and actually, writing them down makes me feel much better about my anxiety.
So, I should probably re-evaluate my capacity and expectations. I have to understand and accept that I can not always keep the same velocity and I don't have to push myself too hard. Slowing down a bit to take more care about the details, maybe I will find different joy and satisfaction in the process.
Honestly, I am not even sure what I am trying to tell in this blog post - maybe just simply sharing my thoughts and feelings with you. Right now, I still feel quite some pressure. I am still adapting and trying to find a better way of dealing with it. I feel a lot better throughout this week of writing and talking to friends, and I am sure I will get through this. This might just be like many other things in our lives; we don't always have perfect solutions, but we have to keep going forward and find our way out.
Maintaining good mental health is one of the important tasks for every open source maintainer to keep sustainable. I don't think there would be "an answer" or "a solution" to the highs and lows throughout the journey. It's more like a continuous process of learning and adapting to find the ways that work for each of us.
Thank you for reading through my messy and verbose thoughts until the end!
I know my opinions must be heavily biased. If it ever triggers any thoughts or feelings for you, I am curious to hear what you think or what are your ways. You can leave some comments under this tweet or mastodon, or send me an email at [email protected] if you prefer private conversations. Looking forward to hearing from you!
Meanwhile, there are actually many other things about open source I didn't get to talk about in this post. Artem Zakharchenko wrote a great article [The Dark Side of Open Source, from different perspectives and points that I also resonate a lot with. Highly recommended to give it a read as well.
At the end, I want to give a huge thanks to my girlfriend Inès, who has been supporting me and helping me to get through those tough times since the very beginning. Without her great support, I probably wouldn't be in open source today.
Also, thanks to {@patak-dev} and {@posva} for our deep conversations around this topic, they really helped me a lot and provided great support.
And You, as well as the great open source community! I am so grateful for all the help and support I have received from you.
Till next time, take care!
