> No one expects you to write perfect code, but we do expect you to fix flaws when you learn about them.
It's not like he was getting paid to work on this, was it? And people do have a life beyond open source. People could have forked and worked on the issues themselves, but that's asking too much. Why do the hard work when you can just write a comment/tweet blaming someone else, right?
Your comment is precisely what entitlement looks like.
The maintainer is happy to get the report, and has an exchange with the reporter acknowledging the bug and how to fix it.
This all seems a very civil, mature way to address issues with open source software. Accept actionable criticism of your code, and strive to make it better. As a developer, I know having other people test my code and report problems back to me is one of the best ways for them to help me and my code improve!
I think identifying to your code to the point where you consider criticism of your code an attack on your personal identity demonstrates a real lack of maturity.
You might have missed a couple lines. It's easy to miss as it's right below the quote from the article mentioned: "This causes the now-usual Reddit uproar. It’s extra nasty this time. Some people go far, far, far over the line."
The issue isn't the article or the bug reports. It's the uproar from Reddit, and the extra nasty comments.
"Some people go far, far, far over the line."
There is a reason HN has guidelines for how to approach communication. It's because if we "go far, far, far over the line" and get "extra nasty" things devolve and this place becomes far worse. Rather than "toughen up" or "just not taking things personally," HN realizes that words matter.
Like I said, a couple lines easily missed or forgotten. It's not the bug reports. It's the extra nasty comments.
This could very well be thanks to the moderators, but I hardly saw any nasty comments on r/rust. People were critical of the actix maintainer, sure, but I didn't see anything that crossed the line. Some comments in the GitHub issues were indeed nasty, but those were actually called out on the subreddit.
There's no way for me to know for sure, but it seems as though Klabnik was exaggerating here.
The nastiest response I encountered was at the end of the GitHub issue thread, right before the maintainer deleted it. (He also cites it in his postmortem.) It said things like "you should never write Rust again," with very little substance.
The problem with the r/rust thread, AIUI, is less "far, far, far over the line" and more just a huge volume of the same sorts of criticism. It sucks to see such a response on that scale, but it's harder to characterize any individual's comment as "nasty."
Yeah, that comment on the GitHub issue was definitely over the line, but it wasn't on Reddit. The comments in the subreddit were higher in volume, but way more reasonable.
Well, I've certainly seen some nasty behavior in topics touching the async-std crate that I didn't like and thought should not be written. It felt really bad and was the first time I felt how this community has changed from the years I started writing Rust.
>> It felt really bad and was the first time I felt how this community has changed from the years I started writing Rust.
I agree. I'm further disheartened by a lot of the reactions that happened since. One of Rust's greatest strengths is turning into a weakness.
The Rust community needs to treat this cultural exploit as if it were a critical technical exploit and apply the same sort of objective and collective examination of source and insightful exploration of assumptions made about existing grammars and syntax and come up with appropriately safe and forward thinking solutions to ensure that the code of conduct isn't just a progressive cliche.
Here's the thing, though: you're looking at a very limited set of interactions (namely, n=1), and declaring that the developer of ureq is awesome and polite, and that the developer of actix is an asshole.
You don't know the history of either project, or either person. The developer of ureq probably has some bad days and responds in ways that their not proud of. The developer of actix has probably had some (many?) good days and responded politely and helpfully.
Indicting the actix developer given a small set of responses to a particular class of issues is a bit unfair.
There is a difference in the bug reports: The ureq one shows a proven error - a crash. That's bad, the author acknowledges it and fixes it.
The actix issue does not show an actual error. It just tells that some internal code does not follow the usual Rust unsafe conventions, and that this might lead to a bug. It takes then some API exploitation by a third person to demonstrate how this could lead to a bug. At that point the author acknowledges the issue, even though any real world implication is still unknown.
> Ok, so here is the article Klabnik cites, comparing various Rust HTTP clients:
Interesting. I'm being led to believe that the actual problem lies in HTTP itself: it is too convoluted to be safely implementable and should be replaced with something else for security-critical applications. (Or in general.)
I don't think this is true. In fact, today, I privately forked one of the aforementioned libraries (httparse) and removed all of the unsafe parts in under an hour (without introducing any new memory allocations, I might add). All the tests pass.
It's not insurmountable. It just takes a little bit of elbow grease and self-discipline ;)
While this may or may not be true, it's irrelevant to the use of “unsafe” code in Rust. Rust doesn't attempt a compile-time guarantee that your code is simple or bug-free. It attempts to guarantee that mutable aliasing, use-after-free, double free, and resource leaks don't happen. No wire protocol requires such things or is even relevant to them.
But this is a problem Rust creates for itself. HTTP is safely implementable in most modern languages without any unsafe code because they're all garbage collected. For instance, Java has a mechanism also called Unsafe that lets you bypass the language's safety features, but I've never encountered an HTTP client that uses it because performance is fine without that. And the JVM developers have been working for years on safe but performant constructs that can replace the uses of Unsafe that do exist in the community, mostly, cases where very precise control over memory and concurrency constructs are needed in high performance servers.
Okay, I massaged the GitHub API logs[0] with jq to make a readable version of the issue history[1]. I was firstly (based on the blog post) feeling bad about the maintainer... but after reading the issue report, it turns out multiple people were working on the issue and the author responded... 'this patch is boring'. That's... certainly not good to people who are trying to resolve the issue. He even goes to threatening to delete the organization if people talk about the issue.
Not quite correct. That patch was never intended to be merged as-is in the first place:
> As a PoC
> Presumably this requires benchmarking/more exhaustive testing which I don't have time to do, but if someone wants to take the patch and get it merged feel free
Keeping that in mind, the "boring" comment comes off differently to me, like they got sidetracked from the original issue and he didn't feel like continuing - which is nearly the confirmation given in the second issue.
I don’t have the full picture here, but the source article implies that folks weren’t just complaining, but also offering PRs to fix the issues, which were rejected. That feels less like entitlement to me and more like bad stewardship of the project, but again, most of my info is biased by source article.
One must also consider the typical quality of a PR - that is, lacking in many fundamental ways. Missing documentation, missing tests, doesn't match existing style, and sometimes just plain incorrect.
At some point, a flood of poor PRs can be worse than a flood of angry bug reports. The cost of validating and cleaning up a PR is significantly higher than closing a bug.
This is why I wrote "forked". They do have the right to not accept PRs for their own project, no? Sure, someone can be a bad steward, or maybe just opinionated. Doesn't give anyone the right to be mean to the point of making them quit their own project.
Here is an example of an actual comment. I believe the thread is deleted now:
> "seriously? Please just stop writing Rust. You do not respect semver, you do not respect soundness, so why are you using a language predominantly based around doing these things right?"
This is what I was thinking of when I wrote "far, far over the line."
That comment is demeaning, unhelpful, and in very bad taste. It's the comment that the delete functionality on GitHub was made for. However, one of the other participants in the thread immediately called out this comment. So you have a constructive dialog, a single bad actor, and said single actor being called out by the people having the constructive dialog. That doesn't sound like an unhealthy community to me, to be perfectly frank.
I agree that the comment is in bad taste but what I don't see this being considered a "far, far, far over the line." comment when I take into consideration that it had been posted in reply to the maintainer's also dismissive comment "this patch is boring" so, yes, the user has definitely been rude, but chances are it's a visceral response too.
Otherwise if that event is far far over the line I wonder what out of the blue insults or death threats qualify as.
Yes, that comment was not ok but as far as I have seen that is the only comment which keeps getting quoted. All but a handful of people seem to have been civil.
Not to mention that that was a comment on GitHub, not on Reddit, even though the "far, far, far over the line" statement was about "the now-usual Reddit uproar". I guess Klabnik just really dislikes Reddit.
This! It is utterly disingenous - in fact, it is simply lying - to characterise users' interactions with the maintainer here as harrassment, or abusive, or entitled.
I completely agree with you, especially considering that comment was posted in reply to the maintainer's also dismissive comment "this patch is boring", which to me makes it seem not as bad as if it were out of the blue...
HN discussions do not always live up to HN ideals. This is not be used as a reason to drag others down to our level. Instead it should make us reflect on our own behaviour.
I think it's a cultural issue, but I honestly don't see what's so offensive about this comment (I was expecting something far worse), especially if it's factual assumptions are true. Honest question, can somebody explain the issue here to me, and how one would express these concerns otherwise? I feel as if I just don't get American culture of politeness and niceness to appreciate it.
It's a personal attack. The poster is telling the maintainer to quit writing Rust, implying he can never get better and basically demeaning his whole effort.
Do you not see how that is (a) not related to the project and (b) rude in any context?
If you were, say, singing karaoke and someone came up to you and said "you're awful, never sing again, you're off-key, you don't know the words"... Is that not rude to you?
I don't claim to know much about either karaoke or rust, but from what little I know of both, that seems wrong. The Rust community expects safe code, while bad singing is expected at karaoke bars.
The comparison was about how to communicate respectfully and appropriately, not about making an perfect analogy.
Think of it this way then: it is completely possible for the Rust community to expect safe code without being entitled assholes about how they communicate that expectation.
I massaged the GitHub API logs[0] with jq to make a readable version of the issue history[1]. I was firstly (based on the blog post) feeling bad about the maintainer... but after reading the issue report, it turns out multiple people were working on the issue and the author responded... 'this patch is boring'. That's... certainly not good to people who are trying to resolve the issue. He even goes to threatening to delete the organization if people talk about the issue.
The initial back and forth isn't the issue, it was reasonably civil, if putting a bit of resistance to fixing the issue. The problem was the escalation which happened when it got posted to reddit, where the suddenly things got a whole lot more virtiolic and most of the vitriol was coming from those not involved in the original discussion at all. A similar thing tends to happen with systemd issues, for example (generally in that case they close the original issue to stop more comments and make a new issue or move discussion to a different platform, but still this will spill over into making new issues, PRs, etc). This behaviour is basically worthless to harmful whenever it happens, because it doesn't further the discussion in any way and just causes headaches for maintainers.
>People could have forked and worked on the issues themselves, but that's asking too much.
Forking projects should be a last resort. This is the "Taking my ball and going home" approach, and now we're splitting development efforts, potentially ending up with very different code paths where improvements can't be merged from one to another, etc. It might be the right thing to do in this situation - but people wanting to avoid it want to avoid it for good reason. It's a big hammer and not the first one you want to pull out of your tool bag.
>Why do the hard work when you can just write a comment/tweet blaming someone else, right?
Except, as the article mentions, the author wasn't interested in detailed bug reports or PRs that had code that fixed it. This wasn't a case of people just being nasty - the maintainer wasn't interested in people doing work to fix it, either.
>Your comment is precisely what entitlement looks like.
This isn't someone asking for a feature request or minor bug to be resolved and whining when it didn't happen. This is a security vulnerability in a popular package where detailed reports are provided and the maintainer has a history of not accepting feedback, PRs, etc. on similar issues in the past.
Security vulnerabilities are a big deal: They have implications for not just the user or company that is making use of the software, but also potentially any end users. This is a web framework - a good portion of projects using it are going to be public facing. A good portion of those are going to be storing user accounts and information about the users. A security vulnerability puts all of those people at risk too.
I maintain that any project that you make publicly available you have a moral obligation to resolve security issues if it is at all within your power, and to disclaim them prominently if it isn't.
If I've got a free lemonade stand, but every glass contains a toxic chemical that will activate in my body if a malicious person sprays me in the face with another chemical, people sure as hell can bitch about my free lemonade, even if they could go run it through a filter and remove the toxic chemical.
No. This was kind of true in the days of CVS and SVN. Now with DVCSs like Git, it's easy enough to merge in changes from wherever; this was the whole reason Tom Lord originally developed the modern DVCS. Git workflows commonly make a new fork for every bug fix. If other people don't want to merge in your changes, they probably don't think they're good enough. But that doesn't matter; you can still use them. If they're wrong, it's their loss.
So, it's true that refactoring isn't going to merge automatically with either feature additions or other refactoring of the same code. But if the code was improved by the refactoring, probably the person making the other change will want to merge it in before making their change. There are cases where clashes arise between different visions of what “improvement” means — XEmacs was born that way — but in those cases it's obviously best for people to have the choice of which version of the code they'd rather work on, rather than bullying one version of it out of existence.
In many cases of profound changes, different versions of the software do a better job of serving different groups of users. For example, EVE Online is built on Stackless Python, a fork of the CPython interpreter that enabled massive concurrency. This was really important to the EVE Online developers, so they were willing to accept tradeoffs that the core Python developers didn't think were good ones. Most people have gone on to use the stock interpreter, rather than choosing Stackless, so probably the core Python team made the right choice for most people. But that's no reason to deprive EVE Online of the ability to try a different approach.
Similarly, when I installed my first Linux box in 1996, there was an "NFS swapping patch" which made it possible to swap onto NFS, which was impossible with stock Linux because it meant that many operations that were normally "atomic" could no longer be atomic. (This was before SMP support, so the kernel didn't have locks; atomicity was enough.) The patch introduced a new "nucleonic" priority level and redefined the notion of atomicity, adding a lot of complexity to Linux to support the marginal use case of running diskless X-terminals and the like on Linux, rather than, say, SunOS or NCD's shitty imitation of VMS. This was not a good tradeoff for the majority of users, and it did not merge well with changes to network drivers. But for a certain subset of users, it was extremely valuable and worth the tradeoff. This complexity was eventually added in a better way when Linux got real SMP support.
Similarly, LuaJIT prioritizes speed (and secondarily minimality), while PUC Lua prioritizes portability and minimality (and secondarily speed), currently being about half the size of LuaJIT and one tenth of its performance. LuaJIT is, generally speaking, about as fast as C, but originally it was i386-only, later adding amd64, ARM, PowerPC, and MIPS support; it still doesn't support aarch64, which is what most new hand computers use. PUC Lua, by contrast, runs anywhere there's a C compiler and a few hundred K of memory. Losing either of these two projects would be terrible.
So, no, forking projects should not be a "last resort." Being able to fork projects is one of the core benefits provided to users by open source. It's the reason Tom Lord invented the DVCS as we know it today, in the form of Arch, and it's the reason Linus wrote a DVCS to use instead of Subversion: to ensure that the users' freedom to fork their software didn't become merely theoretical.
I never used BitKeeper or TeamWare and consequently don't know how their capabilities were similar to or different from arch's at the time. Did you use them?
Tom had a pretty clear vision for arch which is more or less what Git ended up achieving. Everything he wrote publicly about it derived the feature requirements from his social agenda; he never mentioned BitKeeper, and I don't think he knew about it. He must have known about TeamWare, but I don't know if he had ever used it, and from the little I can glean, TeamWare lacked some very significant things crucial to what we think of as a DVCS today. But maybe I'm wrong about that.
If you make your project public, does it by definition mean you are open to other people using your release? I think there's a difference between "Hey, use this project of mine," and "If you use this project, you're on your own..." I think a lot of these debates come down to this confusion. Some people assume the former (and expect some level of response), some the latter (and say it's as simple as forking if you have a problem). Therefore I think anyone who releases should - morally/ethically, not legally/license - state what which philosophy they are following.
It'd be interesting if people could release their projects "abstract" fork-only. So they could publish releases that would be vetted and merged into the downstream forks, but would never be released as a deployable itself.
It's really hard, though, because you'll always get people who will feel entitled. In the distant past I've released things and explicitly put in the readme something like "This is provided in the hope that it will be useful; I do not have time to support it and will not accept requests for help, but will consider merging patches that fix bugs or add useful functionality".
And yet I still got people who would ask for help with it, or file bugs without patches and then get angry when I wouldn't help them.
In that case, you clone and fork. If you're just trying to get your stuff working, your fork is private. If instead you're trying to enjoy publicity, you publicize your fork. In neither case is it necessary to annoy someone who has already done a lot of free work for you.
This isn't a serious response. As amply demonstrated in TFA and elsewhere, the harassment was far more than "reporting bugs".
And, anyway, yes, reporting bugs can be extremely annoying. Different devs respond to this annoyance differently. npm devs, for example, have decided not to pay too much attention to bugs reported by the public. [0]
Strangely, I would rather deal with developers who find bug reports annoying than folks who simply ignore them. The former have a touch of pride and you have a chance to get them to see your point of view. Better that than speaking to a black-hole.
I honestly dont understand people being mad at this. Every dependancy I use I don't like 100% I fork and modify and then upstream changes, and if they never get merged, who cares?
If there was a big user community that wanted different things, fork and have a seperate maintainer structure. Why drama?
A huge number of npm dependancies I use are basically unmaintained, have tons of forks and multiple PRs with the same fixes. I choose the one I like and move on, the magic of github!
From a pragmatic point of view, it's very bad to have widely used libraries that are poorly maintained and that have unaddressed security issues. It's not entitled to not want that situation to exist.
If you create a project that ends up becoming such a security risk, you really should be doing something to address it, for the good of everyone. This could be as simple as adding more maintainers with commit access who will address the issues.
Although I agree with you but there is one more point to consider. Why do people write open source libraries/frameworks? You'd say they write it as a hobby or learning experience and this is totally fine. But why don't they keep their work private if they aren't or shouldn't be bothered about how people use their libraries?
I agree OSS maintainers do a lot of work but no compensation in return. I believe most maintainers actually strive to remove flaws/bugs in their projects.
But if you write a half baked buggy OSS which is used by many people, you definitely should have some sense of responsibility towards users. Otherwise keep it private or at least boldly acknowledge that your project is merely a toy project which has many bugs and you aren't bothered about those bugs.
Let's say some charitable person hands out food to the poor. Only it's cooked with bad hygiene and people who eat it fall ill. People can and should warn tell each other to stay away. Even if his feelings get hurt. Even if he was only trying to do good.
I think this is a good metaphor because how bad the food is is key. If it's just a little bad he is doing a good thing. If it's a little bit more bad it's neutral and people can take it or leave it. And if the quality is really bad that's when people need to protect themselves and each other by dragging his name through the mud.
I'm not familiar with actix so I wont presume to say which category it falls into.
Reasonable expectation does not equate to entitlement.
So what is the person who finds the flaw supposed to do:
1. announce to all the other users of the library to download his branch with just the single fix
2. report it to the maintainer with a suitable patch, discuss it, and hope the maintainer applies it sooner rather than later.
TBH the maintainer sounds like the boy with the soccer ball who ends the match and takes his ball home with him, because the opposing side scored against his team.
To me the maintainer sounds more like the boy who brought everybody cake and then left the party when the other boys started nagging about how their mothers would make much better cake and how his cake is all wrong.
It's more that he bought a cake, but it wasn't cooked in the middle, so there was a chance people could get food poisoning, and the other people at the party pointed that out and suggested ways to cook cakes more consistently, but the author really likes cooking soggy cakes, and he's never got sick from it so it must be fine, so he left the party and told everyone the others were mean to him.
Nikolay works for Microsoft, who use actix-web internally. He was putting in 12 hour days for 3 weeks porting the project to async/await, so I sure hope that Microsoft was paying him for it!
> It's not like he was getting paid to work on this, was it?
So? If I'm donating clothes to one of those coat drives, and the clothes I donate are tattered and covered with rodent feces, should the organizers of said drive not be upset with me? Especially if said organizers point this out politely and I respond with "lol you'll take what I give you, peasant"?
No demand for work is being made here. I'm simply saying a project that isn't a toy project will be criticized if it doesn't behave according to community standards.
I'd consider it to be social norms. It certainly isn't entitlement.
> It's not like he was getting paid to work on this, was it?
That is completely beside the point. Do the Debian maintainers that were responsible for famous security slipups regarding SSH keys got paid? No. Would the backlash if they had been unwilling to fix the issues been warranted? Absolutely.
Once you are a part of people's infrastructure and these people rely on you to not be irresponsible, you can't afford to play the but-I-dont-get-paid-card. You can resign gracefully and let other people take over. If you put up a tantrum, you probably get your reputation burnt faster than a Google project gets when they suddenly pull the plug.
Open source is not some backyard game anymore. It involves companies and their commitment in form of infrastructure and participation.
Open source is like capitalism. But a project's success is measured in commitment instead of capital.
Everyone has different goals and different tolerances when they work on open source, whether as a maintainer or contributor.
So there are some Debian developers who are unpaid and slavishly dedicated to fixing security issues and apologizing if they screw up? Great, that increases my confidence in them (I'm a Debian user and happy with that).
But guess what? There are also open source developers who do their thing as a casual hobby and just throw things out there because they hope it might be useful. They don't want to spend 50% of the free time they allocate to the project dealing with support requests and bug reports.
And there's everything in between, and above and beyond. I think this is a mistake that so many people make: that all open source developers are exactly the same, have the same motivations, want the same level of involvement, and have the same responsibility. That's just flat-out false. Every project and maintainer is different, and yes, it can be difficult to judge what kind of support you'll get when looking into taking on a new dependency, but that's the price you have to pay when you get something for no monetary cost.
You have no right to tell anyone what to do or how to do it unless you are paying them for the privilege of doing so.
> Once you are a part of people's infrastructure and these people rely on you to not be irresponsible
Nonsense. Absent a contract and some sort of consideration changing hands, you are responsible for your dependencies, and no one else.
> You can resign gracefully and let other people take over.
No. If users are unhappy with maintainership, they can fork. It's often contentious and not all that fun, but the (unpaid!) maintainer has no obligation to run the project the way you want them to.
>you can't afford to play the but-I-dont-get-paid-card
Yes, you can. The projects that have persisted over the long term have had a long history of people being paid to work on them, Debian included. There is no need to do something to "let other people take over" either. The code is open, you just type "git clone" and boom, now you've taken over.
I’d argue that if a company has a larger than normal dependency on keeping a project running (like a cloud provider with 1 million VMs running Debian or Debian-based OSes) they should hire a full time employee whose sole job is to work on it.
I think the basic rules still apply: You’re getting this software for free rather than paying for something expensive. Though you deal in the software, you get no guarantee of its fitness for any purpose. If you want a better guarantee of its fitness, either pay the current maintainers or hire someone good who can become a maintainer. OR choose open source projects where a BigCo like Microsoft or Google has hired people to work on it full time.
> You’re getting this software for free rather than paying for something expensive.
So open source is free as in beer, not free as in speech after all. And the reason a company might choose to use open source is solely because it's free, not because they can see the source code or alter it? Because that is why companies are in it, not because they were cheap for the small cash of a paid version. And they're in it because they can watch and choose those projects that are well maintained.
If the maintainer pulls a tantrum and acts unreliable that kills the project from the point of view of any serious user. Until someone else takes over maintenance or it is forked.
This "it's free so you get what you paid for, and if it's shit don't complain because it was free" really rubs me the wrong way. It's a very capitalist mindset that measures everything in money. If there is no money, there is probably no worth, so don't expect any. Accomplishment, dependability, positive net effect? No money, so don't expect it?
> So open source is free as in beer, not free as in speech after all. And the reason a company might choose to use open source is solely because it's free, not because they can see the source code or alter it? Because that is why companies are in it, not because they were cheap for the small cash of a paid version. And they're in it because they can watch and choose those projects that are well maintained.
In general, developers aren't auditing the source code or modifying open source code; they're assembling open source packages to provide base functionality and combining that together with business logic and glue code to produce a product. So yes, companies are most commonly using open source because it's zero cost (and easily available), not because they can theoretically audit or modify it.
> If the maintainer pulls a tantrum and acts unreliable that kills the project from the point of view of any serious user. Until someone else takes over maintenance or it is forked.
There's no single definition of "serious user". There have been projects with no technical issues that are maintained by massive assholes that are widely used, so I would disagree with your statement here.
> This "it's free so you get what you paid for, and if it's shit don't complain because it was free" really rubs me the wrong way. It's a very capitalist mindset that measures everything in money. If there is no money, there is probably no worth, so don't expect any. Accomplishment, dependability, positive net effect? No money, so don't expect it?
1. Unsurprisingly, any discussion within the context of how businesses make decisions or should act is likely to revolve around money.
2. The fundamental issues is that there's a massive disconnect between the worth/value provided by a project to users and the value it provides to the creator.
3. The license dictates what users should expect as far as "what they get" from a library. It almost all cases with open source, they should expect to get nothing, and anything beyond that is a bonus.
> This "it's free so you get what you paid for, and if it's shit don't complain because it was free" really rubs me the wrong way. It's a very capitalist mindset that measures everything in money.
I mean like... yeah.
If I'm maintaining an open source project as a side gig or for fun, I might be able to review and merge some patches. But if the corporations that use my project submit a busload of PRs (or worse, just issues with no solutions) and I end up spending so much time on them that I have no time to work on my dayjob and make rent... that's not gonna work.
Now if those corporations each chuck a hundred bucks a month (less than the cost of a single Developer's Enterprise MSDN subscription) my way, then sure! I'll scale back my freelance web dev work and spend half my workweek dedicated to maintaining this project!
So yeah, I think the corporations who make money off open source projects should be kicking back a bit of money to those projects if they want an expectation of reliability. It doesn't have to be a ton of money either:
- If we're talking about a tiny header parsing library that needs occasional security patches, maybe expense a few bucks at the maintainer's Patreon so they can spend 10 hours a year on those patches.
- If we're talking about the web framework that underlies your big newspaper's CMS, maybe have a developer spend 20 hours a month pushing well made PRs to fix the problems you care about.
- If we're talking about an OS like Debian and you're AWS, maybe hire a 3 person team to work solely on keeping it secure.
What rubs me the wrong way is the notion that if it's for free it has no worth. This "free == shit" idea that is expressed in "you can use it but don't expect much of it because it's free". Maybe I'm just too much of an old school open source idealist.
Some floss developers choose to work for free. That’s fine or even admirable.
That doesn’t mean that everybody needs to. If a dev isn’t being paid then they should have the absolute right to refuse all maintenance or even just destroy the project.
I’d keep my code closed source if there was a risk that it would start getting used and suddenly I’ve got an extra job for zero pay.
I disagree that there is an obligation to "resign gracefully". If people choose to depend on your code without some sort of contract then that is on then and you absolutely can continue to play the "I don't get paid" card if you so choose. The fact that the Debian maintainers don't play this card does not mean that everybody should behave the same as they do.
Let me help you:
> You can resign gracefully and let other people take over. If you put up a tantrum, you probably get your reputation burnt faster than a Google project gets when they suddenly pull the plug.
Where did I say I believe there is an obligation to "resign gracefully"? I said, that you will burn your reputation. Not that I think that is how should be. Just like a politician burns their reputation with something you or I might not find offensive. And that is where shitstorms come from. "I'm just minding my little own business down here" doesn't work once there's a spotlight on you. Do I like it? No. Do I get downvoted on HN for describing the world as something people take offence in? Apparently.
> Open source is not some backyard game anymore. It
> involves companies and their commitment in form of
> infrastructure and participation.
I think this approach leads to sustainability problems, and discourages individuals from sharing their work in open source form. I make a project because I need it, and maybe it's fun to build. I generally share it because I think others might find it useful too.
What I'm reading in your comment is that once it becomes widely used, it becomes my responsibility to meet the needs of these people and organizations who have started using the work I freely give to them. The act of having it used by other people obligates me to them.
That perspective seems like it will eventually force the people who share their work in this way down the path of burnout.
> Open source is like capitalism. But a project's success
> is measured in commitment instead of capital.
I would argue that the goals of any given open source project - and therefore the measures of its success - are under the control of the owner(s) of that project. If one of the goals is to make a widely distributed and used thing, then yes - there are obligations such as you've described; they are inherent in that goal.
If the goal is only to build a thing and share it, there can be no such obligation - regardless of how popular it gets.
> I think this approach leads to sustainability problems, and discourages individuals from sharing their work in open source form. I make a project because I need it, and maybe it's fun to build. I generally share it because I think others might find it useful too.
I don't believe that every little open source project is automatically held to the rules I described. But once your exposure gets bigger, you suddenly enter different waters. Hopefully you might have maintainers of a distribution shielding you from the biggest impact.
> What I'm reading in your comment is that once it becomes widely used, it becomes my responsibility to meet the needs of these people and organizations who have started using the work I freely give to them. The act of having it used by other people obligates me to them.
That is precisely what is happening in many places. I didn't say I like it. In most cases people can move. Sometimes the "market" moves on or forks it. But this is what I have been seeing more and more.
> If the goal is only to build a thing and share it, there can be no such obligation - regardless of how popular it gets.
This is tricky. Viewed from the moral standpoint of the starter of the project, I agree. But once you got into the limelight with your project and other people started depending on it, every misstep suddenly becomes a jackass move. You essentially lost the project.
> But once your exposure gets bigger, you suddenly enter different waters.
I fundamentally disagree with this. Just because my exposure has gotten larger (possibly through no action of my own), it doesn't magically give me more resources, more free time, more motivation, a team of developers, etc. If people (or companies) want to depend on a one-person open source project for something important to them, then they should pay to fund it, either by giving that developer money directly, or by hiring people in-house to contribute to that project.
(Not doing so is just foolish and risky on the company's part, too: depending solely on an unpaid volunteer for an important part of your infrastructure is not a winning move.)
Also consider that more users generally means less free time for developing, and more time handling bug reports and support issues. If an open source project grows, it's absolutely critical for users to step up and pitch in, either with their own skills, or with monetary resources that can help the maintainer (who might have a day job) focus more on the project.
Maintainers do have a responsibility to decide what they want their level of involvement to be, though, and to communicate that. Potential users should have the information they need to decide if the project they want to depend on is well-supported and sustainable. They have no right to demand that the maintainer change their approach or level of involvement, however.
> But once you got into the limelight with your project and other people started depending on it, every misstep suddenly becomes a jackass move.
I really dislike the lack of charitable interpretation given here, and this just contributes to the "entitled user" image. The unpaid maintainer of an open source project does not owe anyone anything. Full stop. Users are responsible for their dependencies. I'll repeat that: users are responsible for their dependencies. If they are going to take on a dependency for that's given away for free and not do their due diligence to make sure it is reliably and sustainably developed, that's on them. If they're not happy with the maintainership and want to use it anyway, that's on them. Users do not get to tell unpaid maintainers how to maintain their software. If they want to be helpful and constructive, that's great, but anything less is rude and unwanted.
I originally invented the analogy to make some friends of mine who had a very strong market oriented mindset, understand open source. This was many years ago, when the likes of Microsoft painted open source in the light of anarcho hippie communism. I needed to explain to them that open source is closer to their thinking than some Fortune 500 behemoth that is capitalism on the outside but basically socialism inside.
It's not like he was getting paid to work on this, was it? And people do have a life beyond open source. People could have forked and worked on the issues themselves, but that's asking too much. Why do the hard work when you can just write a comment/tweet blaming someone else, right?
Your comment is precisely what entitlement looks like.