[nicpottier]

Note that Russ isn't going against the community, he's just going against `dep`. Most of the community, myself included is pretty psyched about go modules.

Note also that the risk you propose for bad decisions is mitigated for Open Source. If that decision really turns out to be so bad then it will be forked and a wiser leader(s) will have their shot at decision making.

`dep` isn't squashed! You are free to continue using it, it's just that they likely won't find much audience anymore.

[munificent]

> If that decision really turns out to be so bad then it will be forked and a wiser leader(s) will have their shot at decision making.

No, that doesn't work in practice. The network effects are so insanely dominant in open source projects that forks are nowhere near an efficient market.

[stcredzero]

The network effects are so insanely dominant in open source projects that forks are nowhere near an efficient market.

The market doesn't have to be anywhere near efficient. It just has to allow any escape whatsoever from a death-march/death spiral.

[nicpottier]

Open Source is absolutely chock full of examples of this.

[munificent]

That's survivorshop bias. Yes, occasionally a fork takes over. It very rarely succeeds and usually only in cases where the original is so toxic that it cancels out its own network effects. node.js is a good example of that. And then even there note how they eventually unforked.

[jessaustin]

It is really uncharitable to describe the node fork as "so toxic". People disagreed, but there's nothing wrong with that. I felt like the subsequent "merge" happened fairly quickly and with minimal drama.

Also this seems like a misuse of the term "survivorship bias". You claimed upthread that forks don't work because of network effects. The response was "some forks work". That is a direct refutation, no matter what the percentages are. Besides, you're misunderstanding the varied purposes of forks. I have several forks right now, not because I hate the original maintainers but because it was convenient to change a small thing for my own purposes. Whether or not upstream eventually agrees with me, my fork "works" perfectly well.

[ansible]

And sometimes the new community wins out over the existing one. LibreOffice vs. OpenOffice, X.org vs. XFree86, etc.

[geodel]

Libreoffice vs Openoffice, Hudson vs Jenkins, and there would be so many more.

[weberc2]

Like the OP mentions in another comment, this is survivorship bias.

[Vendan]

It has literally happened before. Look into the node.js/io.js fork.

[kasey_junk]

> Most of the community, myself included is pretty psyched about go modules.

Citation needed. In my corner of the community this is a very contentious issue.

The golang dependency management story has been a disaster for years. Nothing about the modules or vgo story have seemed to solve that.

In fact, its Russ who seems to be going against the norms of the community. Choosing cutting edge and untried technologies, over well understood and tested ones. If he was going to get edgy with his leadership decisions couldn't he have done it somewhere more valuable like cleaning up the type system?