[cthalupa]

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

[ncmncm]

No. Fork anytime you want to use something in production and don't consider it right.

Post pull requests if you care to, and post your fork, too, if you like, being careful to keep clear that it is a different project.

Some forks wither, some surge, some re-merge. It's all part of the dance. Any of it is better than flaming somebody who makes a thing and offers it.

[kragen]

> Forking projects should be a last resort

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.

[Gehinnn]

This is true for feature driven projects where features are added on top of exiting code and only some existing code is changed.

But you will have a very hard time merging two refactoring branches that both touch internal data structures.

[kragen]

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.

[tzs]

> this was the whole reason Tom Lord originally developed the modern DVCS

Shouldn't that be Larry McVoy? BitKeeper predated GNU Arch by a couple years.

[kragen]

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.