18 ms·

Entitlement in Open Source

• trpro 4y ago
  Homebrew has really wonderful maintainers. I'm mystified why anyone would get into conflict with them, but I can imagine the kind of entitled personalities who would do that. The article gives a hint: "Ironically, this is often worse coming from employed developers’ large tech companies with fantastic profit margins." This is exactly the main OSS problem right now. Entitled $BigCorp employees who churn around 1000 LOC (in OSS) per year for $250,000, engage in activism and high profile issues that will be talked about on Twitter and take credit for actually valuable contributions from idealistic individuals.
  • sneak 4y ago
    I am in conflict with them because they have similar toxic entitlement: in their case, to private user data that does not belong to them. Homebrew embeds nonconsensual Google spyware that phones home with a unique identifier supercookie every time you use it. This correlates client IPs (geolocation) and allows Google to know your travel history. Rather than asking for consent, it is on by default. They close issues about it without discussion, despite opt-out surveillance like this being deeply unethical (which is why Debian et al do not do it).
    • Etheryte 4y ago
      I think you need to check yourself here. Homebrew is giving something to the world for free, that they do it on their terms is not entitlement, it's their right. If you don't like it you can go elsewhere. You thinking that you should have some input on what terms they give their work away for free is what's nose up entitlement here.
      • sneak 4y ago
        • ehutch79 4y ago
          How exactly is it spyware? When you say that, i'm expecting to hear about keystroke loggers, or hoovering up session cookies or something.
          • capableweb 4y ago
            > Spyware is software with malicious behavior that aims to gather information about a person or organization and send it to another entity in a way that harms the user—for example, by violating their privacy or endangering their device's security Definitions vary, of course. But generally I think GA could be seen as spyware unless you tweak it by removing information.
            • akerl_ 4y ago
              > malicious behavior What’s the malicious behavior here? They’re tracking how much usage each homebrew formula has.
              • capableweb 4y ago
                The malicious behavior is gathering information about a person or organization. Opt-out makes this not great for user privacy, while opt-in would.
      • elondaits 4y ago
        For anyone wondering: Homebrew sends data to Google Analytics (https://docs.brew.sh/Analytics https://docs.brew.sh/Analytics) on installs, build breaks, and other events. It's an opt-out setting. Google Analytics violates the European privacy laws (GDPR). Although Homebrew sends a random Homebrew-only analytics user ID, Google gets access to the user's IP and behavioral data. Although Google claims to anonymize the user's IP address, laws like the GDPR intend to protect our private data even in the face of accidental leaking, hacking, and state-actors who could force Google's hand at storing and disclosing it.
        • aliqot 4y ago
          Go does this too :/
          • pdimitar 4y ago
            Do you happen to know if it's possible to deny-list a host/IP in my PiHole setup so Golang tools keep working fine but can't send analytics?
            • akerl_ 4y ago
              You don’t need anything that complex; just set GOPROXY to direct in your environment. More details here: https://proxy.golang.org/ https://proxy.golang.org/
              • pdimitar 4y ago
                It already is set to the official host plus the direct option, but does that mean it sends analytics?
                • sneak 4y ago
                  It doesn’t send any analytics. He is talking about proxy logs.
          • sneak 4y ago
      • jeltz 4y ago
        Just because you are giving away something for free does not entitle you to break the law in Europe. I am more forgiving to people who give away something for free but it is not a carte blanche, morally or legally, to act like an asshole and break the law. Spyware vendors also give away their work for free and your Facebook account is also free. Does that mean these entities can do whatever they like?
        • hk__2 4y ago
          > Spyware vendors also give away their work for free and your Facebook account is also free. Does that mean these entities can do whatever they like? Yes. (as long as they respect the law, like anybody)
      • deleted 4y ago
        [deleted]
    • wilde 4y ago
      Then don’t use it?
      • jeltz 4y ago
        I did not know about this issue until now. But, sure, if you let me borrow your time machine.
        • akerl_ 4y ago
          The first time you run homebrew, it tells you it’s going to record usage analytics, with details on how to find out more or disable that behavior.
          • JohnFen 4y ago
            But does it tell you it's using GA?
            • akerl_ 4y ago
              It tells you it’s recording usage data, and links you to the docs that show where it goes, how to view the data yourself, how to opt out, and why the collect the data: https://github.com/Homebrew/brew/blob/68e895ad4d374b4a0022613a20bd046d6487dfd9/Library/Homebrew/cmd/update-report.rb#L95 https://github.com/Homebrew/brew/blob/68e895ad4d374b4a002261... https://docs.brew.sh/Analytics https://docs.brew.sh/Analytics
    • mikemcquaid 4y ago
      Personally, I find it toxic that you insist on posting this on literally every thread I see about Homebrew. Ironically, you demonstrate my point from the article. You feel entitled to Homebrew having different analytics behaviour and in demanding the time and effort from myself or other maintainers to make it behave how you want it to.
      • sneak 4y ago
        • yakubin 4y ago
          What do you use in place of Homebrew?
          • sneak 4y ago
            Nixpkgs.
      • ctrlmeta 4y ago
        I don't see the parent comment as necessarily an entitlement. They are not demanding anything in particular from Homebrew project maintainers. They are informing us -- the readers -- about the analytics behavior in Homebrew so that we can make an informed decision about whether we should continue to use Homebrew or choose an alternative like macports or nix. It read more like a public service announcement to me.
        • mikemcquaid 4y ago
          Homebrew informs you about our analytics behaviour before we send any data with a link to the documentation (https://docs.brew.sh/Analytics https://docs.brew.sh/Analytics) which in turn links to the code on new installations and on existing ones if you haven't updated since we enabled analytics.
      • watwut 4y ago
        Personally, I find it useful when people let me know about spyware features of software - whether in open source or not.
    • zach_garwood 4y ago
  • j1elo 4y ago
    But then don't try to keep those Entitled $BigCorps out of the way, because the definition of OSS was clearly and strictly written to keep them in, otherwise you're straying out of the golden path and your software is not technically "OSS" any more... it's a complex world.
    • capableweb 4y ago
      > because the definition of OSS was clearly and strictly written to keep them in, What? No definition of OSS I know of forces you to engage with anyone at all, unless you want to. You can slap MIT on random code you write, host it on a HTML page with no further information available or interaction allowed, and that's perfectly fine OSS.
      • tpxl 4y ago
        Parent is referring to people saying licenses like SSPL are not Open Source (and they are not by some definitions).
        • ZeroGravitas 4y ago
          I think they are referring to "open source" being a corporate friendly rebranding of "Free Software". At the time it was drama about GPL which proprietary software forms didn't like but in the modern server world that isn't as relevant.
        • ensignavenger 4y ago
          The SSPL is being promoted and used by big tech companies that are selling software to other big tech companies. If it was about keeping big tech out, I think it is failing. And it isn't open source, it promotes vendor lock in and discourages successful forking. It is the antithesis of FOSS.
      • j1elo 4y ago
        The definition of OSS doesn't force you to bring someone into your house, but it does very clearly forbid you from keeping them outside.
  • KronisLV 4y ago
    > Entitled $BigCorp employees who churn around 1000 LOC (in OSS) per year for $250,000, engage in activism and high profile issues that will be talked about on Twitter and take credit for actually valuable contributions from idealistic individuals. Surely one can conceivably picture a way for letting said wealthy individuals express: "I care about this issue enough to support someone's effort that might go into fixing it." Whether that happens with a beer after the issue has been fixed, or an escrow payment of X USD with a non-refundable downpayment of Y% feels like an implementation detail.
    • deleted 4y ago
      [deleted]
• WesolyKubeczek 4y ago
  Well, if maintainers were not that reluctant to saying "no" to breaking changes, the stories like that would be few and far between. But let's be honest, maintainers do like breaking changes a lot, unless they are in stuff they themselves use. It's also not true that every single programmer is like Bob to the tee, demanding, being outraged. I've seen issues that had been closed even if the reporter was polite to the extreme. This post is trying to describe a strawman, so when you hear any complaint about your stuff breaking other stuff you imagine an entitled prick. This is not so, by far. In most cases, it's not like software is all well-oiled machine, except for that one tool. You have multiple libraries and tools that you need to combine so it all works, and because each and every one of them has quirks, bugs, defects, holes, you get to be generous with glue at places so it all works in the end. You tend to spend uncountable amount of time nudging them to work together. And all of those libraries, tools, applications, utilities are each moving at their own pace, having its own little ways, and of course having lots of stories about ungrateful users. And guess what, the vast majority of them is silent. They see how swiftly are issues being closed, they are too tired to speak up. What for? You're going to close the issue anyway. Those that speak up, usually are polite. In many cases, I've seen people going overboard only after maintainer had played dumb for a long thread of comments and refused to even understand what the problem was about. Few people go to issues to actually vent or demand. In exceedingly many cases, you may only get your bugfix that you absolutely need, but it's inevitably bundled with new features you could totally do without, and regressions which make you think that life is only about picking your poison repeatedly, until you die. In the end, all the stories of this kind end up about being egotistic pricks shouting past one another but refusing to ever listen. I lost my hope to live in a world where we are excellent to each other, but maybe being good enough to one another would be achievable, wouldn't it?
  • zugi 4y ago
    Good points but I don't interpret Bob in the story as being representative of all users who file issues, or of being an egotistic prick. Bob is one example of a seemingly-entitled user, who may be common or uncommon but certainly exists. And the article goes out of its way to sympathize with the stresses that Bob is under, and suggest alternatives that may work better for Bob and others.
• cardanome 4y ago
  I agree with the message but wish they had picked another example. If you remove a feature within just a few months of warning, users will be pissed. I think it is valid to feel frustrated about that. Its unrealistic to closely follow the development of every package you are using. Now, I am NOT saying they are entitled to a solution. I am just saying, if you declare something stable (if you don't, do whatever you want) then you are creating a certain expectation and you should be very cautious not not break the expectation. My intention is simply for the sake of the discussion to separate the two issues: There is the entitlement issue. There is also the issue of certain libraries and frameworks that keep changing things.
  • vbernat 4y ago
    It looks like the change is from an upstream software. Homebrew did communicate the change, which is something that I wouldn't expect from a distributor. In Debian, we have the NEWS file to communicate such breaking changes, but it is seldomly used because most users don't want to be spammed with changes they are not concerned with. Bothering the distributor for changes in upstream software was OK ten years ago. Today, it is not: too many upstreams, not enough people to curate and maintain.
  • zimbatm 4y ago
    That's the life of the package maintainer. You get grief from users that complain about upstream issues, and upstream that doesn't like you reporting issues to them.
  • pdimitar 4y ago
    > Its unrealistic to closely follow the development of every package you are using. It's very realistic and viable for huge corps with infinite pockets for dev budgets. I worked only a handful of times for huge corps. The better ones had extremely hygienic and structured approach to relying on open-source, namely they were inspecting CHANGELOGs and were testing carefully before each version bump. And they were quite right to do so. It should go without saying that when you get stuff for free you get zero guarantees. You gotta guarantee things yourself. Today it works, tomorrow a new version comes out that might break your software. Update at your own discretion and pace. RE: your last line, if you truly need a piece of software but its maintainers change things too often then, well, it's time to roll up your sleeves and write your own. Again, huge corps can afford that.
• EGreg 4y ago
  Seems like the real problem, as it often is, is package and version management. Besides the open source authors and maintainers, has anyone considered that “distros” of open source is a thing? Companies have sysadmins and distributors may have a bit more time to manage exactly these expectations. Why is Bob being affected just because Homebrew made breaking changes in a new version, especially if they used semver? Probably because someone in Bob’s organization, whose job it is to watch for these deprecation notices, doesn’t have the information that Bob is relying on the old behavior. Yet Bob is somehow forced to upgrade to the new Homebrew because the organization “needs” everyone in the company to run the latest and greatest. Well, that issue is between Bob and his company’s sysadmins. And those people should have some knowledge of what changes break what. Actually, what would be nice is some sort of automatic AND STANDARDIZED tool that shows which interfaces are used by which clients in your organization (CLI, ABI, API, etc.) and what an upgrade would entail. Does such a tool exist ?
  • hobofan 4y ago
    I think the closest you will find to this would (monorepo) build tools like Bazel or nix where due to their enforcement of hermeticity all used interfaces have to explicitly specified and their implementations pulled in. This coupled with the build graph then allows you to determine which downstream projects would be affected if you were to upgrade the version of the product.
  • esarbe 4y ago
    I disagree. The problem is the tendency of companies to make use of free/open source software, to build on its functionality and to not contribute back. If that was the case - if every company returned some of the profits they make by building their business on free/open source software - then the ecosystem would have enough resources to avoid such situations. But capitalistic businesses will do the capitalism thing and instead take all the benefit while bearing none of the costs. And when something breaks they cry and feel entitled to remuneration. That's why free/open source software and capitalism are incompatible; free/open source assums that everyone is that is able to is also willing to contribute. Capitalism assumes that it's fine to absorb all the from other's work.
• svnpenn 4y ago
  two things I did cut this way, way down. For my most popular repo: - changed to Noncommercial License [1] - charge for issues. 9 USD or I close immediately. If someone posts something that is a genuine concern, I will address it. However minor issues or feature requests, you're on your own, unless you want to pay for my time. 1. https://polyformproject.org/licenses/noncommercial/1.0.0 https://polyformproject.org/licenses/noncommercial/1.0.0
  • capableweb 4y ago
    "The way I solved Entitlement in Open Source was to not do Open Source anymore" I mean, that's great, if that works for you. But it's hardly a solution to the open source ecosystem, as if everyone moved to a noncommercial license, it wouldn't be open source anymore.
    • svnpenn 4y ago
      sorry you feel that way, but I don't agree. The source is online, people are free to download, look at it, and use it for any non-commercial purpose. If they want commercial use, then I sell that license. You seem to parrot the typical business line of "business cant use it for free, so its not open source!". I don't accept that line of thinking.
      • ctrlmeta 4y ago
        Opensource has a specific definition and the definition includes: > The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research. So if businesses cannot use it for commerical purpose, that's not open source literally by definition. It is not about what your line of thinking is. Words have meaning and "opensource" has a specific meaning. If you want to talk about software that must not be used for commercial purpose, there is a specific word for it too and the word is "noncommercial" which is not the same thing as "opensource".
        • 4y ago
• volleygman180 4y ago
  Great read and points to consider. In a similar, yet different, set of circumstances, what are reasonable expectations when you're an indie developer? And instead of it being an OSS Homebrew solution, it is an OSS library on GitHub that accepts sponsoring (and you've sponsored them before, simply because you get value from the library and want to show your gratitude)? It's easy to hate on the big tech corp who doesn't pay for what they use, but what about the indie dev (and especially if they have paid)?
• elondaits 4y ago
  I think the story in the article is related to a big issue with Homebrew that's not so related to entitlement but to expectations: Homebrew's philosophy and default behavior is to keep everything updated to the latest version. This makes it OK (sort-of, at least) for day-to-day tools and utilities... but not ideal for systems. I've been personally bitten by this before, where a Python script no longer runs because a library (libssl, I think) was updated to a new non-compatible version and one of Python's modules depended on it. This update in particular was caused by installing something else, unrelated to the program or project. ... So now I know this and try to use different ways of installing my projects' dependencies (and have disabled auto-updates). But a lot of people come across Homebrew when googling "how to run <blank> on MacOS", as it's the default recommendation everywhere. This is not necessarily Homebrew's fault or responsibility... but often there's a communication gap between maintainers who assume everyone should keep software up to date dealing with whatever breaking changes are published and announced and people who live on a completely different schedule and might be wondering why the script they run quarterly no longer works. This issue is not exclusive to Homebrew, I think. Modern development (specially things like node.js / front-end) moves at its own fast pace, and long-term support is not its concern (or not long enough). Hopefully a healthier culture of long-term software maintenance will emerge, with patterns and practices that can be adopted to align everyone's expectations and obligations.
  • franciscop 4y ago
    "Hopefully a healthier culture of long-term software maintenance will emerge" What would the open source author's motivation to do so? This takes effort and money, and I would daresay in no small amounts. And even "the markets" seem to reward software that is constantly improved and has news, heck MANY developers consider metrics like "last release date" to judge whether to use a project or not! Open Source is usually free, so the projects that DO offer LTS are pretty rare and usually well-funded like Node.js on itself, Ubuntu, etc.
    • elondaits 4y ago
      There were many steps in the right direction in the past years: - Semantic versioning - The concept of LTS (long term support) versions (e.g. node.js) - Github simplifies forking, submitting patches, or sending issues. - Tests + CI announce when changes break things. Semver is sometimes unreliable, and LTSs are sometimes too short-lived for certain projects... but it's not for lack of motivation from the authors. It's an ongoing process and I expect things to improve. The development of a culture and practices makes it easier for everyone to do the right thing with less effort.
• GnarfGnarf 4y ago
  At the risk of being downvoted, this illustrates why paying for software is sometimes cheaper than "free" software.
  • madeofpalk 4y ago
    Why would this be downvoted? Isn't this the whole point of the story?
  • bheadmaster 4y ago
    > paying for software is sometimes cheaper than "free" software Note that the original meaning of the term "Free Software" refers to liberty, not price: https://www.gnu.org/philosophy/free-sw.en.html https://www.gnu.org/philosophy/free-sw.en.html
    • GnarfGnarf 4y ago
      Can you show me an example of "free"-as-in-liberty software, that the creator(s) nevertheless charge(s) money for?
      • cercatrova 4y ago
        Anything that is dual licensed GPL or AGPL along with a commercial license.
      • marcus0x62 4y ago
        Cygnus was the canonical example for a long time - they heavily contributed to the GNU developer tool chain in the 90’s and made money selling support contracts to corporate users.
      • bheadmaster 4y ago
        Qt uses a double-licensing model - they provide their software with GPL license (which requires all derivative software to also be GPL), while selling commercial license for money (which allows derivative software to be proprietary).
      • 4y ago
• djoldman 4y ago
  I believe the crux of this topic is way down in the piece: > The problem is that these generalities turn into expectations of behaviour, those expectations turn into entitlement and entitlement turns into toxic behaviour that makes maintainers quit open source. From the maintainer point of view: you cannot control your users, you can only control yourself. Therefore the solution is to use whatever tools at your disposal to guard against whatever is facilitating the transition from "toxic behavior" to "makes maintainers quit open source." If maintainers can't avoid getting upset when users complain, there really isn't much to be done.
  • andersource 4y ago
    Maybe I'm misunderstanding your comment, but it sounds (to me) like you're putting the onus on the maintainers, as if it's their obligation to contribute to OS and their inability to not be upset stands in the way of performing their obligation. Many OS maintainers derive joy (and motivation) from knowing that their work is useful and beneficial to others. Users acting entitled isn't "upsetting" in the same sense as a rude stranger is upsetting - it makes the maintainers feel unappreciated and nullifies their source of joy from working on OS. I agree that everyone would always benefit from being more emotionally resilient because there will always be negative behavior around us, but strongly disagree that nothing should / can be done from OS users' perspective.
    • djoldman 4y ago
      I mean that maintainers (and users) have zero obligation to maintain or contribute to anything in almost all cases. If a user is "toxic" or otherwise isn't contributing something of value to the project, then maintainers need to learn how to deal with it emotionally or otherwise. As the article says: "Just say no" is a good place to start.
    • Bakary 4y ago
      The first step is to acknowledge that just because a comment or message exists, doesn't mean you have to consider or respond to it. Bob is just one user amongst many, but the fact that he manifested himself through an issue means that he took over disproportionate mental space compared to the mass of silent users.
• that_guy_iain 4y ago
  It feels like these blog posts come out at least once a year. To me, the issue comes down to the fact that companies are fundamentally relying on software that comes with no promises of support or a warranty. I honestly can't think of another industry that relies so heavily on things they get for free and come with no warranty. So many people act like Open Source is great. But often the love for open source often only goes as far as to say thanks when they're creating a bug report or when they're getting the software for free. Every company I've worked at has used open source code. Only one of them open sourced their code. Many non-decision makers wanted to do open source code but it was never given any time so it would always come down to "You can do it in your free time and release it under our name". So again the company wants free things that benefit them. Personally, I think the way forward is source available. I have a SaaS boilerplate/product framework thing that I'm releasing under the Business Source License where it's free to use for non production and free for folk generating less than $5,000 a month to use in production[1]. To me this provides the best of both worlds, people who aren't making money can use it for free but those who are using it to generate money need to pay to help fund the development. Free users get best efforts in support and paying customers get priority support. I think if it relies on people paying what they can afford it results in many not paying at all even though they can afford it. [1] https://github.com/getparthenon/parthenon#faq https://github.com/getparthenon/parthenon#faq
  • guggleet 4y ago
    > Every company I've worked at has used open source code. Only one of them open sourced their code. Did they have code worth distributing and opening for contribution? It seems like most code I encounter in enterprise environments doesn't really fit those needs.
    • that_guy_iain 4y ago
      I would say one or two had something they could have made available. The one place I worked that did open source code, it was decided very early on it was to be open sourced so it built in a way to make it open source.
  • 4y ago
• traverseda 4y ago
  Epistemic Status: Just musing out loud, I'm not sure I even believe this but it's one approach to the problem. Open source software has some pretty severe networks effects. There's only so many people who are going to maintain a package for MacOs, in affect different package managers are going to be competing for those volunteer maintainers, and there's a pretty big first mover advantage. (there's only one wikipedia, despite it being pretty easy to make a new wiki, volunteers are the resource projects compete over) If you're an open source maintainer who's part of a project driven largely by volunteer labor like this, well you've got to consider the fact that your project existing means that other project will have a lot harder time getting started. It's not as simple as "we're all volunteers so be thankful for what you get" because just by existing your project is consuming a finite resource, volunteers, sponsorships, awareness, etc. Your project existing might be taking up space that a much better project could fill. Of course if it's that much better it probably will eventually anyway, but still. So I don't know, try to make sure your project is the best it could be, and try to build something that will last rather than chasing new features? I hear a lot about entitlement in open source, but with some projects I do wonder if we'd be better off if they just collapsed, and the sponsorships and volunteers moved to a different project. Not homebrew, I don't use homebrew but from what I hear it's all around decent, but there are a few open source projects that have become de-facto standards that I do wish just go phased out. When X11 stopped being maintained in favour of wayland that forced a bunch of your fellow open source developers to make a bunch of changes to their code, foisted a maintenance burden on them. That's fine, things do change, but try to make it easy on them ( https://gitlab.gnome.org/GNOME/mutter/-/issues/217#note_355246 https://gitlab.gnome.org/GNOME/mutter/-/issues/217#note_3552... for example). In a sense, isn't any kind of expectation you could have for open-source software entitlement? If your FOSS doesn't come loaded up with malware, crypto-miners, and a servo motor to punch you in the genitals, should you be thankful since it was free? What if it just comes with the malware? I'd like to see some kind of social contract "maintainer responsibilities" that lists out what users are allowed to expect before they start getting called entitled. There's some basic stuff, like it being free from active malware and viruses. There's some more questionable stuff, like CVEs or some other method to subscribe to security warnings. There's probably some miscellaneous stuff, like being able to get old versions of the software (not having the author go out of their way to remove old versions like what happened with the infamous NPM left-pad story) and all kinds of other stuff I'm not thinking of.
• orliesaurus 4y ago
  I work in open source, as a hobby, I made roughly $200 in donations in 10 or so years. I also know the feeling of people getting mad when I make a change that I believe it is good but others (users) hate it. I agree and would like to echo chamber the issue that for every maintainer there are thousands of users that don't give back anything, not even a thank you. I think our reliance on github causes us to have inefficient or ineffective tools to promote good opensource. I think github sponsors has been a good idea but its execution is extremely poor. (Tl;dr it is ineffective and doesn't plug in the rest of the echo system) There is some psychological aspect for sure in using open source code and not paying for it: the moment you pay you expect some entitlement over support and direction of the project, but I am know psychologist. That being said this blogpost is great, but nothing ever changes as a result, sadly.
• timssopomo 4y ago
  This isn't unique to open source, the behaviors described are easily recognizable to anyone interacting with end users of SaaS or, really, any software. It does not matter how well things are communicated and how much effort goes in to change management, _someone_ will ignore the communication and insist that changes be reverted. If you're interacting with users, it's important to publish crisp and defensible promises to end users and deliver on them (when these promises are backed by a contract, they're an SLA). Boundary setting is as much about what you will do, and delivering consistently, as it is about being comfortable saying no when the error is the user's. Stating clearly what you expect people to do (sign up for this email list, upgrade on this cadence) goes a very long way. Policies and promises stated and delivered are usually enough to get people past the anger phase of grief to bargaining, which makes the interaction a lot easier to manage.
  • _tom_ 4y ago
    This is correct. The only difference between this and commercial software is the user expects a fix for free. No commercial vendor is going to revert an important change for a customer giving them zero money. If you are paying them millions, then sure. Open source can be the same. Offer Reem millions, your problem will likely get fixed. Even a low bug bounty might work. But, exactly like commercial software, people won't break lots of users to fix one user without a lot of motivation.
• zajio1am 4y ago
  One way to handle entitled users is to offer paid support option. We did that in BIRD project: https://bird.network.cz/?support https://bird.network.cz/?support
  • zricethezav 4y ago
    I'm doing something similar with gitleaks: https://gitleaks.io/support.html https://gitleaks.io/support.html So far it's working out great.
• Bakary 4y ago
  This article touches upon a very important part of human nature that becomes increasingly counter-intuitive as you go along. First of all, people will define things as valuable if they bring utility to their lives. But the perception of value of a thing is influenced to a disproportionate degree by the perception of its availability and scarcity. Almost everyone learns this sooner or later. We also have the dichotomy between the moral perception of a job and its salary. Most people feel that [insert should be paid more and star athletes less (at least until comes the time to pay for that through taxation). Most people feel aggrieved that they are paid less than their fellow employees in the same company just because they live in a poorer country. We see the value a profession brings and feel there is something wrong. But to the holder of the purse strings, your value is determined by the ease of your replacement, not the value you actually bring in terms of utility. Capitalism increases the speed at which this adjustment takes place, but it would still happen in a pre-capitalistic society. I would say most people, but not all, are both aware of this and inform their decisions by it, even if it's via a cultural mechanism such as seeking out hard-to-replace professions. And there is the more insidious example that your value as a human being is evaluated not just based on how useful or impressive you are but how difficult it is to access your time, energy, and preference. You have the classic example of a person regularly brewing coffee at the workplace. They mistakenly believe that doing something nice and useful leads to being valued. In reality, their coworkers now take the coffee brewing for granted. They do not respect the coworker more than before, and possibly respect them less because they consciously or subconsciously see their time as less valuable. If the employee in question catches on and stops providing that service, their coworkers are now unhappy with them, which is the opposite of the initial objective. Of course, this is just an illustrative example and life doesn't play out the same way every time. But holding the general belief that people will consistently respond positively to spontaneously provided services is not adaptive because it ignores social status in favor of an illusion of moral reasoning and actual utility. In fact, you could argue with the coffee brewing example that it's a case of trying to sign people on to unrequited contracts, where you do something nice and thus believe they owe you when the premise is that they never asked for anything to begin with. In the example in the article, something similar is at play. People use FOSS stuff because they have a problem they need to solve and see a free resource to help with that. But because it's so free and accessible, there is less automatic respect for the code and its maintainer than could be expected. The key aspect is that people like Bob don't even need to be an asshole or an unreliable worker to gain this sense of entitlement as it is just a natural mechanism that does not require bad intentions. The coping strategies the article cites are all great, but they focus on the angle of self-care and self-respect, which is only the first step in the equation. The final calculus should also take into account the reality of social status and the perception of availability. You do not get treated well because you are useful, but because you are perceived as a scarce resource whether it's true or not.
• falcolas 4y ago
  Exploring this thought. Most of the time this argument surfaces, it’s from developers who are being paid (donations, salary, grants, etc) to work on the software. Why do we expect different behavior from end users just because the output carries the OSS designation? If you’re getting paid to work on software, you should give a damn about your users, since without them you wouldn’t be getting paid. And it’s not like working on OSS is some kind of sacrifice; it’s not like paid work on an OSS project prevents you from also getting a job at a place like Google.
  • nerdponx 4y ago
    The article is describing the opposite situation, where the contributors and maintainers are unpaid volunteers, while the end users are paid employees of some company. Moreover, the article is describing the specific but sadly common situation of a maintainer caring too much about their users, past the point where it makes sense to care about them, leading to maintainer disillusionment and burn out.
    • falcolas 4y ago
      The article is written by the primary contributor to homebrew and based off the author's interactions with users. Homebrew does indeed have both sponsors and donations... https://github.com/homebrew/brew#donations https://github.com/homebrew/brew#donations And I find it beyond credibility to believe that the primary contributor is not taking any money for his work on homebrew. Because while homebrew undoubtedly costs some money to host, a vast majority of the hosting is done using GitHub's public repositories.
      • nerdponx 4y ago
        Right, and if the company depending on Homebrew had entered into a paid support contract, things would be very different. It's very clear that they do already give quite a lot of a damn about their users. I don't see how are you could get an impression otherwise. There are plenty of examples of organizations that do not give a damn about their users, but this is absolutely not one of them. Your argument seems to be something along the lines of "somebody at some point is paying them for some amount of the work they do on this product, therefore it is their duty to cater to every end-user complaint and request, no matter how capricious, misinformed, or selfish". I don't agree with that premise at all and I suspect that most other people wouldn't either.
• cercatrova 4y ago
  I've read so many posts like this on HN. The crux of the issue is that, in my opinion, maintainers need to grow a spine regarding entitled user behavior. If someone opens an issue, and it's not currently in your backlog, tell them to pay up to move to further ahead in the backlog. Cite your hourly or per-issue rate. If people don't want to pay, they can go elsewhere. You kill two birds with one stone, either they leave or they pay you, both likely good outcomes for you. But simply doing it for free based on their whims just encourages entitled behavior, and that is how one burns out. Having worked retail, I know how customers will act when entitled, and with maintainers, it is abundantly clear who has also worked retail and who has not based on their ability to handle user entitlement.
  • nerdponx 4y ago
    I mostly agree, but there seems to be a persistent problem where software authors and maintainers don't have a good communication channels to reach end-users. The only thing that seems to work consistently is embedding deprecation warnings directly in the software. Asking people to subscribe to some enormous mailing list that covers thousands of releases of thousands of different products, or to keep an eye on a forum that gets hundreds of post today, is not really fair to the end-user. It's easy to end up feeling like Arthur Dent: your house is about to be destroyed to build a highway, and while technically there was a long notice process, the process was not conducted in a way that you would ever have known about it. Homebrew is an interesting case because they do actually have a system in the package manager that displays a "caveat" to the user after installation. The maintainer probably could have added a warning there, before bumping the package version. None of this should be taken to excuse a for-profit corporation failing to give even the faintest whiff of a shit about auditing The tools that they depend on, let alone taking some ownership and responsibility thereof. But I do think we as an industry in general should spend some time thinking about this communication channel problem, because it can bite even vigilant, well-intentioned users now and then. Of course, one could also point the finger at the "rolling" release model that Homebrew uses as an extra source of difficulty in this arena, but I am more willing to blame the end-user in that case as well, because they ought to know what they are signing up for when using a rolling release package manager.
• bdw5204 4y ago
  With open source projects, you are "entitled" to do the following if you have a problem with the software: 1) Submit a bug report to the maintainer. The maintainer is free to choose whether to fix the bug, add it to the backlog of bugs to fix eventually or mark it as won't fix. 2) Fix the bug yourself. If you do this, you should offer the code to the maintainer. If they don't want it, you are free to fork the code and merge future releases into your fork. The task of doing such merges gets exponentially more difficult as the delta between your software and the original software you forked grows. 3) You can pay the maintainer or somebody else to fix it for you. This can involve paying for a support contract or a one-off payment. The maintainer still has the right to turn down your offer of money either because she feels the money is insufficient or because she feels that what you consider a bug is actually an important feature that shouldn't be removed (in the latter case, you can hire somebody else to fix it for you and fork it). 4) You can find a way to live with the bug. 5) You can find a different program to replace the program. What you do not have is the "right" to demand that somebody perform any kind of work for you without mutually acceptable compensation or the "right" to send abusive messages to the developer(s) of the software. That kind of stuff shouldn't be tolerated especially when it is coming from corporations that employ skilled professionals who could just fix the bug or could easily just pay the maintainer to fix it.
  • pessimizer 4y ago
    > the "right" to send abusive messages to the developer(s) of the software. This is not a right that is granted by software license, everybody has it. They can send you abusive messages even if you don't have a software project, unless there is illegal content in the message or there has been a court order.
