15 ms·

Open source is neither a community nor a democracy

77 points by levlaz 2y ago

pluto_modadic 2y ago
Okay, let me get this straight. So, Rails will neither patch security vulns, nor bugs, because Rails isn't a community? lol.
oswaldreign438 2y ago
[dead]
Grimeton 2y ago
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.
- trealira 2y ago
  > 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. Maybe you believe they have a moral obligation, but under the most popular open source licenses, they have no legal obligation to fix bugs or be held responsible for the damages caused by their bugs, regardless of whether people rely on their software for critical software. From the MIT license: THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. From the GPL license: 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. If you rely on open source software, you do so at your own risk, as the authors have no obligations to those who use the software they made, and it's written out explicitly all the time; people just skip past it.
- flohofwoe 2y ago
  Well, never use a dependency that you couldn't write or maintain yourself. It's really quite simple. As soon as you use a dependency, you take ownership of that code within your project. If you need changes made that the dependency owner isn't willing to do then fork the dependency. If you can't do that, don't use that dependency. The actual advantage of open source is that you actually have access to the code, create a fork and maintain it yourself if things go south.
  - Grimeton 2y ago
    Depencies within the project didn't refer to third party libraries, but to the knowledge how changes in function A or structure B affect the rest of the software. Changes to code can seem to have zero side effects and three months down the line it turns out that those changes caused huge security issues. And btw: If using open source software is only an option when I know all the languages needed to write all the stuff myself, then the whole thing just lost its meaning.
    - yawaramin 2y ago
      No, it didn't. Open source software doesn't mean that someone else provides free support for all the software (by knowing all the languages needed to write it). It means that you can choose any vendor you want to provide the software to you. Open source has never been about getting software for free, it has always been about preventing vendor lock-in.
    - kelnos 2y ago
      I think you're presenting false dichotomy. You seem to think that the only options are two extremes, either: a) open source developers are obligated to provide their users with fixes to any bugs they run into, or b) open source developers will never ever do anything for their users, so anyone who uses open source needs to be competent at maintaining and modifying all the open source software they use. I hope you don't truly believe that, and assuming you don't, I hope you aren't arguing this way in bad faith. Because neither of those things are true. Open source developers will often want to fix bugs in their software, and add new features that people find useful. A user need not assume they'll have to take ownership of everything they use and maintain it themselves. But an open source user has no right to demand anything from the developers. Sometimes the user will have to do their own work if they're having a problem, because sometimes those problems won't get addressed (either ever, or on a time scale that the user needs). And anyone who makes use of open source software should go into it with that understanding. I've done that myself: I've adopted open source libraries at work (and for personal projects), have found issues with them, fixed the issues, and sent PRs to the maintainers (and maintained and used my own forks until those PRs were merged and new releases made). On occasion when bugs I've found seemed like they'd require too much deep understanding of the code, I've filed issues and provided as much information as I could to help the maintainer reproduce the issues. Sometimes those bugs got fixed, and that's great. But sometimes they didn't. That's frustrating, to be sure, but those maintainers had no obligation to me. From there, I had three options: a) dive in and take the time to learn the software well enough so I could fix the bugs myself, b) live with the bugs being present and decide that that will be ok, or c) drop that software and find or write something else that met my needs. And all that above is what you sign up for if you decide to depend on someone else's open source work. If you don't like that, then you have two choices: a) write everything that you need yourself, or b) pay someone else for their work. That's it. You have no right to demand anything from any open source developer. For any project that I maintain... anyone who comes in believing I'm obligated to do whatever unpaid work they want from me immediately gets banned from whatever communication channel they're using to make those demands.
