June 29th, 2024

Open source is neither a community nor a democracy

Open source software thrives on meritocracy, not democracy. Core contributors drive projects forward, emphasizing collaboration and freedom under the license. Users' influence aligns with their contributions, fostering a gift exchange culture.

Read original articleLink Icon
Open source is neither a community nor a democracy

Open source software does not operate as a democracy or a community where users have a say in the project's direction. The essence of open source lies in the software itself and the freedom it offers under its license. While the term "community" suggests equal participation, most open source projects are managed by a select group of core contributors who drive the project forward. This elitism ensures that those who contribute the most have a greater influence on the project's direction. The tension arises when users feel entitled to a say in decision-making despite not contributing significantly. Open source operates on a meritocratic basis, where those who do the work hold the power. This model, although not democratic, provides users with the freedom to choose among various alternatives or even start their own projects. The concept of open source is best understood as a gift exchange, emphasizing collaboration among dedicated programmers. David Heinemeier Hansson, known for creating Ruby on Rails, emphasizes the importance of recognizing open source as a collaborative effort driven by those who actively contribute.

Related

The 10x developer makes their whole team better

The 10x developer makes their whole team better

The article challenges the idea of the "10x developer" and promotes community learning and collaboration in teams. It emphasizes creating a culture of continuous learning and sharing knowledge for project success.

OpenEMR: Open-source medical record software

OpenEMR: Open-source medical record software

OpenEMR is a feature-rich open-source electronic health records and medical practice management solution, offering ONC Certification, advanced features, multilingual support, and community-driven development. It prioritizes data ownership, security, and accessibility.

Software Engineering Practices (2022)

Software Engineering Practices (2022)

Gergely Orosz sparked a Twitter discussion on software engineering practices. Simon Willison elaborated on key practices in a blog post, emphasizing documentation, test data creation, database migrations, templates, code formatting, environment setup automation, and preview environments. Willison highlights the productivity and quality benefits of investing in these practices and recommends tools like Docker, Gitpod, and Codespaces for implementation.

CISA and Partners Guidance for Memory Safety in Critical Open Source Projects

CISA and Partners Guidance for Memory Safety in Critical Open Source Projects

CISA, FBI, and Australian Cyber Security Centre collaborate on memory safety guidance for open source projects. Emphasizes risk understanding, roadmap creation, and collaboration with the open source community for enhanced cybersecurity.

Open Sourcing Kinopio

Open Sourcing Kinopio

The creator of Kinopio, a thinking canvas app, open sources the kinopio-client app on its 5th anniversary. Users can now run, modify, and enhance the lightweight app (~220kb) locally or on the kinopio-server. This move aims to foster community contributions despite potential risks.

Link Icon 17 comments
By @schneems - 4 months
I’m a top 50. Rails contributor. I worked with him in the sense that I tried for him to not need to notice that I exist. I felt lots of community with other contributors and core. But never Dave.

The year I got my Ruby Hero award was the year that I (partially) convinced core team members to name the RC release of Rails “race car” because Dave ditched us to play Max Verstappen. He didn’t come to RailsConf because of a race.

The years he did come, he usually will come be there for his keynote, maybe see him at dinner, and then he’s gone. Everyone else is pumped to be there. Core and contributors show up, actually go to talks for all the days, conduct birds of a feather sessions and hack and chat.

On the day that 1/3 of basecamp quit I had a realization that he really just didn’t care about us. We were resources to be exploited.

I still really like the rails community, but it keeps feeling like Dave wants that to be exclusively defined around him. Which doesn’t feel like a community.

By @msteffen - 4 months
There’s a great episode of the Oxide and Friends podcast where Brian & co. talk to Kelsey Hightower about Hashicorp changing the Terraform license to exclude a lot of companies in the TF ecosystem—the ultimate “we’re the maintainers we can do what we want” move. Kelsey has maintained many open source projects and understands the importance of maintainers having freedom to focus their energy where they see fit regardless of what the peanut gallery thinks.

His view was: what is ultimately needed is upfront clarity from maintainers about how they’re going to govern the project. If you want to have complete control over your project and ignore bugs and pull requests as you see fit, and users need to accept the software as it is, that is fine and good, but put it in the README so that prospective users know what they’re getting into. If you want to have a community-driven governance structure where people have a path to getting involved and steering the project, like Kubernetes, that’s good too and you should lay all that out for users too. What Terraform did, where they cultivated community engagement in order to have a plugin ecosystem and then rug pulled those plugin authors by changing the license, “poisoned the well of open source” (his words) by giving the impression that OSS is inherently fickle and serious teams should be hesitant to use it because maintainers can and will break things carelessly. I think there were companies that failed because of the TF change.

(I also posted this in a reply but now realize that I wanted to say it as top-level comment. Sorry for reposting, Ma.)

By @kelnos - 4 months
I agree with a lot of what the author is saying, but the premise seems a little odd to me. When did anyone ever claim open source was a democracy? And I don't really associate "community" with "democracy", either. I don't see them as related at all. Certainly there are communities in democracies, but there are communities under all kinds of political and governance systems.

I do think a lot of people have an entitled attitude toward open source and open source developers, which is regrettable (as someone who has been on the receiving end of that entitlement many times over the years), but I don't think I've really seen people assuming that users get to vote on what developers work on.

(I do recall bug trackers like Bugzilla used to have a feature where users could vote on bugs, though, so maybe in the past some people really did think that all open source developers would tackle the highest-voted issues first.)