• beckman466 4y ago
  what about 'Entitlement in Closed Source'?
  • hk__2 4y ago
    The article talks about Open Source, but it’s more about free software (as in "free beer") in general, either open or closed source.
    • beckman466 4y ago
      yeah, sorry, i understood. i think in my mind i was referring to Bill Gates's letter to hobbyists (which is basically that), thanks for the clarification
• gumby 4y ago
  I feel for the person who wrote this rant but this exact problem has existed since the 80s (early days of the GNU project) and surely forever in other domains. Most people just think of themselves.* On this topic I often mention bfox’s canned response to complaints about bash: “Please return your copy of bash for a full refund” * remember this when writing a marketing campaign, pitch letter, or for that matter a report for your boss.
• thenerdhead 4y ago
  Entitlement will continue as the world adopts OSS further and everything is built on the shoulders of giants. People are lazy by nature and more willing to complain than send a PR or detailed enough issue for a maintainer to pickup. The challenge I see is that maintainers shift their mindsets from the labor of love to be one that should be compensated accordingly. I wonder why and when that tends to happen? I have guesses, but mostly think it's a boundary issue. The article basically nails the last point that seems overlooked on many of these projects: > Finally, maintainers need to learn to say “no” again and again. No to new features. No to breaking changes. No to working on holiday. No to fixing issues or merging pull requests from people who are being unpleasant. No to demands that something has to be fixed right now. There's definitely pressure from the world stage to say "Yes" to everything, but that's the trap that I think many maintainers fall into into trying appeasing the whole world and feeling fed up after they've had enough.
