[nicpottier]

Ya, I've been following all this drama since the vgo proposal and I also find it somewhat rich. I mean in a way didn't the `dep` folks do exactly the same thing to the `glide` and other existing solutions? At some point you just have to say, hey, you've done good work but I think another approach is better. They did that to glide and Russ did that to them.

Note also that he doesn't dispute that Russ tried to bring them into the fold with his concerns and direction but they rejected his arguments. That's a fight they should have known they were going to lose.

Maintainers / BDFLs get the final say, that's just how it is. Just because there is a large community does not mean they get the final say, just because you put in a lot of work does not mean you get the final say. The reason BDFLs are in the position of making that decision is because they have proven through the accumulation of their previous decisions that they get it right more than they get it wrong. And that's the very reason there is a community around them at all.

If you walk into ANY project, public or private, open sourced or closed, and ignore the lead's objections when you go off in a direction they don't agree with, then yes, you are very likely in for some wasted work. That's just how the world works.

On another note I hope this is the last we hear about all this, please lets move on.

[stcredzero]

Ya, I've been following all this drama since the vgo proposal and I also find it somewhat rich...On another note I hope this is the last we hear about all this, please lets move on.

I only became aware of this by going to a meetup and seeing a talk. I just want something that's workable and not broken.

The reason BDFLs are in the position of making that decision is because they have proven through the accumulation of their previous decisions that they get it right more than they get it wrong. And that's the very reason there is a community around them at all.

This is the same reason given for totalitarian rule generally. The problem is that the dictator has enough power to make a big mistake, committing the entire communitiy's resources. In this position, if you can avoid making a decision, you should. Toyota doesn't simply make such decisions by fiat. Instead, they have a competition.

I mean in a way didn't the `dep` folks do exactly the same thing to the `glide` and other existing solutions?

Was the competition squashed?

[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?

[yawboakye]

> This is the same reason given for totalitarian rule generally. The problem is that the dictator has enough power to make a big mistake, committing the entire communitiy's resources. In this position, if you can avoid making a decision, you should. Toyota doesn't simply make such decisions by fiat. Instead, they have a competition.

You're comparing very different things. Programming languages and empires/nations/companies aren't the same thing. Rails has stayed on the course DHH wants it and hasn't become a mess mainly because DHH remains the BDFL. Go could benefit from similar structure. We're now about to see how Python will do post-Guido.

[munificent]

> Rails has stayed on the course DHH wants it and hasn't become a mess mainly because DHH remains the BDFL.

\* and DHH happens to make good decisions frequently enough.

For every successful BDFL example, history is littered with a hundred dead languages and frameworks designed by a single visionary leader who made the wrong decisions.

[vorg]

> a hundred dead languages and frameworks designed by a single visionary leader who made the wrong decisions

E.g. there's the namesakes for Rails and Ruby, i.e. Grails and Groovy. Virtually no-one's upgraded to Grails version 3 since it came out 3 yrs ago, or started new projects in Grails version 2. The Grails 2 plugin ecosystem is as good as dead. It only has its "single visionary leader" listed for the 3 contact persons (owner, admin, tech) in the grails.org DNS registration.

As for Apache Groovy, it's hanging on as the build language for Gradle and Android Studio, but doesn't seem to have any other significant use besides its original use case of glue code and testing harnesses. Groovy's problem is its creator, who had successfully added closure functionality to a clone of Beanshell, left the project after 3 yrs and the "despot" at Codehaus who subsequently claimed the title Project Manager was someone who didn't have the aptitude for many programming tasks.

[geodel]

So is other way round. Huge numbers of failed design-by-committee or community projects. What you say is truism not particularly insightful or useful.

[claydavisss]

The only meaningful example of this I can think of is Larry Wall and Perl...but his mistake was in loosening his grip instead of tightening it. Perl6 started off as a utopia wherein Larry was only considered slightly more powerful than any other contributor. This resulted in a revolving door of clowns taking the reigns and rapidly resigning as Larry looked on.

Fortunately Perl5 still does the Pumpking thing which is effectively a rotating BDFL.

[lizmat]

> This resulted in a revolving door of clowns taking the reigns and rapidly resigning as Larry looked on.

I would say that this hasn't been the case for the past 10 years at least. Patrick Michaud has been Perl 6 pumpking since then, to make room for Jonathan Worthington about 2 years ago. Hardly a revolving door and hardly clowns.

[eritain]

Parrot did burn through quite a few pumpkings. I wouldn't call them clowns either, but I do think they led Parrot astray. Obviously Parrot is not Perl 6, but they are closely linked in many people's minds for obvious reasons.

(It's not all the pumpkings' fault, either. I think Parrot would still have been doomed if its leadership were constantly flawless, just because it was designed before Perl 6's object system was.)

[claydavisss]

A competition still has to be judged by someone.

The only curious element here is that a (the?) judge also had the winning entry. Russ claims he got buy-in from the other core members and so far no one has contradicted that.

AND...vgo is better than dep. Let's not forget that. Peter can hem and haw about politics but in the end the best horse won.

Go developers want the tools to be as good as possible, 99% of them don't know anyone who contributes to Go by name so this drama is irrelevant to them.

[pcwalton]

> AND...vgo is better than dep. Let's not forget that. Peter can hem and haw about politics but in the end the best horse won.

Nobody has worked with minimum version selection and compared it to the traditional approach enough to know. I have serious reservations as to how it will work in practice.

[sagichmal]

> AND...vgo is better than dep. Let's not forget that.

Facts not in evidence.

[jessaustin]

After reading TFA, which tries to be self-serving but is mostly just silly, do you even doubt it? I say this as someone with no dog in any Go fight. When the defendant's own testimony convicts himself, he's guilty.

[stcredzero]

I couldn't tell if that assertion was ironic or not.