Tech giants aren’t philanthropies. There’s a reason they’re betting on open source: it’s good for business.

Open source is everywhere. It’s in your phone and in your car. It’s flying satellites to orbit and helping cure diseases. It’s powering today’s economy. Latest survey finds it in 96% of code bases, in which it represents more than half of the lines of code.

Image for post
Image for post

And yet… whereas every company uses it, few contribute back.

And so we hear of resource-strapped projects, security concerns, maintainer burnout, and sustainability issues. There’s even a conference specifically about the latter.

But what initially seems like a tragedy of the commons is actually a gigantic opportunity. …

Smaller companies need open source contribution policies too, but those can be radically simple.

Image for post
Image for post
Photo by Nikola Johnny Mirkovic on Unsplash

Open source contribution policies fascinate me. They’re generally left to management or legal to figure out. Developers rarely know of them. And yet, they shape the way companies practice open source… and thus how they write software

I spoke about creating open source contribution policies that don’t suck at the Open Source Summit in Edinburgh in 2018, with a focus on large companies.

But smaller companies need open source contribution policies too, even if those don’t need to be as complex.

Buffer is an amazing company with a radically transparent culture and philosophy. At Buffer, pretty much everything is public…

Software foundations have increasingly started helping non-corporate backed contributors with travel expenses. W3C has been lagging way behind. Until last year, “invited experts”—W3C jargon for individual contributors—even had to pay to attend the technical conference in which they come work for free. It’s time for change.

Image for post
Image for post
Photo by Fabian Blank on Unsplash

The context: across its different working groups, W3C has over 150 invited experts that contribute to spec work in various capacities, sometimes doing a lot of the heavy lifting. Unless these invited experts have a private arrangement with a client, which is rather rare (and needs to be disclosed to the working group), they work for free.

But not only are these experts working for free, they’re also paying for they travel expenses to attend face to face meetings in different parts of the world, and, up until last year even had to purchase their own ticket to join TPAC…

According to GitHub’s 2017 open source survey, 37% of contributors to open source projects don’t know whether their work contract allows them to contribute to open source outside of work. Another 12% need to get permission before doing so.

Image for post
Image for post
Photo by Parker Gibbons on Unsplash

The big picture: employers regularly seek to hire open source contributors, so much so that the word out on the street today is that if you’re a software engineer, your GitHub profile is your resumé (that’s a an issue in and of itself, but not the topic of this article). Software engineers know that very well, and strive to maintain a healthy open source presence, even when employed; a hole in your GitHub activity calls for justification just as a hole in your resumé would.

Anything that prevents software engineers from contributing to open source is a deterrent to hiring…

Image for post
Image for post
Alexandria Ocasio-Cortez and Kerri Evelyn Harris photographed by Corey Torpie (CC BY 2.0)

In a recent Huffington Post’s article about Ocasio-Cortez’s interrogation of Michael Cohen, the authors claimed that “[o]ne advantage Ocasio-Cortez has over some colleagues is that she consistently attends even the most mundane committee hearings, since she does not spend any of her day calling donors for money.”

That’s a second-order consequence.

Being able to attend any committee hearing wasn’t AOC’s original intent at all when she decided to rely exclusively on small donations. No. It’s a second-order consequence, a by-product of avoiding to rely on a small pool of large donors that have to be continuously groomed.

Second-order consequences aren’t…

Developers often intuitively assess the health of open source dependencies they decide to take on. What can we learn from their practice?

Image for post
Image for post

Last week, I posted about measuring the health of open source projects you want to take on as a dependency. A mailing list reader replied that they really like the simplicity of just focusing on the date of the last commit (shared with permission). (If you’re not on my mailing list yet, here’s where to sign-up.)

While I myself rely on that when picking open source projects, I realized it’s not the only signal I use.

I use node.js quite a bit for software development. I must say npm, node.js’s package manager, has made me pretty spoiled. It provides a…

Image for post
Image for post
Photo by Ragnar Jensen on Flickr (CC-By 2.0)

Open source software doesn’t come with service level agreements. You can decide to rely an open source project today, only to see its core maintainers leave and its community dwindle within a year.

Sure, you’ll be able to continue using the software, but you’ll be the one responsible for keeping it up to date. Fixing security bugs, updating dependencies, or maintaining interoperability with other software you rely on, all suddenly fall under your responsibility. …

An unrolled Twitter thread

Image for post
Image for post
The Cowpath. Photo by Bossi on Flickr.

Unrolling this twitter thread.

We’re seeing the same thing today with CSS that we’ve seen seen with HTML/JS before and which led to the current JS framework situation:

📱 A competition with native for slick app-like user experiences.

🐘 Larger teams working on more complex apps with needs that aren’t met by the current standardized tech.

🚀 A culture of moving fast and breaking things.

🏰 A distrust of standardization bodies, perceived as locked-up in their ivory towers and not understanding developers’ needs.

⚔️ A polarized landscape pitting pragmatism against good practices.

Just as with JS, the consequences are pretty…

Image for post
Image for post
Photo by Khamkhor on Unsplash

Yesterday, Stratechery’s Ben Thompson wrote a thought provoking article about the current AWS / MongoDB kerfuffle that’s been keeping the open source community’s echo chamber humming for the past couple of weeks.

It’s refreshing to have an outsider’s perspective on the topic.

It’s a great piece and you should absolutely read it. His comparison with the music industry is particularly apt.

Can AWS afford not to support its ecosystem?

Today, Thompson published a follow-up where he paints a sombre outlook for the business perspective of open source software providers like Redis Labs and MongoDB Inc., …

How open source widens wage and position gaps in tech and what companies can do about it.

Image for post
Image for post
Photo by Josh Appel on Unsplash

Open source is largely built on engineers’ free time. And free time isn’t evenly distributed. People who work two shifts, who care for elders and children—care-giving is still predominantly done by women—or with long commutes due to housing cost, just don’t have the time to contribute. The gender imbalance in tech is already pretty bad: women only represent 12% to 24% of the workforce depending on who you ask. But it’s much worse in open source.

In 2017, GitHub surveyed 6,000 open source contributors, over 90% of which were randomly sampled from about 3,800 open source GitHub repositories (the rest…

Tobie Langel

Open Source & Web Standards Consultant.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store