• golemotron 4y ago
  In the early days of OSS everyone who was a user was a developer and if you didn't like something, you fixed it (or forked and fixed it) and moved on. That's the answer really. An OSS user is not a customer. Acting like an entitled customer should get you nowhere. There are paid models for that sort of behavior.
• pdonis 4y ago
  While I'm generally sympathetic to the points made in the article, I think one statement it makes is misguided: "[R]emember and really deeply internalise the fact that you can stop working on any open source project at any time. Open source maintenance is a job and, like a job, when it stops working for you and you have better options, you can go elsewhere. You should not feel bad about this; instead, you should feel good about the fact that every contribution you continue to make or made in the past were good deeds given freely to others. When your life or the project means it no longer feels good to work on it anymore — stop." Actually, the fact that you can just stop working on any open source project at any time, regardless of how many users it has, means that an open source project is not a job. In an actual job, you cannot just walk away whenever you feel like it, because someone is paying you to do the work, and you have some kind of actual agreement with whoever is paying you that you can't just break if you feel like it. If nobody is paying you for your open source software, it's not a job. I emphasize that I am not saying that working on your own open source project in your own free time should be a job where you can't just stop when you feel like it. As long as the situation is made clear to your users, then it's on them to deal with it. But that very fact means that you should not be describing it as a job, because it's not. Your relationship with your users is not the same as it would be if the software were your actual job and you were being paid for it.
  • phkahler 4y ago
    >> an open source project is not a job. In an actual job, you cannot just walk away whenever you feel like it, because someone is paying you to do the work, and you have some kind of actual agreement with whoever is paying you that you can't just break if you feel like it. What country are you in? People quit paying jobs all the time. Most employment in the U.S. is "at will" which is usually used to mean "we can fire you at any time for any reason" but the flip side is "I can walk away at any time" and people do. In some cases enough people quit a company that it can't continue and closes down.
    • pdonis 4y ago
      A job doesn't have to be paid "at will" employment working for a company. You might be a founder of the company, and the company might have contracts with paying customers. You might be an independent contractor with contractual agreements with clients. Contractual agreements of that sort that involve open source software are the situations where open source software would be your job. But with Homebrew, none of this is the case; Homebrew does not have paying users, and the organization the project is a part of is a nonprofit that has no contractual agreements with anyone regarding the project, and does not pay employees to work on it--the project maintainers are all unpaid volunteers. Such a situation is typical for open source projects, and in such a situation, the project is not anyone's job because no one has any binding commitments to it. Even in the case of "at will" employment with a company, an employee generally can't quit with zero notice; there is some kind of notification period, even if it's only a week or two. But in any case, in such a situation, the company is highly unlikely to be providing open source software that many other users depend on; and even if it were, the contractual agreements with paying users, if any, would be the company's, not the employees'. So even if the employee might be able to say they can just walk away from a "job", the company can't. The company has binding commitments that it will suffer penalties for breaking; those commitments are the company's job. And if the company doesn't have any such binding commitments, then providing that open source software is not the company's job, any more than providing Homebrew is the Homebrew volunteers' job. It's something they do because they feel like it.
