[Dbix-class] The email I didn't want to write.

[Matt S Trout]

(I've been absent from the discussion since sunday night because I've been
thinking through and then writing this up; please believe me when I say that
I really didn't enjoy the process, but could no longer see how to avoid it)

So, up until a few days ago, the conversation seemed to be about establishing
a new team, and figuring out how we make that team accountable, and then
moving forwards from there.

Now, of course, it's going to be about "do we establish a new team, or do
we accept ribasushi's offer to continue part-time as dictator?".

Which means now rather than giving riba the send-off-with-applause that his
technical contributors have more than earned him, I'm going to have to talk
about the policy and human factors issues that exist around DBIx::Class and
its place in the greater CPAN ecosystem, because otherwise there's going to
be no way I'm going to feel like the userbase is making an informed decision.

And, y'know, letting you lot make an informed decision was exactly what led
me to ask riba to explain his plans in the first place, even though before I
made a start I was already pretty much expecting that the response would be
an attempt to paint me as satan.

Which, well, https://twitter.com/ribasushi/status/776259074497323008 - I'm
pretty sure "rabid badger" wasn't intended as a compliment.

Happily (from my POV, at least) his position was that his right to
unilaterally repudiate a previous agreement over permissions with a PAUSE
admin (which I'd've documented publically had I known then what I know now,
but at the time figured was quite sufficient given I was dealing with a
partner in crime and close friend who I trusted to keep their word) was based
on moral authority derived from the support of the DBIC userbase, and so the
PAUSE administration insisted that you actually be consulted.

Of course, that didn't mean actually revealing a plan, but instead
complaining that being expected to consult with the userbase was evil
and terrible and somehow made it impossible to have a plan at all. But it
was engagement at least.

Now, however, as of https://twitter.com/ribasushi/status/790515094685876224
there is sort of a plan.

The trouble is it's at least as risky as mine is, albeit along different axes.

If this was ribasushi-of-2012, say, I'd be inclined to say "I'm not sure
why you want to drop everybody else's co-maints, but otherwise I'm totally
happy with you staying in charge indefinitely". However, it isn't.

http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012282.html

gets one thing right - my views on stability haven't changed a lot since
2005. In that I care about it rather a lot, but refuse to consider it the
only factor.

Thing is, these days riba's views are rather more absolutist than that, and
involve branding anybody who doesn't value it exactly as much as he does as
(variously) irresponsible, incompetent or malicious.

We had a long chat at one point about the idea that accusing somebody of
active malice towards their userbase over a technical disagreement (in this
case fatal warnings, which, roughly, I love because I'm more worried about
code 'completing' but doing the wrong thing are thereby causing data loss or
corruption, and riba hates because he's more worried about code throwing
unexpected exceptions in cases that would've worked fine otherwise ... and
thereby causing data loss or corruption) is ... not only probably not the
case, but even if it is, actively counterproductive. In the end, in this
particular case, it became clear that most people found fatal warnings an
unpleasant default and while I continue to encourage people to try them out,
I'm comfortable that they'll never be universally loved.

Thing is, the amount of bile directed at me during the process basically made
me avoid the entire thing for about six months because I was sufficiently
upset by the accusations of malice that, frankly, something else always seemed
a more interesting thing to spend my weekend on. This significantly delayed
my concluding I was wrong and fixing my mistake, to the detriment of users.

Those who've known me over the years are probably aware that I'm both thicker
skinned than average and also more comfortable being blunt (sometimes to the
point of accidental assholery) than average - so it shouldn't surprise you to
know that the same effect happens when other people are treated the same way.

Hell, I know I've accidentally driven people off with overly heated
arguments. But I consider that to be a bug in my argument process since on
a human level it's toxic to the contributor group and on a techical level
it usually means things take even longer to get fixed. riba-of-2016 doesn't
seem to see that as a problem at all that I can tell.

Back in May, he added comments to the source code directly attacking rjbs
for the crime of disgreeing with him technically, and when ilmari and I
suggested this wasn't really acceptable, he posted

http://lists.scsys.co.uk/pipermail/dbix-class/2016-May/012164.html

to the mailing list and then walked out of the #dbic-cabal channel; happily,
the following day he quietly removed the comments in

https://github.com/dbsrgits/dbix-class/commit/e8452b02f9db53148f3d0bc6679a107a9c956174

but you will, of course, notice that in spite of being a long time DBIC user
albeit no longer pumpking, rjbs' voice has been absent from this discussion.

That 4/5 email struck me as, frankly, jaw dropping. The attacks on me I
figured were inevitable but lashing out at ilmari and castaway as well, not
so much.

"loses interest whenever the problem space required a more in-depth solution"

This seems like a surprising description of ilmari, given he holds the
first-come permissions for both DBIx::Class::Schema::Loader and SQL::Abstract
and conducted a huge and highly successful refactor of the former. I've
always found him to, in fact, be somebody once can happily spend hours
discussing in-depth solutions to hard problems ... so I rather suspect that
if that's riba's experience of his work of late, the reason for loss of
interest in those cases is more about treatment than technical effort.

One of the things I think makes a difference here is that I love mentoring
people, and helping them level up, and getting them to re-work their code
until they can be proud of it even if that takes much longer than re-writing
it myself would've done, and generally riba seems to find that a much more
energy consuming process than I do.

The thing is, if you don't do that, you don't grow a sustainable team. When
ether first started releasing toolchain level code, there was some carnage
... which she generally had corrected within a day or two, and which she
rapidly took as feedback to adjust her style to be more conservative. These
days, she's not only maintaining/releasing quite a few things - see
https://metacpan.org/author/ETHER - but is generally part of the arguments
in favour of being relatively conversative and has been helping newer
recruits learn the same lessons.

DBIx::Class, on the other hand, hit the "no co-maintainers and no successor"
wall, and given just how much fun this has been for everybody I hope it's
understandable if I think taking steps so that doesn't happen again would
be a good idea (hence my governance proposal being explicitly designed to
just turning me into a new SPOF).

Meanwhile, we've now reached a point where seeing a ticket or patch sent in
by ribasushi tends to result in people ignoring it for a few days because
they need to work up the emotional stoicism required to deal with the chances
of it being a useful patch/ticket that happens to come with a free polemic.

Plus his tendency to refuse to compromise or believe in consensus tends to
harden other people's attitudes, resulting in a number of fights between us
that boiled down to "riba will accept no compromise because that would mean
endorsing an imperfect solution, mst would prefer to get as many concessions
as he can to stability and then endorse the result". So ironically, his
disappearance from those discussions as of more recently has actually made
it easier to shift things overall in the direction of stability, in spite of
losing somebody who I used to basically rely on having on my side in such
discussions.

I believe on previous occasions riba's crystallised this as "open source
is about the users, not us", and considered technical excellence to be the
only thing of relevance in how a project is run. The thing is, I don't
really think open source is *about* the people developing as such. What I
think is that open source is *made of* the people developing it, because
if you don't build a team around a project it ends up with a bus factor of
one, and a project like DBIx::Class is sufficiently important that that
simply isn't safe.

So, roughly, we're looking at a choice between

- a cathedral type approach
- run by the single most effective committer we've ever had
- but part time
- with no team, and likely no team going forwards, leaving the bus number at 1
- although riba-and-only-riba will be amazingly free of bugs
- who's actively attacked and/or alienated the owners of many of our downstream
  dependencies, including the crucial SQL::Abstract
- who didn't even think the userbase needed to be consulted about this

(and obviously given riba's explicit insistence that I be run out of town on
a rail, there's no way I could credibly start a DBIC2, so I'm afraid anybody
who wants a fork needs to make sure they've got somebody to run it first)

versus

- a bazaar type approach
- run by people who've all got noticeable amounts of code in the system
- but aren't currently nearly as familiar with the internals
- intending to build out a team of contributors, which will almost certainly
  mean that at some point somebody will screw up and we'll have to scramble
  to do a bugfix release
- but that's how you get the bus number up if you want a sustainable project
- who're well known and (with the partial exception of me) well liked among
  the maintainers of the projects we're dependent upon
- who intend to operate under a system where if we do screw up, the userbase
  have an explicit mechanism to hold us to account

(and we can, internally, run a two-stream development system where people
opt-in to a version of DBIx::Class with new features but probably also new
bugs, and changes migrate down to the main stable release over time - this
can be done without disrupting the ecosystem, I think; pulling the same trick
off as a fork may be trickier)

Both plans have their risks, definitely. I have an opinion as to which plan's
risks scare me less overall, obviously.

I'm off to Cluj tomorrow and so I'm not sure when I'll be able to get an
updated governance proposal together - hopefully by monday if not sooner.

This email is intended to both communicate my reservations about the
part-time-riba plan, such that they can be taken into account when whoever's
doing so writes up the proposal for that, and to draw attention to the key
axes of disagreement to help people to understand how I see the problems
at hand to inform their decision making for the final vote.

If, however, you still consider the governance proposal to be the worse risk,
you should absolutely vote against it - after all, my entire goal here was to
give the userbase a say in the future of the project, and if you use that say
to vote it down en masse then that genuinely still meets that goal.

Thank you for reading. I'm going to go grab a beer and miss the old riba.

-- 
Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue

http://shadowcat.co.uk/blog/matt-s-trout/   http://twitter.com/shadowcat_mst/

Email me now on mst (at) shadowcat.co.uk and let's chat about how our CPAN
commercial support, training and consultancy packages could help your team.