Working on projects at 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:

• requests (and as a consequence chardet and urllib3)
• Flake8 (and transitively, pep8, pyflakes, and mccabe)
• Twine
• flake8-docstrings

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.

Working on projects for companies that don't employ me

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?

Other people's experiences

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"

When companies do "contribute", it's often not in the best interest of the community, it isn't enough, or it's thoroughly misguided.

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

When companies open source a project

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:

1. The company refuses to expand the core development team with non-employees
2. The company abandons the project and allows non-employees to take over the entirety of the maintenance burden while continuing to reap the PR benefits and failing to credit those people or support them in any manner.

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.

Why do companies behave this way?

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.

What needs to change

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.

1. Companies need to do more for the projects they use (financially, by engineers who can contribute to the project appropriately during their normal working hours, donating services, or some other way)
2. Companies that already contribute resources in one way or another need to check that what they're doing is not only in their best interest (or perhaps not in their best interest at all). No, really, the good of the project should be the focus of any contribution. If your goal is to improve something only for the company, then that isn't a contribution in good faith.
3. Companies looking for publicity and events that they can tout as their support of open source software, need to actually employ open source developers who know the pain that those events will inflict. Not a single maintainer has ever said "I don't care about the quality, just give me a flood of new contributions that I need to code review, give feedback, and hope that person actually acts on the feedback." Not once. I was linked to this webcomic recently and it aptly describes this approach.
4. If a company has an engineer test a fancy new feature for a project, that engineer needs to test more than just their own use cases to give effective or valuable review. (See also the following tweets from Jeff Forcier: https://twitter.com/bitprophet/status/660943465547599872, https://twitter.com/bitprophet/status/660943804250263552, https://twitter.com/bitprophet/status/660943975738556416, https://twitter.com/bitprophet/status/660944140641763328 in which he relays a story of an important PR that people claimed worked without really deeply testing it.)
5. Companies that use open source software should strive to hire some, if not all (not all in one place either), of those people that maintain the software to work on the project. And no, I do not expect those people to work 100% of their time on that project. That's unreasonable. They should be treated like adults though and allowed to spend what they see as an appropriate amount of time working on the project versus other projects for the company. Trying to quanitfy/limit the amount of time leads to conflict and strife and unhappy management and employees. It doesn't work and it's not a long term, maintainable solution.
6. Alternatively, instead of hiring those developers to hire the existing core developers, reviewers, and maintainers, those companies can buy training on how to effectively contribute and participate in upstream projects. That said, I doubt there's anyone who can train a person in empathy.
7. Companies need to stop encouraging and allowing their engineers to be abrasive, abusive, or insulting when reporting bugs or contributing changes to projects. This was admittedly more of a problem before I added Codes of Conduct to projects, but I still see this on other people's projects. (This happened 2 years ago on a bug report where the company upgraded from an ancient version of our project to the latest and greatest and found some usecase that apparently only they had that broke. The vitriol in their replies and their behaviour should have resulted in them being reprimanded by their managers for behaving that way while at work.)
8. Companies need to have realistic expectations of the work-life balance of open source maintainers. Open source software is unpaid labor for so many of us. It is work. Many of us working on successful projects take it very seriously. It is stressful. It is emotionally draining. Sometimes we don't have the energy to fix your problem as soon as you think it should be fixed. Sometimes we're on vacation. Sometimes we're sick or taking care of loved ones. Behaving as if we're your employee that you can just boss around is not acceptable. If you want that relationship with us, hire us to work on the project. (Hint: If you act like this, I will never work for you because it is very apparent your management does not understand what a real life is or how a work-life balance needs to be managed.)
9. Companies need to realize that not all open source authors or maintainers view their projects the same way. For many of us, we scratched an itch, we are not developing a product. We often do not want our hobbies turned into work because then we no longer have an outlet or a place to just have fun. The project may be serious business for you, but that may not be how others view it.
10. Money isn't everything. Whether you're a bootstrapped start-up or a company that is publicly traded with stock values in the hundreds of dollars, money isn't everything. Instead of placing $5000.00 on a bug, develop a relationship with the community. Sometimes a heartfelt gift is more meaningful than a large sum of money. I know some people who'd rather have games purchased for them off their Steam wishlist. Other people would love to get things from their Amazon wishlist. Know the people who develop the software that allow you to make the money you make and respect them.
11. Acknowledge the projects somewhere on your website, product, wherever. This one is simple, just say "This is powered by ...". This gives projects credibility and that gains users which means another company that can afford it might hire that person to work on that project.
12. Companies that open source something need to adopt a Code of Conduct immediately and from the start. And preferably, if they can, companies should sponsor and contribute to other projects that have Codes of Conduct (preferably real ones, not the crap the Linux Kernel has adopted).
13. Companies that open source a project and then abandon it need to publicly acclaim the people taking over the project and make a clear change in ownership. Creating a third-party organization that includes everyone actively involved in the project is the best plan and the one that will allow those non-employee maintainers to manage their time and commitments while being able to be recognized for their hard work, passion, and dedication.
14. More communities need to adopt Codes of Conduct and be more mindful about how their actions affect current participation of corporate and non-corporate contributors while coloring the future reputation of the project. Developers move on but first impressions do not. As new developers cycle onto projects, they may be unaware of past events and may be metaphorically shooting themselves in the feet.
15. Conversely, companies need to continuously strive to take the high ground and continuously re-evaluate projects and their involvement (or lack thereof) in the project.
16. Tons of things I can't think of at this very moment. Go read other articles about this. There are tons.

Concluding some things

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.