• abiro 4y ago
  Maintainers complaining about entitled user behavior implies a business opportunity for an enterprise version of the software.
  • zricethezav 4y ago
    I recently tried my hand in commercializing my open source project, gitleaks (http://gitleaks.io http://gitleaks.io). I'm keeping the core gitleaks project MIT but changed the gitleaks-action on GitHub to a commercial license. Revenue from the commercial license and maintenance agreements has netted me much more than donations I've received over the past couple years. I encourage any open source maintainer to try and find a business model (plugin, dual license, enterprise support, etc) for their project. FWIW, here is a blog post explaining the rationale behind starting an LLC https://blog.gitleaks.io/gitleaks-llc-announcement-d7d06a52e801 https://blog.gitleaks.io/gitleaks-llc-announcement-d7d06a52e...
    • abiro 4y ago
      I like what Material for Mkdocs did as well. They ship features to sponsors first and release for free when a certain founding goal is met: https://squidfunk.github.io/mkdocs-material/insiders/ https://squidfunk.github.io/mkdocs-material/insiders/ Roughly 10xed their sponsorship revenue in ~1 year.
      • squidfunk 4y ago
        Maintainer of Material for MkDocs here. Correct! The Sponsorware strategy is an alternative to dual-licensing which works fairly well for our project. If you have a successful Open Source project that is a pain killer and product-market fit, this strategy might also work for your project.
• carapace 4y ago
  This is why I feel like it's important to maintain the distinction between "Open Source" software and "Free Software" even though, as a Free software die-hard I have to admit it seems like we have failed. The original idea of Free software started when RMS wanted to fix a printer. Xerox said "no", and the the rest is history. AFAIK the idea of "Open Source" started as a way to make Free Software more palatable to commercial interests. Businesses wanted to develop commercial advantages and not share them with everybody else. I have no idea personally why anyone ever thought this was a worthwhile thing to do, but then there's a lot of human behavior that I find puzzling. In any event, from my POV, we can trace entitlement in Open Source software to it's very root: the whole point was to enable people to use the software without contributing anything back. Originally, the idea with Free Software was that programmers would charge money for making improvements and fixing bugs. (The idea of charging for copies of already-written software is not excluded, it's fine if you can pull it off.) I personally figured we would program the computers to do all the work and more-or-less retire in a techno-utopian Star Trek scenario. (Again, from my POV I don't know why everybody isn't on board with this: "Let the robots do the work and we'll take their pay.") To sum up, the whole "Open Source" movement (as distinct from the "Free Software" movement) is kind of self-contradictory: business has been encouraged to take advantage of the freely-available "Open" software, and so they did. But then the culture became one of entitlement (as contrasted with the contribution-based culture of the GPL).
