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.
>> Personally, I think the way forward is source available.
I'm not sure that's the best solution either. One thing I think is often overlooked is license compatibility. Open source benefits a LOT at time when code can be taken directly from one project and used in another. In fewer cases it also benefits from the ability to fork a project.
In my opinion we should stick to a tiny number of licenses depending on which makes sense for a project: MIT, GPL, and LGPL. Now I realize there is a lot of BSD out there which seems equivalent to MIT. And as everything is moving to the cloud I can actually see AGPL as a good thing, but even that IMHO should have been merged to GPL3 to prevent license proliferation. In the same sense I think the OSI made things worse by "approving" more licenses that are technically open source but just fragment things. Similar for the Apache licenses.
So no, we don't really want to solve these problems with another license. OTOH if your product is stand alone and not likely to have code useful outside itself then it might be OK. But then you're just inviting outsiders to contribute to your commercial product while also offering a limited use free version. I'm going to guess you don't get a lot of contributions?
> 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.
> I honestly can't think of another industry that relies so heavily on things they get for free [...] So many people act like Open Source is great. But [...]
I likewise have trouble understanding how people getting so much great stuff for free, with which they create stunning, society-changing artifacts on a regular basis, think that getting that stuff for free was... bad? I mean, yes, you don't get a warrantee and don't sign a contract and don't have anyone to blame but yourself if it breaks. And it works amazingly well! Objectively and experimentally much better than the proprietary infrastructure that it replaced[1].
And it's not like buying your stuff solves this problem anyway. This very site is filled with complaints and reports of proprietary software failing to work the way its users intend too.
[1] Anyone else remember porting software across six Unices in the 90's? I do!
> And it's not like buying your stuff solves this problem anyway. This very site is filled with complaints and reports of proprietary software failing to work the way its users intend too.
I've had proprietary software break on me. It was actually our fault. Literally, it resulted in there being a call with a developer at the vendor and they fixed our code for us.
I've had proprietary software break and got money back for SLAs. You get a fix real quick when there is an SLA.
I've had proprietary software have release dates pushed back because we couldn't handle the time to rewrite to the new version and we still had a support contract for that version. We could have choosen just to keep paying for support on the old version at a higher price but obivously choose to rewrite to the newer version.
At the same time, I've had pull requests go unmerged even though they had tests and fixed bugs.
For me, even if it's just the ability to complain I thnk paying is worth it. You complain to an open source project they're screwing with your stuff you're an entitled user. You complain to a vendor that they're screwing with your stuff, you're an rightfully angry customer that gives them a reason to spend time to fix the issue causing you problems.
> I've had proprietary software break on me. It was actually our fault. Literally, it resulted in there being a call with a developer at the vendor and they fixed our code for us.
I write open source software for a living. I've had users come to me with problems that turn out to be bugs in their code. I fix their code for them. This happens pretty much every week. I don't see the distinction, one anecdote is as good as another.
Obviously, yes, you can write big checks that ensure people take you seriously, which is fundamentally what you're talking about here. You can write those checks to anyone though, including many, many excellent companies who would love to take your money to maintain their open source projects. It's an orthogonal problem.
> I write open source software for a living. I've had users come to me with problems that turn out to be bugs in their code. I fix their code for them. This happens pretty much every week. I don't see the distinction, one anecdote is as good as another.
I have a feeling the difference is you told them how they were using it wrong and/or wrote code in a comment that they could copy and paste. While the vendor's developer literally made modifications to our codebase themselves. There is a difference from providing the solution and implementing the solution.
Fair enough, but to repeat: this has nothing to do with "proprietariness" of the product you bought, it's because you Wrote Them a Big Check.
In almost all cases, if you want to write big checks for your open source dependencies to ensure support, you can do that! The world is filled with companies doing consulting like this. But many people don't, because on balance it's more effective to get stuff for free and do the support yourself[1].
Just don't whine if you chose to be in category #2 but want to be in #1, just write the checks.
[1] By Writing Big Checks to your expert employees, of course.
The issue I have is for most open source projects you can't even write them a big check.
Out of the open source projects I use:
* Symfony - It's 50/50 on if you could write them a big check. Symfony is a legal entity but it's well known they're affilated with SensioLabs who you could write a check to.
* PHPUnit - The maintainer runs a consultancy group, so possibly but maybe not. It may not be worth his time to provide support even if you're willing to part with lots of money.
* Doctrine - You can buy a support contract via a third party but that is a very minimum support set up from what I see. And honestly, I don't know who would honor it since it's a group project and doesn't have a legal entity.
* PHPSpec - Not possible
* Brick Money - Not possible.
* Behat - Not possible
* Guzzle - Not possible
* Gorilla Websockets - Not possible
* PHP - Not possible - Maybe via Rougewaves but they're not part of PHP development any longer.
While many larger open source projects it is indeed possible to get support from third party companies and sometimes from the original developers. For many large open source projects it simply isn't.
Commerical products that are open source you can get support for.
Sorry, but because the dissonance is really confusing me: If you genuinely don't want to be using "open source software" and would prefer to pay for stuff, why on earth are you building your app on top of an ancient legacy platform like this?! There are copious proprietary/paid frameworks and toolsets with the sophistication of PHP (which is hardly a high bar). Just buy one of those.
I thought this was going to be an argument about Linux or clang or k8s or React or something. Not... 90's web stacks. No wonder you think open source doesn't work, you're trying to use the stuff open source developers abandoned years ago.
What about a system that allows requiring a fee to "open an issue" or "file a bug report". GitHub could add that to the issue creator pretty easily. And maybe there could be tiers. Free issue == no guarantees. $5000 issue == guaranteed fix.
Well the amount listed could be up to the developer. And it doesn't need to be an instant transaction, if the scope of work is large it could lead to negotiation on cost and expectations
That doesn't really address the underlying disconnect, though.
A lot of FOSS work is done as a labor of love, not a job. In order to make good on a promise to fix something for money, that means it's now a job. That may be OK for many FOSS projects, but it is completely incompatible with others.
I think you’d want time responsibility to fall the other way — a bounty system basically — where the fee can be offered to anyone willing to clear the task. This it can also capture negotiation, invalid tickets, etc by nature of both parties being involved before the task is undertaken.
One problem though is you’d need a strict definition of complete, and someone to arbitrate.
I usually amplify this, but with tiers (i.e. as a bounty) it suddenly makes a lot of sense to me. Not all issues are bugs.
The perverse incentive would be to avoid fixing bugs or adding features because someone might add a bounty to it in the future, but that's limited by the possibility of a fork. Maybe limit UI for bounties to FOSS projects (that can be forked.)
"The way forward" is very subjective and depends on what your goals are in open-sourcing your project.
If you are trying to drive adoption for your product like AMD GPUs on Linux or FSR then open-sourcing with a liberal free software license makes perfect sense. If you worked on a hobby project and you are no longer interested in it and just want to put it out there to help someone else along who might be interested in the future, open-sourcing with a free software license makes sense.
If you want to control anything about how your product is used (outside of something like GPL) then using a more restrictive license or only open sourcing parts of your product ("open core") makes sense, like you describe. I don't think there's anything wrong with any approach to open source as long as it's explicitly communicated to the user.
> So again the company wants free things that benefit them.
Pretty much. This is actually the strongest possible reason to use GPL. Licenses that are too permissive enable these companies to succeed while giving nothing back.
> 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.
Dual license GPL/proprietary. I'm always reminded of this post:
> I honestly can't think of another industry that relies so heavily on things they get for free and come with no warranty.
I can think of plenty examples of such industries: mining, logging, oil, wind and solar energy etc. However, the difference is that any imperfections in the "things", in case of those industries, is literally caused by forces of nature, and measures have been developed over centuries to mitigate or avoid them.
With open source, the free "things" are created by humans, and it's too easy to fall into the trap of seeing them as just another set of "vendors", even though the base principles - which make things free on the first place - are actually quite different.
I'm my mind, any company depending on open source has only a few possible options:
1. Directly pay someone - either the original authors or someone else, inside the company or outside - to ensure the maintenance and support for the open source code.
2. Not use open source and only go for commercial vendors, which may not always be available.
> 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.
Interestingly, software users do this too with free web services, but generally we don't treat it as entitlement when users complain that a free web service is discontinued or migrates to a subscription model.
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.
> 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.
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.
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.
> 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.
I'd say that if using free stuff doesn't scale for you when you are using hundreds or thousands of free things, you should use fewer free things.
I meant the opposite, sorry. Subscribing to a general "release announcements" type of channel often means that you have to wade through potentially hundreds or thousands of messages for things that you don't care about, in order to get updates on the handful of things that you do care about.
You should also subscribe to the upstream project's changelog, but if you're already pinning yourself to an old outdated version then that won't help you find out when the package in a repo is being updated.
> 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.
By accepting payment you’re taking on another hassle: maintaining the feature for undetermined time. If it breaks or has a bug, you’re on the hook for fixing it. An entitled user becomes an entitled client.
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.
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.
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.
> 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.
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).
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.
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.
Homebrew informs you about our analytics behaviour before we send any data with a link to the documentation (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.
You violated our trust and still are seemingly refusing to admit that. You dismissed any criticism of your choices that didn't come from a maintainer, calling such criticism abusive and stemming from entitlement. It's relevant context whenever you complain about entitled users.
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.
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?
For anyone wondering: Homebrew sends data to Google 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.
I’m not treating them as a monolith. I’m suggesting that if the concern is a local program on your computer shipping usage metrics to Google, Golang and Homebrew both do that.
Both support well-documented opt-out, and I’m not personally bothered by the existence of either as a default-enabled feature.
But it’s odd to me that because Google has many employees, you’re ok with golang sending usage data to one of their databases, but you have major beef with homebrew sending to another database 6 feet to the left.
Is your concern default-enabled metrics? Or metrics sent to Google? Or specifically GA as a storage backend? It’s not clear from this thread.
Thanks for engaging. I still don't see Google Analytics referenced. Second paragraph reproduced below.
> Since Go 1.13, the go command by default downloads and authenticates modules using the Go module mirror and Go checksum database. See proxy.golang.org/privacy for privacy information about these services and the go command documentation for configuration details including how to disable the use of these servers or use different ones. If you depend on non-public modules, see the documentation for configuring your environment.
Nothing about GA. Of course, or naturally as you wrote, they will have server logs. I can't imagine anyone in good faith arguing they should not have server logs and those that do can host their own proxy.
Not sure where you're getting GA from? This doesn't really have anything to do with GA, as far as I know.
> I can't imagine anyone in good faith arguing they should not have server logs.
???
That seems like a really, really strange take to me. "Server logs" is just one way of capturing usage data. GA (as you mentioned above) would be another, though I don't think that's in play here.
The point being, usage data is available to Google. Whether they use it (or not), now or in the future, is unknown to me.
And yep, the people who care can disable it. aka opt out
> elondaits: For anyone wondering: Homebrew sends data to Google Analytics...
> aliqot: Go does this too :/
> sneak: No, it does not.
> akerl_ 1: yes, it does: <<link>>
> sethammons: (summary) I don't see it (GA usage) at <<link>>
> akerl_1: (summary) see paragraph 2
> sethammons: (summary) no GA stuff still
> akerl_1: (summary) wait, why are we talking GA?
The thread started with GA, and I though you were saying that Go uses GA.
Given that Homebrew is using GA basically as a raw database / dashboard, the distinction between “google” and “google analytics” feels pointless here.
The thing that makes GA worse for your privacy than other 3rd party datastores is the linking/inferences because of its shared nature. If you visit 100 sites that use GA for tracking, Google (and to an extent, those 100 site operators) are benefitting from the joining of your browsing history across all the sites.
By contrast, Homebrew is submitted logs to GA with a custom UUID not shared by any other application / requests / browsing that you do, without your IP address, and without any metadata that would link your Homebrew activity to other non-Homebrew activity. They needed a place to send metrics, and GA is providing them the data storage and visualization layers.
If I wrote a FUSE filesystem called “GAFS”, that stored arbitrary encrypted files as GA metrics using their API, I’d technically be using GA but it would be weird to file issues about the privacy impact of having GA code in my CLI tool.
Those decisions are all from 2022.
GDPR has existed since 2016 and GA wasn't an issue then so a recent ruling must have happened that changed this. But sure enough, it means I am wrong.
The GDPR came in effect in 2018 (May 25). When it did, most companies scrambled to comply.
Back then I researched the analytics situation and can say from what I remember (and my POV):
- It was super clear it was a touchy subject, because you're basically disclosing private information (IP, tech capabilities, some browsing history, etc.) to a third party who may or may not comply with GDPR's basic requirements about data protection, right to be forgotten, etc.
- It was super clear there were some minimum requirements, like anonymizing IPs, limiting storage of data, storing the data in Europe, or making sure URLs didn't disclose personal information.
- Google didn't say much about compliance of GA. Their text was more about shifting the responsibility to web admins. Possibly because there were some doubts, like the validity of the Privacy Shield, which eventually was deemed invalid.
- Other analytics tools, like Matomo, offered configuration settings for anonymizing visitors and limiting storage.
- It was often suggested you could solve the issues by having users opt-in to analytics. e.g. "This tool by itself is not in violation, you are in violation if you didn't ask for consent before using it". The "guns don't kill people" argument. However, anyone would agree that if you can only track consenting people your analytics get super skewed, maybe to the point of being useless.
One of the main issues back then was that the GDPR doesn't talk about cookies at all, because a separate legislation (updating the existing ones) was going to cover that afterwards. This created a lot of doubts of whether an analytics solution based on cookies (without opt-in) could even be compliant at all. Current understanding is that certain cookies (e.g. login cookies) are and will be OK, while others (cross-site tracking) are absolutely not.
I think the reason decisions started coming as late as 2022 is because implementation was super late, and people are still learning about these things. There are still a lot of touchy subjects, like how to deal with YouTube embeds, Google Maps, etc.
> 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.
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:
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.
> 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.
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.
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.
"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.
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.
LTS is inherently expensive and it is just boring drudgework. TAANSTAAFL. You paying anything for support?
SemVer is also absolutely abused to be toxic since there's no clear definitely of what is a bug and what is a feature and what is breaking change and what is just an xkcd-spacebar and it is all ultimately subjective. And while there's always the argument that you just bump a major version every time someone complains, if you're bumping majors every 3 months then someone will complain about that.
FOSS developers are also FOSS users of other software. So they can be motivated to manage their projects in a way how would like the software they use to be managed. I.e. leading by example.
I can't necessarily speak for anyone else, but for me; at the back end of my career I find myself contributing financially to FOSS projects. This is possible courtesy of more success than I have deserved, facilitated in no small part by the contributions of many other FOSS developers.
Paying it forward, I guess?
Also, +1 for stop doing it when it stops being fun / worth your time. For anything really.
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.
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.
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.
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.
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 ?
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.
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.
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).
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)?
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.
>> 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.
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.
>> 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.
No, actually the whole at-will thing means that is literally not the case. It's polite to give notice, it might be tied to some form of severance to give notice, but in 49 US states you absolutely have the right to get up from your desk, right this second, leave, and never come back. And your employers only legal action will be to pay you for the time right up until you quit.
If you have a contract with your employer, "at will" employment does not give you the right to violate it. Many employees (for example, those who are part of collective bargaining agreements) might not fully realize that they have a contractual obligation to their employer not to quit without notice. (Executives, who are more likely to have individually negotiated agreements, are of course far more likely to be aware of the implications.)
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.
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.
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.
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.
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.
> Its unrealistic to closely follow the development of every package you are using.
You've just abdicated all responsibility here! It is realistic -- not to mention being the core part of our job -- to closely follow the development of ALL code in your application. No matter whether you wrote it, your coworker wrote it, or it was written by a volunteer halfway around the world, if it's running YOUR application, it's YOUR code. You've just chosen to outsource the maintenance of said code to someone you've never met and have no intention of paying.
If you wouldn't pick some random asshole off the street to sit down at your desk and mess around in your production environment without at least peeking over their shoulder, why would you take some random stranger's code and shove it in your codebase without vetting it?
So yes, it IS possible and IT IS YOUR JOB to follow the development of all the code that runs your system. That random asshole off the street offering you code for free owes you nothing more.
> 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.
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.
> There is also the issue of certain libraries and frameworks that keep changing things.
Then it's up to the people burned by this to use a different one. If you want a stable interface/API, make sure that's part of your decision-making process when you choose the tools you build atop.
The proliferation of easy-update-path tooling across platforms has hidden that fact that managing dependencies is a critical part of providing software and software-based services.
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.
I agree and i think that important task of projects is to manage user expectations by clearly stating what they offer. Some projects offer stability guarantees, some projects just keep changing things. If these approaches are well-communicated, then users would be less frustrated when their expectations are not met. But truth is, i personally would not use the second class of projects unless i am desperate.
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.
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).
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.
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.
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.
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.
I recently tried my hand in commercializing my open source project, gitleaks (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.
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.
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.
Textual¹ is open-source but sells the precompiled app. Keka² has the app available for free on GitHub but charges for it on the Mac App Store, to support development.
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).
The FSF used to sell tapes (and later CDs) of GCC and Emacs. I'm sure that revenue stream has dried up in recent years but it was a money maker in the 80s.
I'm not so sure. Payed-for software can get unmaintained just as well. Companies go bust, are sold, or change direction for whatever reason. Paying for a product doesn't give you any guarantee either.
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.
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.
If I maintain a tool or library used by others, I do see it as a personal duty to maintain it on their behalf. And, clearly the volunteers in the post we're referring to here feels a duty, or they wouldn't be concerned about making the necessary changes to update the tool and libraries provided. Their argument in the post is that their duty to update the tool and its libraries supersedes the perceived entitlement, as they put it, the end users have to an expectation of support. I'm pretty certain what we're discussing here is a feeling of duty, they just have a different opinion on what that duty entails.
There has to be a better way. The reason I think the distinction is important. One is a world where we spend more time as developers struggling to keep our balance as the floor constantly moves. And, therefore less time spent on solving actual problems. While the other potential world is one where we create a self-healing structure that somehow makes life easier for both the maintainers and end users.
I honestly don't know how it would work, but I definitely feel it exists somewhere in our future.
> And, clearly the volunteers in the post we're referring to here feels a duty, or they wouldn't be concerned about making the necessary changes to update the tool and libraries provided.
I'm not sure you're on the right track by thinking of this in terms of "duty". Someone might be working on open source for any number of reasons, possibly none of which are because they feel a duty towards any particular user of the tools they're working on. They may simply wish to produce the best, most secure tool possible at the lowest cost to themselves. That doesn't mean they have a duty to (say) keep around older, insecure versions just so users who haven't done their own due diligence can minimize work disruptions.
Given the lack of an existing "better way", I'm more than willing to cut open source maintainers a bit of slack until such a time as I'm paying them decent rates.
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.
"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.
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.
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".
Basically every OSS license contains something like the following (examples from MIT):
> Permission is hereby granted, free of charge, to any person obtaining a copy of this software
> to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software
Adding restrictions on who can use the software goes against the idea that the software is for anyone, anywhere.
The quote above comes from OSI (Open Source Initiative):
> 5. No Discrimination Against Persons or Groups
> The license must not discriminate against any person or group of persons.
> 6. No Discrimination Against Fields of Endeavor
> 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.
For-profit business is a "field of endeavor". Restricting usage for for-profit businesses can be a good idea, but it's no longer open source.
Right. OSI is steered by business interests, and has distorted the public view of what open source actually is. So currently anything that is not "business friendly", is not open source. I reject that notion out of hand.
Richard Stallman has long argued for [1] and established [2] the same thing as a requirement for open source, and I don't think anyone would accuse him of being a shill for "business interests".
It's a (these days popular) rewriting of history to suggest that "big business interests" are the only reason open source definitions do not allow authors to restrict what a user can do with the software. Rather, from the start, this was seen as a fundamental freedom, the freedom to run the software as you wish rather than have to get permission from the copyright holder as to how you are to use it, where you are to run it, for what purposes.
It's, for instance, been part of the GNU license since before OSI even existed, and in those days I don't think anyone would argue GNU was a tool controlled by "business interests". In fact, the reason people now don't seem to like this requirement for "freedom to run" is precisely because it interferes with their "business interests", their desire to make money from open source. That may be a respectable desire -- but open source does not conflict with it becuase of "business interests", but the opposite, because it's ethos was from the start about the rights of users to have freedom to use software, not about "business interests" in profiting from it.
You're avoiding the fly in the ointment, which is that the definition of "open source" that is advocated by the OSI is not without controversy and does not necessarily comport with how the term "open source" is used in everyday language. (I don't really care what Richard Stallman thinks here, FWIW.) Thus it's not immediately clear to me that you can say without reservation that software with available, noncommercially-licensed source code fails to be "open source" -- as when I use "open source" I and many others mean something different from what the OSI means.
You are avoiding the "fly in the ointment" that open source has always meant freedom to run it how, where, and for the purposes the user wants, from before the OSI even existed, and your and many other people's use is in fact not only an attempt to change the historical meaning, but a change that is motivated by the business interests of those who would like to profit off of selling software licenses while still calling that software "open source".
But sure, you are part of a movement to change the definition of open source to suit certain business interests in opposition to the original principles of freedom that motivated the concept of open source. I acknowledge that movement exists, and that you all are attempting to change the meaning of open source. People have tried to change the meaning of open source to suit their business interests since it began, but there is a new wave of invigorated effort to put holes in the meaning of open source to serve certain business interests. I don't think you have succeeded yet, and I hope you do not, and I'll keep pointing it out. If anyone can call anything they want open source, of course various business interests will, since it is viewed as an attractive label.
> But sure, you are part of a movement to change the definition of open source to suit certain business interests in opposition to the original principles of freedom that motivated the concept of open source.
I am not a part of anything here, unless I suppose you want to place me in a very loose group of linguistic descriptivists. I am concerned here with how the phrase "open source" is actually used across the breadth of English speakers, not with how it is defined solely by groups and persons with specific political goals.
Sure, ignoring OSI, the licenses themselves, the ones we use to ship OSS, have the very same sentiment in them: You can use this software for whatever you want, without restrictions.
For me personally, the "without restrictions" part is a huge part of why I use OSS. I want to use it for whatever I want, and is the same reason I publish OSS for others, I want them to be able to use it for whatever they want, even if I personally disagree with whatever that is.
open source, means the source code is available, in my opinion. I don't agree with your opinion, or the OSI, or any of the licenses you named. That might be why the license I choose doesn't include that language:
Someone could put time and effort into some software, and put it out to the world to be used for decades. Some company could then use that software to make a profit, and the original author would get nothing. I don't think thats right, and I will keep raising awareness against those who have been brainwashed into thinking only business friendly licenses are open source.
I don't generally agree with you, and I have zero "big business" interest behind me, I don't work for anyone for quite some time.
But this:
> I will keep raising awareness against those who have been brainwashed into thinking only business friendly licenses are open source.
is not generally a helpful perspective to have. I understand you don't agree, and you want people to understand your point of view. But if your goal is really to "raise awareness", it generally doesn't help to call other people "brainwashed". I won't call you brainwashed because you don't agree with me, not everyone needs to have the same opinion.
It's possible to have a different perspective than others without being manipulated by something else.
> open source, means the source code is available, in my opinion.
Hard disagree because I have been in the open source arena for two decades and I have never seen any notable project using "open source" to mean "source code is available". A software whose source code is available is just "source available" but "open", "free", "libre" mean much more than just source code available. I am not making this up! Just look at the license terms of any open source project of repute.
"Source available" is not enough for me to use a software. If a software license forbids any field of endeavour (including but not limited to commercial activity), it is no longer "open" to me anymore. Sure the source is available but it is not open, it is not free, it is not libre because it discriminates against a field of endeavour.
When I make something open source I really mean "open" and any individual or organization should be able to use my software without any discrimination while agreeing to the terms and conditions set out in the license.
If I really want to forbid commercial activity, then I will choose a "noncommercial" (and thus non-open, non-free, non-libre) license.
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_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.
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
"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.
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.
> 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.
This feels a bit screwy. Maybe it's arguable what the "lifeblood" of a volunteer-run open source project is, but surely it's not simply the users -- without sufficiently motivated volunteers there would be no project for the users to use.
And how is working as an unpaid volunteer, alongside your day job, anything but a hobby anyway?
> Instead it would just keep losing ground or stagnating compared to closed-source private services and ecosystems that prioritize their users.
Let's assume you've identified a genuine problem with many open source projects: their unpaid volunteers aren't offering good enough support to their users. What happens to the project when their motivation is completely sapped because they haven't been able to work on interesting problems, due to having to pacify needy users who aren't giving anything back?
> This feels a bit screwy. Maybe it's arguable what the "lifeblood" of a volunteer-run open source project is, but surely it's not simply the users -- without sufficiently motivated volunteers there would be no project for the users to use.
Without users, there would be no point to any software project. Less, Open Source...
> And how is working as an unpaid volunteer, alongside your day job, anything but a hobby anyway?
That's precisely why Open Source projects need to find a way to get funding. There is no way the general public would build their lives and future on Open Source that relies on hobbyists. Which is a reason why Open Source is not where it should have been today.
> What happens to the project when their motivation is completely sapped because they haven't been able to work on interesting problems, due to having to pacify needy users who aren't giving anything back?
Nothing. The project dies. Before that, the users will have already left, probably for private, closed ecosystems. Because it was a folly to expect people to build whatever they were going to do, less their businesses or organizations, on volunteers who may go away at any point in time.
Sounds brisk and brutal, I know. But that's the reality of public usage of software - if people can't rely on it, they won't use it.
Don't like it? Fork it. That's your recourse. Want something fixed? Do it yourself, or pay someone to do it for you. Publish your fix, and maybe it'll get merged into mainline. Or maybe people will decide your fork is better, and use it instead. Or maybe you'll be left with your own personal branch. In any case, you now have the software you need, because you made the software what you need.
The cool thing about Free (as in Freedom) software is that you have that right, unlike in proprietary land. Proprietary software (like Google's) can just die completely. Proprietary software can stay broken forever, because the only people who can fix it don't want to. With Free software, anyone can fix it. More importantly, YOU can fix it.
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.
Do you think people are in general kinder and more respectful and admiring to maintainers and support staff for software they pay for, then? That seems to be what your theory would call for?
Yes, and it's not just a binary. As a general rule – this has been verified in any number of cases – the more people are paying for something, the more respectful they are to the providers thereof, and the higher the perceived pay and status of the individual employee they are dealing with, the more respectful they are to that employee.
Money is just one aspect of it. It's the perceived availability of the person as a resource. Support staff are treated poorly because they're seen as available in that you can not only contact them whenever but they're technically coerced by their job into having to respond to you.
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.
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?
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.
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.
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.
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...
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.
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.
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