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.
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. …
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…
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…
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…
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…
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…
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. …
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…
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.
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., …
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…
Open Source & Web Standards Consultant.