Reasonable fixes should still be possible.
Process is incredibly important. Collaboration is one of the most foundational values for any open source community.
Most of all, i'm sorry that i've not provided a clear, comprehensible explanation of my concerns. i hope that this story, plus the screencast, fix that.
Unhealthy collaboration hurts us in both the short and long term.
i'm speaking up about it anyway, as i believe that an honest accounting of damage done is prerequisite to moving forward, and defining our values as a community.
i understand why it's tempting to make dep-vs-modules comparisons, but it's usually not relevant, if not misleading and harmful.
1. the visible bits: CLI commands, Gopkg.* files, etc.
2. the version selection engine
3. the VCS source management system
i always expected 1 to change. Really, to disappear. 2&3, i'd hoped to keep and evolve.
“Dependency hell is NP-complete. But maybe we can climb out.” research.swtch.com/version-sat
True. But not for lack of trying on our part - our efforts to collaborate on such a mammoth undertaking were ignored.
We had no idea what was on or off the table. Or what negative community consequences (wasted work/goodwill) a misfire proposal might have.
It took me a few weeks to assemble a response. docs.google.com/document/d/1NA…
That took up all my dep contribution time during those weeks.
Even when a Go team member told me in early July that word was Russ was planning to just ~""rip out all that crap"" (rough quote), it still seemed absurd."
During that meeting, some of us were quite resistant to the idea. At minimum, four-on-one wasn't a good dynamic.
To the extent i was defensive, it was primarily from having to field yet another greenfield idea, after months of silence.
(Yehuda is the original author of Bundler (Ruby) and Cargo (Rust), and a friend)
He apologized, though i now see this for the red flag that it was.
Besides, he's BDFL. Why would our rejection even matter?
So, no: our work was disqualified before discussion even began.
So, i trusted him, and trusted the process - however academic it may have been.
The new baby is why i'm not at Gophercon - too close to due date!
Some of that was disdainful comments, like the closing line of research.swtch.com/vgo-mvs
More than one baffled package management friend from other languages asked me, ""Why is he even doing this?"
For example, the Kubernetes/YAML issue that featured so prominently was a problem with glide, not dep. (It's easiest to link to in the proposal: github.com/golang/proposa…)
Russ was flatly uninterested. IIRC, he shut down that entire conversation with "this (vgo) is the path Google is interested in pursuing."
(Yes, i probably should've just finished PV. i still may.)
This was partly an emotional defense mechanism. When the rug is pulled from under me, i tend to hide from public view until i've found somewhere stable and safe.
And i did. i refer to the single most critical problem with the design as "information loss."
It's something you'll have to think about all the time, as we were discussing over here:
(i've explained labor extraction many times - and again, in the screencast.)
But a non-problem? No. 3 days after modules were merged, someone hit it and emailed the list: bit.ly/info-loss-stri…
Which is just silly - subtle behavioral incompatibilities will always exist. It's Hyrum's law, which everyone involved agrees on. hyrumslaw.com
(This behind-the-scenes view has also led me to wonder what user pain other Go proverbs might be concealing.)
But yes, my two messages are quite disjoint. That's because his response to my olive branch was, roughly, "MVS and SIV are happening, and you need to accept it."
Or why his story, and apology, came long after the committee's decision to accept his proposal.
But that brings us around to this tweet.
If these arguments weren't true all along? That's engaging in bad faith.
Which i get. But now, we're not talking about high-minded design, or hard choices in pursuit of the best outcome, or the most scalable solution for an ecosystem.
That's just workflow preferences.
No matter your take on the outcome, this process was extraordinarily toxic. We can't chew up and spit out community members on every major change.
However, it doesn't seem like the community should look to Google/the Go team for leadership on good collaboration.
If we, as a community, want to see better process and outcomes, the better governance model will need to come from us.