- pdonis 2y ago
  > When you provide software that is widely used and that people rely on, you automatically created a community where fixing bugs is an obligation. No, you don't. Some open source producers might choose to take on that extra burden, but giving your software away for free cannot automatically create such a burden, no matter how many people use it. The only recourse you have as a user if you don't like that deal is to not use the software. You don't have the right to demand more free work from someone who already provided you with free work.
  - ozim 2y ago
    How often it is that someone just gives software for free? I mean usually you have to promote software and by promoting you create an obligation - no one is going to use it if you drop some piece of code on GH and in reader you will write „I don’t care about it take it or leave it”. You have to actively promote and show that you care to create „widely used software”. Promoting by showing that you care creates the obligation. Of course obligation is not entitling people to tell you what to do - but to keep level of decency like fixing glaring security flaws.
    - pdonis 2y ago
      > Promoting by showing that you care creates the obligation. Promoting by promising to fulfill a particular obligation creates the obligation. I'm not sure "showing that you care" is specific enough. In any case, you are shifting your ground. Before you said that just making the software available and having enough people use it creates an obligation. Now you are saying that "promoting" it does. When "promoting" is properly unpacked, you will end up agreeing with my position: either the software author has made an explicit promise to provide support, or they haven't. If they have, they have an obligation; if not, they don't.
    - swatcoder 2y ago
      First, most users are indeed finding open source software by searching around by keyword and assessing top hits on their own. Most developers don't have a sense of how to promote their project effectively if they wanted to. Marketing of any sort only plays a role in the most high profile projects, many of which are commercially sponsored. Second, even where a developer puts some legwork into letting the world know what they've shared, that effort is within the context of the project's license terms which almost universally make it explicit and clear that they profer no such obligation. Tweeting "I made this thing, check it out!" does not soemhow absolve the user from reading the license on that thing and understanding that no promises are made.
- yawaramin 2y ago
  You are completely wrong, and this really couldn't get any simpler. Just look at the license of the software you are using. You agreed to this license when you used the software. It says something similar to: > THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. It's not even as if this was buried under mountains of legalese. OSS licenses are usually quite simple. You have absolutely no excuse for not understanding that the software provider has zero obligation to you. All you had to do was read a few paragraphs.
- lolinder 2y ago
  > When you provide software that is widely used and that people rely on, you automatically created a community where fixing bugs is an obligation. What you're saying here is that "give them an inch and they'll take a mile" is not just a description of an unfortunate reality, it's a moral imperative. Give them an inch and they have a right to that mile. Do you not see how totally destructive this moral framework is? If giving away free work instantly entitles anyone who benefits from that free work to an arbitrary amount of additional free work, the only rational move for a would-be contributor is not to play the game at all. Is that really the world you want to live in?
- kelnos 2y 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. No, absolutely not. What I write and release comes with no warranty, and no guarantees that any of it is fit for purpose. If people want to use it and find it useful, that's great. If they don't, that's fine too. If they use it and have problems, I'm happy to receive bug reports, but I don't work for them, and have no obligation to them. I will work on bugs and improvements because I want to, because it's fun, and because I care about my work. But when it's not fun or I don't care, I may not work on it, and that's 100% my prerogative. > 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. That's tough luck, then. Let's reframe a bit. Let's say you've decided to pay Oracle for their proprietary database. And then you find a bug in it. What are you entitled to? At best, I'd say you're entitled to a refund. Oracle actually has no obligation to fix that bug for you. But Oracle likely will want to fix that bug, because they maybe want to keep you as a customer, and develop and maintain a reputation that their software is worth the money people pay for it. Certainly some open source developers often have reputations they want to maintain. And sometimes doing the grunt work to do thankless jobs and fix annoying bugs and add features they don't care about... well, sometimes that's necessary to maintain the reputation they want to maintain. And that's fine, if that's the choice they've made. But it's also fine if someone just wants to build stuff for fun, share it with others, and continue only doing things with it that they find fun. You might look down on people like that, or be frustrated with them, or choose not to use their software, but you are not entitled to any work out of them, and they are not obligated to provide you with anything at all.
- swatcoder 2y ago
  > 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. As noted in VERY LARGE PRINT at the top of almost every open source license for the last thirty years or so, the person taking the free stuff is responsible for whatever happens when they do. That's why it's free! If you can support it yourself, great. If you can't, then you might need to hire someone to do so. If those options don't appeal to you, then you should probably buy an alternative that does not explicitly tell you that you're on your own. Open source software exists so that the community of reasonable, responsible people can share work with each other without being caught in a rats nest of finger pointing, liability, and defensive practices like hiding source code or preventing alteration. It is a two-sided contract, and the user's side of the contract is very explicitly to take responsiblity for what they choose to do with what they take.
