I have been working on Open Source Software (in one way or another) since 2011 (just over 4 years since my first open source commit on a project). When I started writing open source software it was for fun. I was not a Computer Science/Engineering student. Programming was a hobby and open sourcing the code was fun and exciting. Eventually, I started maintaining Flake8, then Requests, then other things. Today, I'm a core developer of the following projects:
And probably other projects that I've forgotten about. I've created (and still develop) the following projects:
I'm was a core reviewer and driver for five projects in OpenStack (until recently when I removed myself from 4 of those projects). I am still a core reviewer for:
I also contribute (a fair amount) and am often pinged for reviews on urllib3.
Some of these projects are "owned" by one person and maintained by me (or me and other persons). In other words, the "owner" is absentee. Think of a landlord who does not collect the rent, or inspect the premises, or deal with tenants, or really any work.
I've worked on a lot of projects. I continue to work on a lot of projects. Over the course of two jobs, only one has given me the ability to work on Open Source Software ... sometimes.
OpenStack's Compute service, Nova, needed to perform URI validation as part of their JSON Schema validation but could not use the existing library because of licensing. Only because this was something important to my team, I was allowed to create rfc3986. I continue to maintain that, but, in my free time. OpenStack uses, heavily:
I've had opportunities to work on requests and Flake8 as a result of a few show-stopping bugs, but otherwise I don't work on any of the above projects during work. This isn't a break from what I'm used to, so I'm not trying to complain or anything like that. Would it be nice to be able to improve the software that powers our company and our product? Certainly, is there a serious need to do that? Not at the moment.
Some of these projects are used by the US Federal Government, those and others are also used by some really large corporations (no I won't name names, I don't see a point). I sometimes get a thank you from individual developers at those companies, but those companies think nothing of just taking the software (which is fine because I licensed it permissively). That said, when there's a bug introduced in the package, those companies email me, ping me relentlessly in IRC, create duplicate issues, and do everything they can to (perhaps unintentionally) overload me. As soon as a bug affects them, they want it fixed immediately. If you don't fix it in 24 hours (because maybe you have a real life or a family or you're sick or any number of other very valid reasons) then the threats start.
"Well if you're not going to take this seriously, we'll have to start using another project."
Not once has a company said to me:
"This bug is costing us $X per day. Can we pay you $Y to focus on it and get a fix out as soon as possible?"
I've also never demanded this. It would be nice, but it never happens. So, what happens? Those bugs are fixed eventually. Sometimes those companies let their engineers submit a fix that is incredibly poor but it took them an hour and now they can whine at me for not merging it. Nevermind that it breaks the continuous integration checks that ran 30 seconds after they sent the PR. This is because the company wanted to invest as little time in the problem as possible so the person couldn't fix the tests, write new ones, or write a real fix. I don't blame the engineer, I blame their manager and their company. If the project is that important to them, they should have let the engineer spend a few hours, fix the bug the right way and follow the guidelines outlined in the contributor's documentation.
Further, some of my projects (github3.py in particular) tend to only ever actively benefit corporations - the corporation using it and GitHub. Neither ever tries to support me in its development. This is why I am also very conflicted about finding other maintainers for this project. I would love to find someone who could be paid by their employer to work on it, but I do the majority of the work on the project so it's hard to even know who to ask about that.
In short, the joy and enthusiasm that I had when I started working on open source has been flattened. My attitude was naïve at best - this is fun and maybe I'm helping some other people do good and have fun too. This is also how a lot of my friends presently view their projects. Is it greedy of me to want them to continue to be able to have that perspective?
Ashe Dryden has written an invaluable post about The Ethics of Unpaid Labor and the OSS Community. This is a must read and it really hits home a bunch of very important points about the way we treat Open Source Software and its developers (e.g., requiring that a developer have an active and colorful GitHub profile before considering them for a job).
David MacIver recently decided they were Throwing in the towel for their project Hypothesis.
Eric Holscher, who co-founded Read the Docs and Write the Docs, has recently been discussing the economics of companies using open source software and contributing absolutely nothing back to the projects they use.
Dr. Russell Keith-Magee, the president of the Django Software Foundation, gave this talk at PyCon Australia. His key argument in this talk is that if open source projects had resources equivalent to closed source products, open source software would exceed any other project in quality. This talk is excellent and full of great examples.
Cory Benfield, my very close friend and colleague on several of the projects I mentioned above, has also blogged on this topic.
No one is asking companies to endure a significant financial burden in order to contribute back. But all of these items are, predictably, ignored by the companies who seriously need these projects to work and remain production quality.
When companies do "contribute", it's often not in the best interest of the community, it isn't enough, or it's thoroughly misguided.
OpenStack started as a collaboration between Rackspace and NASA; it was originally very operator focused. The project was used by tiny cloud operators and larger operators alike. All had a chance to voice grievances and work with developers to make things better. Somewhere along the way, the community became developers (who never deployed or operated OpenStack other than with DevStack) employed by large corporations working solely to forward the goals of those corporations. OpenStack isn't really something that was ever meant to be consumed by developers. Sure, the APIs are technically something a developer would use, but those are exactly how operators interact with the projects too. The developers who work on OpenStack don't mean to be harming the actual intended consumers, but if you keep an eye on discussions with operators, we (yes, I'm one of those developers) cause more problems than not out of sheer ignorance of the real users and how they actually use OpenStack. (To be clear, the community are the people who operate and maintain OpenStack clouds.)
Generally speaking, though, companies can have engineers become involved in a project to scratch their own itch while also benefiting the community. These are not mutually exclusive results; they're just exceedingly rare results.
A lot of projects use sites like BountySource to get paid to work on a bug on an open source project. Sometimes, companies will add a bounty to a bug. The largest bounty I've seen for any project I work on that accepts bounties has been $135 (USD). These values often do not reflect the true value to the company nor to the person fixing the bug. That said, sometimes you find a bounty like this one where a company has added a significant amount to a bug. Those seem to be the exception rather than the rule, though.
Other times, companies give a developer an hour to "make it go" which results in a situation like I described above. Allow me to expand: these will be companies that file a bug with as little detail as possible and then a fix that makes little sense and may appear to fix the bug but causes many others. After they have a fix, they stop responding to questions for more detail so it can be fixed appropriately. They often can't share a sample of how they're encountering the bug or anything like that.
Some companies don't even bother giving engineering time to a project, or money to the developers working on the project. Instead they run well intentioned campaigns to increase activity for those projects by offering rewards to anyone for doing just about anything, regardless of value or merit. These rewards can be anything.
One very recent such event promised a t-shirt if you sent 4 pull requests (via GitHub of course, because obviously real open source software would never be developed anywhere else) to open source projects. That was it. The pull request didn't need be merged, or to stay open for very long. It didn't need to contain any value at all. The event organizers contacted some projects owners asking if they could feature the projects. Now harken back to the paragraph where I explained that the owners of some of the projects I maintain are absentee. One of those was featured. That wasn't the only project I work on that that received hightened and lackluster attention from t-shirt seekers, but it was easily the one that received the highest traffic. So what happened was: the company contacted the owner who agreed but didn't tell me. The company never considered the fact that others might actually be doing the work of the project (and didn't think to check that with the API they're going to use to decide who gets a t-shirt). The company never talked to me in advance to, at minimum, warn me. (To be clear, the owner isn't blameless in this either, but I'm also not the only person who was in this position and complained about it. Perhaps I'm just loudest or have the largest platform.)
Of all of the pull requests (on all the projects) that I received as a result of this event, some of them were merely diffs that looked like this:
diff --git a/ex.txt b/ex.txt.new
index 5fe5360..e98e6b5 100644
--- a/ex.txt
+++ b/ex.txt.new
@@ -1 +1 @@
-foo bar bogus. Biz baz boo
+foo bar bogus.. Biz baz boo
No, really, I actually got a pull request that added a second period to the end of a sentence. I love encouraging and helping new contributors work on a project or otherwise aiding those new to open source in general, but how do you help someone who sends that pull request? Their commit message was "Update ex.txt". How do you help that person who clearly only has a goal of padding the number of PRs they sent for the month of October? Closing that pull request was a waste of my time, which is already stretched thin. I don't think that particular person was "trolling" (which is such an overused word as to be meaningless at this point), or otherwise behaving just in pursuit of their own amusement, but they were being inconsiderate.
Further, let me reiterate that the company in question did contact someone. That in no way exonerates their borderline reckless behaviour. I actively mentor several people who are new to open source and their event consumed (in aggregate) a few days of my time which did not leave me enough time to work on real bugs in other projects or mentor those people as well as I could have.
There are exceptions to the rules above sometimes. There's one particular team at HP (actually they're now in HPE) that is entirely composed of some of the best open source developers I know of working full time on their areas of expertise. But, this is the only team I'm aware of at HPE that behaves like this. Other teams (I'm thinking specifically of their teams working on OpenStack and their former Helion product) are split between product work and upstream work and most of the time don't have enough time to dedicate to being upstream developers and reviewers.
I would argue that while these sponsorships are good for the larger community, they're still a bit misguided. I trust each of these people to act in the best interest of their respective communities on that team at HPE, but what happens to them as soon as HPE decides funding that work is no longer beneficial or valuable? I don't have an answer to this, but I hope the answer is not that those developers are shown the door with a generous severance package. On a similar note, what happens if that developer decides they wish to explore other communities outside the reason they were hired? Is there room for growth or are their responsibilities narrowly defined enough that they have to quit to grow professionally?
I'm asking these questions in the context of this one team at HPE but there are some similar teams at other companies and the same questions are valid for those teams as well. If you want an example of what I'm afraid of, just look for the TwitterOSS team (hint: their funding as a department was cut).
There's also a separate pattern in the larger community where a company that already has some reputation in the community decides to open source a project that was previously just something they had initially developed for internal use. If these companies dedicate resources to the upkeep of the project and development of a community there tend to be two possible outcomes:
There are also rarer cases where people who contribute heavily to those projects are offered jobs to continue their work as an employee, but those seem to be fairly rare.
I have heard a myriad of reasons companies behave this way. I don't have the complete answer, but one important point is that there is toxicity in the community, its leaders, and or its contributors, and the companies have learned their behavior from this toxicity.
This certainly shouldn't be a surprise at this point. I would guess that it is safe to say that pretty much every person (including myself, I'm certainly not exempt from this) has had bad days and reacted poorly when dealing with the community, contributors, colleagues, etc. These are not excuses and these events can (and often do) shape the behaviours of the community and those observing it.
A close friend of mine, Paul Tagliamonte, was involved in the discussion about Debian's switch to systemd. He received at least 3 death threats due to his participation. In what world is this acceptable behaviour for a community? What about developers who have their addresses and the information of their loved ones posted on 4chan and other "forums"? Why don't we fight this more?
Any company that has involved itself (or its employees) with Linux Kernel development has probably come away with a very intensely sour taste in their mouth and a jaded view of how to effectively contribute to an open source project. In fact, I wouldn't be surprised to learn that these companies witnessed significant churn in the engineering teams working with that community.
They're also certainly not the only community struggling with this. Companies need to be involved, but just like other contributors, they need to be assured that they will be taken seriously and treated equally. Some projects work to actively alienate corporations trying to contribute because of ideology. This is not the path that will lead us to sustainable open source software development and companies that can contribute responsibly.
Too much for me to clearly or effectively enumerate without missing things. So let me give a high level list of things that I see as being incredibly problematic and maybe I'll expound on them (or a subset) if I still have the emotional energy to do so.
As with all of my posts on this web log, there is no comments section. If you'd like to discuss this with me, I would encourage you to email me. (You can find my address on my GitHub profile.) If you would rather discuss this in a briefer and more public fashion you can also discuss this with me on Twitter. Keep in mind that I've been really working on keeping a very serious work-life balance so my responses will likely be delayed if they occur at all.
I also fully reserve the right to take points from this post and write follow-up posts in much greater detail. If you take the time to send me an email or a tweet, I may also desire to use that as a discussion point in a future post. Be prepared for my asking permission to quote you, even if doing so anonymously.
I would like to extend specific and sincere gratitude to Cea Stapleton, Cory Benfield, and Paul Tagliamonte for their thoughtful, critical, and crucial review and feedback while I wrote this piece.