• palisade 4y ago
  I see this from a different perspective. The developer using the API or tool has a valid expectation that their software should continue to work as-is for years even as outside changes are made to the underlying tools, libraries and features. The flaw here is instead, in my opinion, a willingness on the providers of these tools and libraries to pull the rug out quite frequently on their end users. If there is a security risk, you can mitigate that by redirecting your users who still use the feature to what I'll call a "diversion" along with a warning that they will no longer receive updates and to consider the feature obsolete. Perhaps with a popup or console blurb that warns the user of the problem, this way the end user developers eventually do have to fix it because users will bother them about the issue. I understand it creates clutter that maintainers would like to avoid, but the alternative is constant rug pulling that undermines productivity and the usefulness of your tool or library. You created your software or tool to help others whether for financial gain, altruism or ego boosting. I think you forget that when you decide to throw your hands in the air and rug pull. It is irresponsible and lazy. You are shirking your duties onto others. We need a new system, process or design pattern to help alleviate this issue in our industry. Because end user developers and system or library developers are constantly butting heads over this. There is a strong smell here that needs to be resolved. It is a problem in search of a solution. I think we can potentially engineer our way out of this. For example, if you developed software for the first Google Android phone, it no longer works on the latest phone. It should. Why wouldn't it? I wrote a piano app that no longer works, it would require a full rewrite and recompile. And, this isn't just between an ancient version and a new version of the phone. Just one SDK update and they've suddenly changed all of the interface names, function arguments, etc. Just because they thought a name sounded cooler or clearer. This is irresponsible design. Microsoft does a great job with their APIs being backwards compatible as much as possible. But, the cost is having to carry a massive history of APIs and tools they can never truly sunset. If you develop something for the first DirectX SDK it still works on the latest release. Because, they number their interface names. I'm not saying this is the ultimate solution, but it is one way to address the problem. But, it has problems of its own. I'd like to see a large effort to address this, we keep avoiding it as an industry.
  • compiler-guy 4y ago
    "You are shirking your duties onto others." That might be true if you had a duty to them. But you don't.