- kragen 2y ago
  > When you provide software that is widely used and that people rely on, you automatically created a community where fixing bugs is an obligation. if you measure the solubilities of some salts and publish them, and your data is widely used and people rely on it, do you therefore have an obligation to repeat your experiments to make them more precise and correct erroneous measurements, and to extend them to more salts? i think not; i do think you have some ethical obligations, but they are limited to admitting that you were wrong, and not taking credit for others' work if the users of your work start talking to each other and helping each other, they might become a community, but that still doesn't impose an obligation on you to do more work for them. to my way of thinking, you're the person in that situation with the least ethical obligations
- wiseowise 2y 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. No, just no.
Mathnerd314 2y ago
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-community-guidelines https://docs.github.com/en/site-policy/github-terms/github-c...
- kragen 2y ago
  they're not communities. 'community guidelines' is a marketing eyewash; those are diktats imposed by management, not some kind of decision of the 'community' at best, fecebutt and the like are fora where communities can form, as long as management tolerates them
- robinsonb5 2y ago
  The platforms themselves are absolutely not communities; they're a virtual location - a space - and some infrastructure within which communities can form. Any one community within is free to set its own rules and conventions (for instance, I'm on a community noticeboard group where business posts are only allowed a Monday), but those communities have absolutely no influence over the policies of the platform as a whole.
  - kragen 2y ago
    and the platform often throws wrenches into their workings
- wiseowise 2y ago
  > 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 https://docs.github.com/en/site-policy/github-terms/github-c... Well, if they have community guidelines… this definitely makes them a community, lol.
schneems 2y ago
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.
- bruce511 2y ago
  Communities exist orthogonal to the project itself. They start optimally as user-groups of people who are basically peers of each other. Yes, some projects include themselves in the community. Others are involved in the community. Others set out to actively build and maintain a community. There's no one model fits all here. The ideal community has a power balance. It (can be) hard on a DHH-like figure at conferences because some percentage of folk treat it as a bug-reporting forum, or feature-request session. People don't want to get to know you, they just want your attention. I've been to "conferences" (community driven, large user groups) where the Supreme leader is there, and where they aren't. Frankly the ones where they are not there are more interesting. At conferences when they are there, the focus tends to be more on what they said (usually with gross misinterpretations) coupled with a lot of whining about what they're doing wrong. When we're "alone" it's more about the community, sharing knowledge, more positivity etc. IMO the ideal community does not centre on the project lead. It works better when the power imbalance is absent. And yes, this sometimes makes the community feel powerless (which they are). But it's still better.
- tasuki 2y ago
  I can easily empathise with both DHH and you! > We were resources to be exploited. This is uncharitable. DHH have you the gift of Rails. He does not want to give you the gift of participating in the community. That is okay! I don't know much about Rails, but my guess would be that DHH poured insane amounts of time, effort, and caring into Rails. Is that not enough?