Anyway, I do feel like this sort of post is par for the course for something DHH might write. I've never worked with him, but based on reading things he's written and observing (from a distance) some of his interactions with the Ruby community, he's always seemed a bit out of touch with how communities actually operate. To put it charitably.

By @drbig - 4 months
> But whatever word you choose, you'd do well to remember that open source is first and foremost a method of collaboration between programmers who show up to do the work. Not an entitlement program for petulant users to get free stuff or a seat at the table where decisions are made.

Sounds to me exactly like words of someone who has actually been running relatively popular open source project(s) for a long enough time to get really tired of all the people who have opinions and needs but absolutely no interest in contributing anything of value.

(there are more ways than code, and money isn't the only alternative either.)

I see no contradiction with the reality of the project structures of those "who actually make it work" and ship _software_ vs the community of people who use the _software_. Each project will have unique details, but the users will usually outnumber the makers by order(s) of magnitude.

Open source is indeed a programmer collaboration methodology. Any notion, or even existence, of "a community around the project" is completely separate.

By @metabagel - 4 months
It’s not a democracy, but it’s a community. The act of sharing creates a community.
By @KBme - 4 months
Yes. Otherwise one half of contributors would have died in a famime and the other half at the hands of secret police. I remember them tryimg to subvert linux with some unconsequential contributor accusing people in the core team of sexual misconduct and whatnot.
By @Almondsetat - 4 months
Truth is, people do not think about the meanings of words and their implication. They simply follow what's popular.

Even though selling software is perfectly in line with GPL, since 99% of FOSS has not been commercialized, people have gotten this idea in their heads that it's wrong and antithetical.

Even though (regarding collaboration) the only requirement of FOSS is to make the source code relatively easily available, people have been accustomed to the GitHub way of developing for so long that it has forever changed the perception of what is considered an open source project

By @Mathnerd314 - 4 months
By this logic, X/Facebook/Instagram/etc. are not communities, but "ecosystems"... after all, everyone controls their own posts. You can't force someone to post something you want. "Don't like what <celebrity> is posting? Follow one of the countless alternatives. Or start your own account! Here, you can even use this automated bot as a base for making the posts you'd like." Meanwhile, "whatever word you choose, you'd do well to remember that <platform> is first and foremost a method of collaboration between elites. Not an entitlement program for petulant users to get free stuff or a seat at the table where decisions are made."

But these social media platforms are clearly communities... they even have "community guidelines". Not to mention Github https://docs.github.com/en/site-policy/github-terms/github-c...

By @litox - 4 months
This description of open source fits with the plurarchy concept explored by Alexander Bard in Netocracy 2 decades ago.

From my point of view there are not only one open source community, there are a myriad of them.

By @pluto_modadic - 4 months
Okay, let me get this straight. So, Rails will neither patch security vulns, nor bugs, because Rails isn't a community? lol.
By @danmaz74 - 4 months
Any successful enough open source project will develop a community around itself, but it's true that this isn't a kind of community where democracy works or should be expected to be implemented. And, as DHH put it, that's fine.
By @jillesvangurp - 4 months
Most open source projects are a money driven meritocracy. This is a good thing. There's a lot of open source. But much of it is running on commercial interest from the various companies that depend on it (i.e. every big software company you can name). They pay the bills. People get paid to work on open source projects and these companies wield their influence through these people. Whatever this is, it isn't charity mostly.

There are of course also a lot of hobby projects and a few idealistic ones. I run some of those small projects myself. But most of the bigger strategic projects have companies behind them and are all about what they need and want. This long tail of smaller projects is nice and all and there's a lot of value there and people run them for all sorts of reasons. But as soon as they become valuable, companies and commercial interests tend to get involved one way or another. Most people just don't have a lot of unpaid time to donate.

Either way, decision making is strictly hierarchical typically. You are welcome to fork and modify and do your own thing. That's what it means to be open source. You are not welcome to force push your changes upstream. Getting your changes accepted requires scrutiny, consensus, and negotiation that involves the upstream people in charge. Mostly those people get that power by virtue of being there, doing most of the work, and being qualified for the job. And then getting paid to do that job. In most well run projects getting your changes in is a relatively straightforward process. But when there are conflicts, upstream generally wins.

Rails is a good example where loads of people started making money doing rails related work 20 years ago or so. The author is the creator of Ruby on Rails and the CTO of a company that drives its development and where the framework was initially developed. It probably makes nice amounts of money from doing rails related work and it apparently made him quite wealthy. Good for him.

By @braza - 4 months
Ruby folks maybe this is a silly question, but why DHH it’s still relevant in the ruby ~community~ user group?

I work with Python since 2009 and I just discovered the name of the guy that created it 2 years ago.

By @openplatypus - 4 months
Please stop posting DHH bullshit. Don't amplify this troll's content.
By @Grimeton - 4 months
On the one side: Yes, truer words have never been spoken. You want a new feature added? Want to talk about how the project should change directions? Want to impose new rules? Do a little power play? Yeah, start working on the project, implementing changes/features you want to see.

On the other side: No. When you provide software that is widely used and that people rely on, you automatically created a community where fixing bugs is an obligation. Your software has become a corner stone in other people’s software stack/life and so those people and their issues with your software have become your problem, too. If you want it or not.

Hiding behind open source and not fixing bugs has become a deal breaker so many times over the last few decades, that I stopped counting. Not everybody knows the language needed to fix a bug and not everybody understands the dependencies within a project to being able to fix a bug. So “fixing” one bug can create ten new ones and make things much worse.

Not to mention what happens when you attempt to fix the bug but the source is not accepted upstream because it’s bad, which is understandable, but still leaves you with an upstream version of the software and your patched version that fixes said bug.