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 articleOpen 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 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 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)
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, 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
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.
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.
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.)
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.
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.
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
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...
From my point of view there are not only one open source community, there are a myriad of them.
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.
I work with Python since 2009 and I just discovered the name of the guy that created it 2 years ago.
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.
Related
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 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)
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, 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
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.