kelnos 2y ago
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.
metabagel 2y ago
It’s not a democracy, but it’s a community. The act of sharing creates a community.
- atlasy1 2y ago
  That is not true in most people’s experience judging from previous HN threads unfortunately. Generally one or two contributors are breaking their balls doing all the work and due to a schooling created desire to inpress others are just being taken advantage of. Then thousands of freeloaders and cheerleaders riding on their back who are not even willing to donate $2 to the project demand more and more shit Eventually the contributors eventually burning out and seeing how stupid the entire thing is (I.e no longer caring what these people say or think of the project) and the project suddenly gets abandoned Two dudes creating something from a place of ego satisfaction and thousands of cheerleaders taking advantage of them is not a community
  - AstralStorm 2y ago
    Unless said two guys (usually the core is up to 10) are implementing the project to work well for their own uses too. Really, FOSS exists to solve problems of the developers, with good user interface sometimes an afterthought for this particular reason, as the developer is the ultimate power user often enough. The exceptions are the true big projects, but they can end up in the 10 people situation due to sheer size of it. Those people are then usually maintainers, like in Linux. Unless the project starves due to user/developer mismatch, or gets taken over by corporate interest and people start implementing stuff neither the developers nor users actually want, sapping the energy. (I'm looking here at Mozilla Foundation specifically.)
- kragen 2y ago
  kind of, yeah, but dave's description of it as a gift exchange seems really on point. it's not a community in the way a village debating who should get to graze on the common is a community. it's a community in the sense that everyone has the right to use the shared resources, but that doesn't give them a vote it's a curious situation, because with naturally scarce goods like grazing land, the best we can do is control access to them fairly, so our intuitions about community come from two million years of that. but software is knowledge, not land or capital goods. it conflicts with our intuitions would you speak of the community of air-breathers, the community of users of the pythagorean theorem, the community of speakers of english? that's the kind of community we're talking about when we talk about the linux community or the rails community
KBme 2y ago
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.
Almondsetat 2y ago
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
- kragen 2y ago
  well. you also have to license it under an open-source license
- oska 2y ago
  The requirement of Free Software is to respect the four essential freedoms [1], one of which explicitly talks about 'community'. And the essay that lays out the four freedoms begins with this very line : > “Free software” means software that respects users' freedom and community. (my italics) This is why, while 'FOSS' can sometimes serve as a useful, rough grouping, the need to distinguish Free Software from Open Source is an important one. The two are not the same. The author of the submitted piece, of course, talks only about Open Source. [1] https://www.gnu.org/philosophy/free-sw.en.html#four-freedoms https://www.gnu.org/philosophy/free-sw.en.html#four-freedoms
  - Almondsetat 2y ago
    Respecting community does not mean creating community. FOSS allows people to collaborate freely, it does not force people to collaborate.
openplatypus 2y ago
Please stop posting DHH bullshit. Don't amplify this troll's content.
- steve_taylor 2y ago
  Jason Fried really needs to rein in his barking dog. It's a bad look for the company.
braza 2y ago
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.
- danmaz74 2y ago
  Are you confusing ruby with rails? DHH created the latter, not the former.
  - pluto_modadic 2y ago
    I think DHH tries to also speak for ruby, not just rails.
    - tinco 2y ago
      Nope, the two "communities" are largely disparate. They have different philosophies and different leadership.
  - braza 2y ago
    Ruby with Rails. Just read the full article about him. Sure was the creator and I got that. But from what I heard his positions and part of the "community" not liking his ideas, what prevented someone to do a fork, let's say Ruby on Trails, and get a more community driven approach?
    - Timshel 2y ago
      I guess nothing and that kind of reinforce DHH point.
danmaz74 2y ago
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.
msteffen 2y ago
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.)
deleted 2y ago
[deleted]
litox 2y ago
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.
jillesvangurp 2y ago
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.
drbig 2y ago
> 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.

77 points by levlaz 2y ago

Okay, let me get this straight. So, Rails will neither patch security vulns, nor bugs, because Rails isn't a community? lol.

oswaldreign438 2y ago

[dead]

Grimeton 2y ago

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.

trealira 2y ago
> 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. Maybe you believe they have a moral obligation, but under the most popular open source licenses, they have no legal obligation to fix bugs or be held responsible for the damages caused by their bugs, regardless of whether people rely on their software for critical software. From the MIT license: THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. From the GPL license: 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. If you rely on open source software, you do so at your own risk, as the authors have no obligations to those who use the software they made, and it's written out explicitly all the time; people just skip past it.
flohofwoe 2y ago
Well, never use a dependency that you couldn't write or maintain yourself. It's really quite simple. As soon as you use a dependency, you take ownership of that code within your project. If you need changes made that the dependency owner isn't willing to do then fork the dependency. If you can't do that, don't use that dependency. The actual advantage of open source is that you actually have access to the code, create a fork and maintain it yourself if things go south.
- Grimeton 2y ago
  Depencies within the project didn't refer to third party libraries, but to the knowledge how changes in function A or structure B affect the rest of the software. Changes to code can seem to have zero side effects and three months down the line it turns out that those changes caused huge security issues. And btw: If using open source software is only an option when I know all the languages needed to write all the stuff myself, then the whole thing just lost its meaning.
  - yawaramin 2y ago
    No, it didn't. Open source software doesn't mean that someone else provides free support for all the software (by knowing all the languages needed to write it). It means that you can choose any vendor you want to provide the software to you. Open source has never been about getting software for free, it has always been about preventing vendor lock-in.
  - kelnos 2y ago
    I think you're presenting false dichotomy. You seem to think that the only options are two extremes, either: a) open source developers are obligated to provide their users with fixes to any bugs they run into, or b) open source developers will never ever do anything for their users, so anyone who uses open source needs to be competent at maintaining and modifying all the open source software they use. I hope you don't truly believe that, and assuming you don't, I hope you aren't arguing this way in bad faith. Because neither of those things are true. Open source developers will often want to fix bugs in their software, and add new features that people find useful. A user need not assume they'll have to take ownership of everything they use and maintain it themselves. But an open source user has no right to demand anything from the developers. Sometimes the user will have to do their own work if they're having a problem, because sometimes those problems won't get addressed (either ever, or on a time scale that the user needs). And anyone who makes use of open source software should go into it with that understanding. I've done that myself: I've adopted open source libraries at work (and for personal projects), have found issues with them, fixed the issues, and sent PRs to the maintainers (and maintained and used my own forks until those PRs were merged and new releases made). On occasion when bugs I've found seemed like they'd require too much deep understanding of the code, I've filed issues and provided as much information as I could to help the maintainer reproduce the issues. Sometimes those bugs got fixed, and that's great. But sometimes they didn't. That's frustrating, to be sure, but those maintainers had no obligation to me. From there, I had three options: a) dive in and take the time to learn the software well enough so I could fix the bugs myself, b) live with the bugs being present and decide that that will be ok, or c) drop that software and find or write something else that met my needs. And all that above is what you sign up for if you decide to depend on someone else's open source work. If you don't like that, then you have two choices: a) write everything that you need yourself, or b) pay someone else for their work. That's it. You have no right to demand anything from any open source developer. For any project that I maintain... anyone who comes in believing I'm obligated to do whatever unpaid work they want from me immediately gets banned from whatever communication channel they're using to make those demands.