• BirAdam 4y ago
  Personally, I have felt that the current rate of software development across the entire industry is impossible to maintain long term. People are writing software faster than QA can happen, nothing is ever truly stable, and everything is always broken. Software is a fluid that will always expand to fill its container. That said, it's also true that software mostly works which is something I cannot say for software in the 90s. I suppose this one of those "miracles" of the industry. I personally hate the direction the industry is going though. Stuff seems to change constantly for no reason, desktop software is mostly just chrome in some form or another, and SaaS is eating everything. The only stuff that doesn't do this seems to be FLOSS, so I use it. It may be time for me to sharpen other skills and make a career change, I dunno.
  • ollien 4y ago
    > People are writing software faster than QA can happen That's _if_ things are QA'd thoroughly, or at all. It's definitely something we're seeing less of.
• unity1001 4y ago
  "deprecation" kills Open Source projects, ecosystems, even private services. The people don't like to build their businesses, livelihoods on shaky ground that can collapse from under them at any point just by the decision of some maintainers who are doing something as a side-activity. This seems to stem from the academic roots of Open Source. It grew from such projects in academic environments where deprecation of something would not cause anyone's business to collapse. Amplified by its adoption in large organizations in which deprecations don't cause major disruption and the organization would have ample time and funding to address these anyways. This mentality even afflicts and hampers large private organizations - take Google: A culture that has grown from its academic roots in MIT, where the funding mainly comes from the government or large military/private organizations. Carried over to the larger organization of Google as it matured, where there was ample funding and time for addressing such 'deprecations'. All good. But they kept behaving towards their end-users in the same way. Constant 'deprecations', shutting down entire services on people's faces with little notice, literally giving a jolt to their small businesses, organizations, even livelihoods. Then they started noticing people earlier. But this didn't change a thing because the general public don't have the funding and resources that Google has for addressing such 'deprecations'. So people started trusting Google. To such an extent that Google Cloud cannot get people on board even as their execs openly promise stability to the customers. Because nobody believes them anymore. https://steve-yegge.medium.com/dear-google-cloud-your-deprecation-policy-is-killing-you-ee7525dc05dc https://steve-yegge.medium.com/dear-google-cloud-your-deprec... Actually, turns out Google itself also doesn't have such resources. As evidenced by the recent 'inefficiency' talk that they gave to the company. So much engineering. But not enough product, in the face of a tech sector that is increasingly imperiled by rising inflation and dire economic times that do not permit floating organizations on overvalued stocks... ... If even Google suffers from this kind of 'deprecation' behavior, imagine how much general Open Source suffers from this. Obscure feature or security updates causing backwards-incompatible changes and breaking entire software setups, small businesses and individuals having to dedicate considerable time to maintaining their software as if they were software engineers who were doing it as a hobby. That's what's hampering Open Source. Treating everyone as if they were software engineers using the Open Source software on the side, as a hobby. They aren't. They are people, a lot of them non-technical, with real lives, businesses and livelihoods that hang on that software. And that is the major reason why Open Source keeps losing ground to proprietary, closed-ecosystem services that just give the users what they need to run their businesses and their daily lives without having to deal with Open Source maintenance problems. So... > The lifeblood of volunteer-run open source projects, which is most of them, is ultimately the motivation of the maintainers who work on them No, the lifeblood of volunteer-run open source projects are their users. If there aren't users, there is absolutely no point to an Open Source software other than being a hobby for those who get involved in it. The users include corporate or intra-organization users too, by the way. With such a mentality, Open Source can never change the world. Instead it would just keep losing ground or stagnating compared to closed-source private services and ecosystems that prioritize their users.
