How and why should companies sustain open source communities?

Notes from the Sustain community meetup in San Francisco, April 12th 2019.

How  and why should companies sustain open source communities?

Notes from the Sustain community meetup in San Francisco, April 12th 2019.

Why should companies sustain open source projects?

  • Your business is based on Open Source Software. Those dependencies have to be maintained otherwise it’s a liability and your engineers will be slowed down by fixing bugs down the stack
  • Ethical question: you build a business based on the work of hundreds of engineers that make your app possible and they are not paid. Many of our friends are burning out maintaining open source projects.
  • Today, any application has thousands of dependencies. We can’t give $10k to each, but collectively we can.

Issues

  • How to divide the money to the different open source projects?
  • It’s obvious for very small and very large projects (Linux), not so obvious for the most common middle size projects.
  • There is no silver bullet. It’s gonna depend on each company and each project. Priorities are different. It’s ok, we need to embrace a diversity of solutions.
  • Different open source projects need different things, money is just a proxy for time. It’s often better to provide resources.
  • Companies need to get better at supporting open source communities but open source communities also need to get better at exposing what they need.
  • “The budget is in the hands of the CTO but it’s the engineers working on the code that know better what open source projects should be supported”

Benefits

(or how to sell sustaining open source to your company)

Here again, no silver bullet, each company will have different incentives to support different types of open source projects. So find out what arguments will resonate the most for your company. But here is a list that have worked for others:

  • Huge hiring persuasion tool
  • Expose your developers to a larger community. Avoid internal echo chamber.
  • Improves velocity: your developers are more likely to rely on open source communities to ask questions, less drag on velocity.

“When we allow our engineers to run a tech meetup in our office and cover for food etc., it’s not so much about the direct impact. But it’s about making our engineers happy and allow them to feel a sense of belonging to a larger community.”

We tend to forget the social role in open source communities. The most successful ones are not the ones with just the best code, but the ones that has a community of people who talk about it, blog about it, keep conversations alive, etc. “Let that sink in, don’t say that you don’t contribute to open source because you “just create issues or comment on issues”.

Experiments that companies are trying

Indeed is doing an FOSS fund. They give each month $10k to an open source project decided collectively by their engineers. See https://fosdem.org/2019/schedule/event/community_sustaining_foss_projects_democratizing_sponsorship/

Airbnb is experimenting with giving a gift card (using Open Collective) with each offer made to engineer candidate: “We care about open source and we think you should too”. “It’s a great way to convey our values”.

“Would be interesting to look at closing rate to see the impact”

Daniel Compton (https://twitter.com/danielwithmusic) in the Clojure community runs https://www.clojuriststogether.org/

He reaches out to companies that use Clojure to gather funds to sustain some important projects in the community. He runs quarterly surveys to find out which projects should the community invest in. It’s like a ad-hoc representative democracy for the community.

“It’s interesting to hear about how other communities do it, we tend to only hear from our own community”.

Quotes

“OSS replaced video games as my hobby”

“It’s not always obvious for people in our company that they can and are encouraged to contribute to open source, so doing information sessions about it helps internally”

“Hard problems are bad feedback loops in disguise” (so how do we make these feedback loops better?)

“Saying that a piece of software is open source is about as descriptive as saying that the company has a business model.”

Take-aways

At the end of the conversation, we asked everyone what was their main take away of the evening. Here are the ones that came out the most (note: those are take-aways from individuals, they do not engage their respective companies):

  • Loved the idea of gift card to engineer candidates
  • Incentivize employees to contribute to OSS (“How do I champion a culture of contribution in my company?”)
  • Great to be around other people who also think about sustaining open source in other companies
  • Open source communities need to be more transparent about what they need (e.g. we need money to hire a product manager, to hire a freelancer, to organize a conference, …)
  • Love the idea of giving stock of a company “to the community”
  • Would love another Sustain Community Meetup but centered this time around maintainers

Tweets and other blog posts

“lots of great ideas about how companies can better support open source products and how they can encourage their own employees to contribute started flowing. The next two hours were full of lively discussion from all attendees on the ethics, challenges, and next steps for each company in how better to promote collaboration on open-source projects.”

“One of the most important things said at the meetup I believe was this: open source isn’t about the code. It’s about the communities that develop around the code, and the people that enjoy them.”

https://dev.to/dlionz/what-am-i-doing-here-1lg4

“Hard problems are just bad feedback loops in disguise.”