pdonis 2y ago
> When you provide software that is widely used and that people rely on, you automatically created a community where fixing bugs is an obligation. No, you don't. Some open source producers might choose to take on that extra burden, but giving your software away for free cannot automatically create such a burden, no matter how many people use it. The only recourse you have as a user if you don't like that deal is to not use the software. You don't have the right to demand more free work from someone who already provided you with free work.
- ozim 2y ago
  How often it is that someone just gives software for free? I mean usually you have to promote software and by promoting you create an obligation - no one is going to use it if you drop some piece of code on GH and in reader you will write „I don’t care about it take it or leave it”. You have to actively promote and show that you care to create „widely used software”. Promoting by showing that you care creates the obligation. Of course obligation is not entitling people to tell you what to do - but to keep level of decency like fixing glaring security flaws.
  - pdonis 2y ago
    > Promoting by showing that you care creates the obligation. Promoting by promising to fulfill a particular obligation creates the obligation. I'm not sure "showing that you care" is specific enough. In any case, you are shifting your ground. Before you said that just making the software available and having enough people use it creates an obligation. Now you are saying that "promoting" it does. When "promoting" is properly unpacked, you will end up agreeing with my position: either the software author has made an explicit promise to provide support, or they haven't. If they have, they have an obligation; if not, they don't.
  - swatcoder 2y ago
    First, most users are indeed finding open source software by searching around by keyword and assessing top hits on their own. Most developers don't have a sense of how to promote their project effectively if they wanted to. Marketing of any sort only plays a role in the most high profile projects, many of which are commercially sponsored. Second, even where a developer puts some legwork into letting the world know what they've shared, that effort is within the context of the project's license terms which almost universally make it explicit and clear that they profer no such obligation. Tweeting "I made this thing, check it out!" does not soemhow absolve the user from reading the license on that thing and understanding that no promises are made.
