Everyone has a different motivation when working on Open Source Software. That motivation can change over time both in quantity and in actual motivation. When the Free and Open Source Software (a.k.a., F/OSS) movement began, the motivation was clear: I have hardware and I should be able to make it work for me and redistribute that software to others so it works for them too. This grew out of the nature of openness and co-operation already present in the academic environments where this was happening.
Today nearly 50 years after the noted start of this kind of software sharing and roughly 36 years after the launch of the free software movement, life is significantly different. It's different in part because computers and software have grown so much, and it's hard to tell how much of that growth has been because of the F/OSS that so many people have created, contributed to, and maintained over the years and how much of the growth of F/OSS is due to the ubiquity of computers and such. This growth has given us a much more room to:
- make F/OSS purely for fun
- make F/OSS because we're paid to
- make F/OSS to scratch an itch
- make F/OSS and then abandon it
Furthermore, it's amazing how much of the software that everyone in the world relies on is provided entirely for free. Much of that software powers global economic powerhouses and it can raise conflicting emotions when you think about how some high school student's project they published for fun might be used by a Fortune 100 company in their production stack. It's even more terrifying when you realize that as soon as the fun wears out, that someone could turn that dependency into malware. And yet, I think that we all inherently (and maybe subconsciously) accept this risk, even if we don't think it's a very likely possibility.
Probably a decade ago, there was a lot more skepticism around pulling in some random F/OSS dependency. Some of that skepticism was based around questions like:
- Will this person continue maintaining this?
- Will there be security issues with this and if so, how will that person handle them?
- Is this one of the many projects using "viral" licenses?
But today, a lot of companies seem far more willing to accept the risk to avoid the cost of developing something similar that checks all of the boxes. Further, many companies employ a totally new generation of developers whose careers have been immersed in F/OSS and take it for granted to some degree. Many of my peers today seem to have the some of following perceptions of F/OSS:
- How could anyone ever contribute to F/OSS? It's so big and I wouldn't even know where to start.
- Why wouldn't you use a F/OSS product if it exists? It's there, it does the thing, just use it!
- What do you mean your company doesn't allow you to contribute fixes back to a project either on company time or in your personal time?
- How self-conceited are you to want to be paid to work on F/OSS? I do this in my non-paid time and you should too. I have children, a partner, and such and I still find the time to do this.
- The only way to advance my career is to work on some F/OSS, build up a GitHub profile and find employers who want to hire me to work in the language I use for fun and F/OSS on GitHub.
- This maintainer hasn't responded quickly enough, they must not be maintaining this thing anymore.
- You're maintaining this software, my company is building other things that build upon it with our super special branding, so now I'm going to open issues, send you emails, try to DM you on social media, and contact you every other way because our product has a bug that is fixed in you (our dependency that we don't disclose) and need a release six months ago.
And this, is an anecdotal spread of my experiences. I'm sure other folks have had other experiences as well and this only represents something like 1% of people's perceptions.
My Motivations
When I started working on F/OSS, I was in college. I was teaching myself to program in public after having a really rough semester taking "Introduction to Computer Science" in Java and receiving super vague assignments that should have been easy but which I didn't understand and made more of than I should have.
I thought my problems were with Java so I taught myself C. I built an IRC bot with my own really awful parsing engine (having never learned to parse things before) and I made that public. I did it for fun because learning these things was fun back then (and honestly still is fun now).
My first "successful" F/OSS project was really something I did as a mental exercise and it's modicum of success is what sucked me into being far more involved than I ever thought I would be. I rebuilt Gina Trappani's todo.txt bash script in Python without reading the source just to see if I could. [1] As a result of its modicum of success, I wanted to integrate the issues on that project into my own ToDo list auto-magically and that's when I started working on github3.py this chain of events led me to becoming a maintainer on Flake8 and then Requests and so on from there.
In spite of the tremendous amount of nervousness I had about being part of such large and important projects, I was having a tremendously fun time. What scared me was that I gained a lot of this responsibility for somewhat critical infrastructure prior to even becoming a "real software engineer" because I was still in college studying mathematics. People implicitly and explicitly began to trust me more and more because I was associated with these well-known projects and eventually all I had to do was offer to help with a project and I'd be given the ability to write directly to the repository.
I took all of this very seriously, but it baffled me then and it makes a lot more sense now. Especially in the Python community, there are a fairly consistent group of people who produce a lot of the best known software for various things. Often times, those people are also trying to lift the tides for other projects that they need and become maintainers. Over time, you start seeing the same faces popping up and they're all overwhelmed so a new set of familiar faces start taking their place and the cycle continues. I was definitely one of those faces.
At this point my motivations had shifted from fun to a sense of responsibility and loyalty. My work on these F/OSS projects inexplicably made me very hireable, so I felt indebted to the community for helping me learn more than I ever would have if I had been a Computer Science major. I also felt loyalty to the people who had become my friends, who were the other familiar faces in these projects. I saw their exhaustion, I felt for them, and I wanted to help them. As you might guess, this cycle led directly to my several battles with burn out.
Today, my motivations tend to consist of the following:
- I want to have some fun, or
- I am trying to find people who can get paid to replace me, or
- I am trying to actively eliminate the need for the project in question
I've made my feelings on the free corporate consumption of F/OSS pretty clear over the years [2]. I still struggle with how to help others who are drowning under the burden of entitled corporate users making demands on their free time. But I think there is cause to hope.
Hope
While there are other projects out there, Bountysource continues to help (in some small sense) with the problem of funding the development of a F/OSS project specifically for motivating specific smaller pieces of work. However, I think one of our best bets for making F/OSS more sustainable (although still far from perfect) is Tidelift.
Traditionally, the biggest problem for companies (especially established "enterprises") has been how to send money to a project. It's nearly impossible to just send someone a lump of cash via PayPal arbitrarily in these companies. This is where Tidelift comes in. They are building a model where they act as the middle-people between these corporations and the under-water maintainers. By building subscription-based support contracts that both sides can deal with and handling the corporate procurement processes and such, they manage the relationship with the financial offices and F/OSS folks get paid.
Furthermore, a lot of people are excited about Microsoft's acquisition of GitHub and now of Citus Data. The excitement centers around how Microsoft is buying companies who built into their business model the benefit of F/OSS [3]. It seems like one of the oldest anecdotal opponents to F/OSS is now becoming one of it's biggest proponents and this makes some feel hopeful that Microsoft is going to integrate something that will put Bountysource and Tidelift completely out of business.
I have no particular horse in this race:
- I don't work with a Tidelift contract at the moment (although other developers on urllib3 are).
- I don't work on F/OSS as part of my job any longer (although I'm not forbidden from doing so either)
With all of that said, I don't know that including a payments system within GitHub will be any more sustainable than Gittip/Gratipay were [4] but no one has seen concrete plans for this so there's no need to try to predict what it might look like.
How Might This Affect the Future of Open Source?
This is hard to say, and of course, each person may disagree. I know there are a lot of people that believe that mixing money into F/OSS will cause all kinds of horrible problems (e.g., lack of democritization, no longer serving "the user", prioritizing bug reports from corporate sponsors over other "regular" users, etc.). I don't know that I've ever seen those concerns come to fruition, but I also don't know that they haven't. Regardless, I'm not convinced that they're going to cause significant strife.
If anything, I think paying maintainers will be th eonly way that F/OSS will be able to survive. And to be clear, paying maintainers can take the form of a number of methods:
- Projects dual licensing such that corporations need to buy a permissive license to use in their products (i.e., how Sidekiq works)
- Hiring maintainers directly and providing contracts that give maintainers a portion (perhaps even 100%) of their time to work on their F/OSS projects
- Sponsoring specific development (although this has proven to be less than sustainable, at least through Bountysource)
- Purchasing "support contracts" in a fashion similar to Tidelift
I know that if I could justify spending my ever more valuable "free time" financially to work on F/OSS, I might do that. Unfortunately, at this point, the projects that might happen for are the projects that bring me the least joy.
Finally, I would hope that paying folks to maintain these pieces of software would eliminate a class of trust problems that seem to be plaguing the software industry more and more these days.
What Does My Future Look Like in Open Source?
That's still an unanswered question. I still have a lot of fond memories that keep me hacking in tiny bits and pieces, but I'm scaling back to the point that I've actively asked people to not nominate me for positions in various F/OSS organizations. I don't have the time to dedicate to them and in some cases, I don't have the emotional energy to dedicate to the communities as a whole.
At this point in my life, I have far too many interests and far too little time. I'm taking steps back so I can re-evaluate what I really want to do instead of what I feel obligated to do and right now F/OSS maintenance is one of those things that feel like an obligation instead of a desire. I don't think I'm disappearing permanently or even really "disappearing" at all, but you may definitely see less of me on GitHub and more of me here.
Footnotes
| [1] | I got most of the way there. People pointed out behaviours that were wrong or missing and at that point I wasn't hacking on it any longer. |
| [2] | I was particularly burned out when I wrote this blog post but I still stand by much of the sentiment there around ethical consumption. |
| [3] | Certainly GitHub has made F/OSS easier and more accessible. They've also consistently hired upstream developers to work on upstream projects and so that's also at the very least beneficial. You may disagree on the categorization as a whole, and I don't want to argue this point terribly much. |
| [4] | Gittip/Gratipay had very few corporate sponsors of other developers. Primarily, the service was developers supporting each other making it a circle of cash that never landed in someone's bank account proper. |