• ChrisMarshallNY 4y ago
  I use Homebrew frequently. It's quite useful, so thanks, Mr. McQ. It's not an "I can't live without" utility, but it is one that I'm glad to have, occasionally (a lot of CLI tools and whatnot, are best installed via HB). I've been doing open source for a couple of decades (at least). The only real "hit" that I wrote, is now out of my bailiwick, and alive and well, in the hands of a great team. I have encountered some fairly bad behavior, in my time, but having massive scale, and being deluged by requests, has not been an issue for me (which is just fine). As far as I know, no one has taken anything I've written, and made themselves rich on it. I release my stuff as MIT (generally), so there's nothing I can do, if they do that. I just tend to write stuff that is "the same, but better," as opposed to "new paradigm" stuff. "Better" doesn't actually seem to mean much to folks, which makes me a bit sad.
• lamontcg 4y ago
  When people don't pay for anything they have no leverage and a lot of people turn into assholes to try to get their way. Generally issues that come in through paid support where people know they're going to get worked on are a whole lot more neutral or positive. Issues that come in through the public GH tracker have a strong tendency to get passive aggressive really quickly.
• unixbane 4y ago
  First of all, we have this blog post at least once a year, like top commenter has said. Second, uh, no, you're a moron. Open source now is just completely commercialized. Firefox looks exactly like a 90s garbage web browser that shows you some stupid page full of ads, and links to news with ads, on startup. I am an open source developer. I don't expect any gratitude for what I do, I just want to get shit done. People who pretend issues don't exist are annoying. If I am using a typical open source library these days, I expect it to be made by some guy developing it as if it's his job (and accordingly, with lots of corner cutting). Basically all these new sprawl of languages are a stack of half working bullshit from the build system to the GUI all made for clout or on a whim based on some idea thought of last night, or by some extremely inexperienced person. And the only reason none of this stuff works well is because open source devs are literally clout chasing and constantly move all their dependencies (also fixing invalid problems that shouldn't exist like RCE bugs). You're right, I shouldn't expect them to work at all. I didn't even read your article, I have better things to do. The idea that people are "entitled" in tech is retarded and no spin on your title can make sense. Tech is a sea of festering rot piled up 100 times.
• gautamdivgi 4y ago
  The problem is bigger and I think “Bob” can be very damaging to “Reem”. If “Bob” ever threw a tantrum on the issue board while “Reem” quietly and politely shut his issue down he could get vindictive. He could in fact damage “Reem”’s career prospects if she were to apply into “Bob”’s company for a job. He could write damaging reviews that make it harder to attract contributors. So in this example the behavior did not escalate. But if “Reem” is someone who does this in her free time and planning to use it as experience when searching for positions - “Bob” can have the ability to make her life quite miserable. I’m pretty sure those cases exist. So while we think of how users are entitled and what corporate impacts exist. Let’s also pay some thought to the maintainers and contributors who spend a lot of personal hours on this. Be kind and communicate with respect and thanks.
• emilecantin 4y ago
  His fictional story reminds me of the Homebrew 2.7 debacle: https://github.com/Homebrew/discussions/discussions/340 https://github.com/Homebrew/discussions/discussions/340 TL;DR: They deprecated "brew cask install" in version 2.6, then removed it in version 2.7. Sounds fine, right? Except version 2.6 was released on December 1st, and 2.7 was released 20 days later on December 21st, breaking everyone's scripts just before the holidays. I agree with the overall premise, but there's a balance to be had somewhere. When millions of developers use your tools, you do have to be a little more careful when you make breaking changes. I think Linus has a point here with his "don't break userspace" rule.
• nuc1e0n 4y ago
  I think the views espoused in this article are not the best way to handle such situations. Bob should have pinned the dependency to the older version being used (assuming that can be done in homebrew) so that his companies usage of it can continue uninterrupted. However his team should also be able to properly identify and schedule the work needed to update the dependency. Having something just randomly break one day in production is not acceptable. If homebrew packages can't be pinned to an older version then that would be a technical difficency of homebrew itself.
• deleted 4y ago
  [deleted]
• fmajid 4y ago
  Perhaps we need a set of well-defined community engagement policies just as we have well-defined licenses or copyright policies, e.g.: - patches/pull requests welcome or not - paid consulting available or not (obviously with a right of refusal on architectural changes) This would go a long way towards managing expectations and avoiding mismatch. Tooling matters. Github doesn't have a way for a project to specify they won't accept pull requests for instance (e.g. thet's SQLite's policy, one I fully support, but then SQLite doesn't use GitHub or even git for that matter).