yawaramin 2y ago
You are completely wrong, and this really couldn't get any simpler. Just look at the license of the software you are using. You agreed to this license when you used the software. It says something similar to: > THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. It's not even as if this was buried under mountains of legalese. OSS licenses are usually quite simple. You have absolutely no excuse for not understanding that the software provider has zero obligation to you. All you had to do was read a few paragraphs.
lolinder 2y ago
> When you provide software that is widely used and that people rely on, you automatically created a community where fixing bugs is an obligation. What you're saying here is that "give them an inch and they'll take a mile" is not just a description of an unfortunate reality, it's a moral imperative. Give them an inch and they have a right to that mile. Do you not see how totally destructive this moral framework is? If giving away free work instantly entitles anyone who benefits from that free work to an arbitrary amount of additional free work, the only rational move for a would-be contributor is not to play the game at all. Is that really the world you want to live in?
kelnos 2y 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. No, absolutely not. What I write and release comes with no warranty, and no guarantees that any of it is fit for purpose. If people want to use it and find it useful, that's great. If they don't, that's fine too. If they use it and have problems, I'm happy to receive bug reports, but I don't work for them, and have no obligation to them. I will work on bugs and improvements because I want to, because it's fun, and because I care about my work. But when it's not fun or I don't care, I may not work on it, and that's 100% my prerogative. > 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. That's tough luck, then. Let's reframe a bit. Let's say you've decided to pay Oracle for their proprietary database. And then you find a bug in it. What are you entitled to? At best, I'd say you're entitled to a refund. Oracle actually has no obligation to fix that bug for you. But Oracle likely will want to fix that bug, because they maybe want to keep you as a customer, and develop and maintain a reputation that their software is worth the money people pay for it. Certainly some open source developers often have reputations they want to maintain. And sometimes doing the grunt work to do thankless jobs and fix annoying bugs and add features they don't care about... well, sometimes that's necessary to maintain the reputation they want to maintain. And that's fine, if that's the choice they've made. But it's also fine if someone just wants to build stuff for fun, share it with others, and continue only doing things with it that they find fun. You might look down on people like that, or be frustrated with them, or choose not to use their software, but you are not entitled to any work out of them, and they are not obligated to provide you with anything at all.
swatcoder 2y ago
> 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. As noted in VERY LARGE PRINT at the top of almost every open source license for the last thirty years or so, the person taking the free stuff is responsible for whatever happens when they do. That's why it's free! If you can support it yourself, great. If you can't, then you might need to hire someone to do so. If those options don't appeal to you, then you should probably buy an alternative that does not explicitly tell you that you're on your own. Open source software exists so that the community of reasonable, responsible people can share work with each other without being caught in a rats nest of finger pointing, liability, and defensive practices like hiding source code or preventing alteration. It is a two-sided contract, and the user's side of the contract is very explicitly to take responsiblity for what they choose to do with what they take.
kragen 2y ago
> When you provide software that is widely used and that people rely on, you automatically created a community where fixing bugs is an obligation. if you measure the solubilities of some salts and publish them, and your data is widely used and people rely on it, do you therefore have an obligation to repeat your experiments to make them more precise and correct erroneous measurements, and to extend them to more salts? i think not; i do think you have some ethical obligations, but they are limited to admitting that you were wrong, and not taking credit for others' work if the users of your work start talking to each other and helping each other, they might become a community, but that still doesn't impose an obligation on you to do more work for them. to my way of thinking, you're the person in that situation with the least ethical obligations
wiseowise 2y 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. No, just no.

Mathnerd314 2y ago

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-community-guidelines https://docs.github.com/en/site-policy/github-terms/github-c...

kragen 2y ago
they're not communities. 'community guidelines' is a marketing eyewash; those are diktats imposed by management, not some kind of decision of the 'community' at best, fecebutt and the like are fora where communities can form, as long as management tolerates them
robinsonb5 2y ago
The platforms themselves are absolutely not communities; they're a virtual location - a space - and some infrastructure within which communities can form. Any one community within is free to set its own rules and conventions (for instance, I'm on a community noticeboard group where business posts are only allowed a Monday), but those communities have absolutely no influence over the policies of the platform as a whole.
- kragen 2y ago
  and the platform often throws wrenches into their workings
wiseowise 2y ago
> 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 https://docs.github.com/en/site-policy/github-terms/github-c... Well, if they have community guidelines… this definitely makes them a community, lol.

schneems 2y ago

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.

bruce511 2y ago
Communities exist orthogonal to the project itself. They start optimally as user-groups of people who are basically peers of each other. Yes, some projects include themselves in the community. Others are involved in the community. Others set out to actively build and maintain a community. There's no one model fits all here. The ideal community has a power balance. It (can be) hard on a DHH-like figure at conferences because some percentage of folk treat it as a bug-reporting forum, or feature-request session. People don't want to get to know you, they just want your attention. I've been to "conferences" (community driven, large user groups) where the Supreme leader is there, and where they aren't. Frankly the ones where they are not there are more interesting. At conferences when they are there, the focus tends to be more on what they said (usually with gross misinterpretations) coupled with a lot of whining about what they're doing wrong. When we're "alone" it's more about the community, sharing knowledge, more positivity etc. IMO the ideal community does not centre on the project lead. It works better when the power imbalance is absent. And yes, this sometimes makes the community feel powerless (which they are). But it's still better.
tasuki 2y ago
I can easily empathise with both DHH and you! > We were resources to be exploited. This is uncharitable. DHH have you the gift of Rails. He does not want to give you the gift of participating in the community. That is okay! I don't know much about Rails, but my guess would be that DHH poured insane amounts of time, effort, and caring into Rails. Is that not enough?

kelnos 2y ago

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.

metabagel 2y ago

It’s not a democracy, but it’s a community. The act of sharing creates a community.

atlasy1 2y ago
That is not true in most people’s experience judging from previous HN threads unfortunately. Generally one or two contributors are breaking their balls doing all the work and due to a schooling created desire to inpress others are just being taken advantage of. Then thousands of freeloaders and cheerleaders riding on their back who are not even willing to donate $2 to the project demand more and more shit Eventually the contributors eventually burning out and seeing how stupid the entire thing is (I.e no longer caring what these people say or think of the project) and the project suddenly gets abandoned Two dudes creating something from a place of ego satisfaction and thousands of cheerleaders taking advantage of them is not a community
- AstralStorm 2y ago
  Unless said two guys (usually the core is up to 10) are implementing the project to work well for their own uses too. Really, FOSS exists to solve problems of the developers, with good user interface sometimes an afterthought for this particular reason, as the developer is the ultimate power user often enough. The exceptions are the true big projects, but they can end up in the 10 people situation due to sheer size of it. Those people are then usually maintainers, like in Linux. Unless the project starves due to user/developer mismatch, or gets taken over by corporate interest and people start implementing stuff neither the developers nor users actually want, sapping the energy. (I'm looking here at Mozilla Foundation specifically.)
kragen 2y ago
kind of, yeah, but dave's description of it as a gift exchange seems really on point. it's not a community in the way a village debating who should get to graze on the common is a community. it's a community in the sense that everyone has the right to use the shared resources, but that doesn't give them a vote it's a curious situation, because with naturally scarce goods like grazing land, the best we can do is control access to them fairly, so our intuitions about community come from two million years of that. but software is knowledge, not land or capital goods. it conflicts with our intuitions would you speak of the community of air-breathers, the community of users of the pythagorean theorem, the community of speakers of english? that's the kind of community we're talking about when we talk about the linux community or the rails community

KBme 2y ago

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.

Almondsetat 2y ago

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

kragen 2y ago
well. you also have to license it under an open-source license
oska 2y ago
The requirement of Free Software is to respect the four essential freedoms [1], one of which explicitly talks about 'community'. And the essay that lays out the four freedoms begins with this very line : > “Free software” means software that respects users' freedom and community. (my italics) This is why, while 'FOSS' can sometimes serve as a useful, rough grouping, the need to distinguish Free Software from Open Source is an important one. The two are not the same. The author of the submitted piece, of course, talks only about Open Source. [1] https://www.gnu.org/philosophy/free-sw.en.html#four-freedoms https://www.gnu.org/philosophy/free-sw.en.html#four-freedoms
- Almondsetat 2y ago
  Respecting community does not mean creating community. FOSS allows people to collaborate freely, it does not force people to collaborate.

openplatypus 2y ago

Please stop posting DHH bullshit. Don't amplify this troll's content.

steve_taylor 2y ago
Jason Fried really needs to rein in his barking dog. It's a bad look for the company.

braza 2y ago

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.

danmaz74 2y ago
Are you confusing ruby with rails? DHH created the latter, not the former.
- pluto_modadic 2y ago
  I think DHH tries to also speak for ruby, not just rails.
  - tinco 2y ago
    Nope, the two "communities" are largely disparate. They have different philosophies and different leadership.
- braza 2y ago
  Ruby with Rails. Just read the full article about him. Sure was the creator and I got that. But from what I heard his positions and part of the "community" not liking his ideas, what prevented someone to do a fork, let's say Ruby on Trails, and get a more community driven approach?
  - Timshel 2y ago
    I guess nothing and that kind of reinforce DHH point.

danmaz74 2y ago

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.

msteffen 2y ago

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.)

deleted 2y ago

[deleted]

litox 2y ago

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.

jillesvangurp 2y ago

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.

drbig 2y ago

> 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.