On Friday, 26 May 2017 at 11:32:21 UTC, Andrei Alexandrescu wrote:
One thing that several of those people emphasized is we need to
improve leadership and decision. "You are trying to do
democracy and democracy doesn't work here" (by a successful
I'm pretty sure nobody actually involved with D would call it a
democracy. We may get to say our piece, but ultimately the core
Walter and I have implicitly fostered a kind of meritocracy
whereby it's the point/argument that matters.
That's because that's all that matters. It is what almost every
worthwhile organization aspires to, though very few get there.
Doing anything else would be a mistake.
It should be meritocracy of the person - good proven
contributors have more weight and new people must prove
themselves before aspiring to influence.
Certainly you can weight their opinion more because they know the
code better, but otherwise it is precisely this personal
influence taking precedence over the particular argument that
sinks most organizations.
Historically, anyone with any level of involvement with D could
the forum and engage the community and its leadership in
debate. Subsequently, they'd be frustrated with the ensuing
disagreement and also get a sense of cheapness - if I got to
carry this unsatisfactory debate with the language creator
himself, what kind of an operation is this?
Or they were inspired that their feedback was taken into account,
if not followed, and decide to pitch in.
Since anything can be debated by anyone, everything gets
debated by everyone. Anyone can question any decision at any
time and expect a response. It's the moral equivalent of
everyone in a 5000-person company building can expect to stop
the CEO on the way to his/her office and engage them in a
conversation of any length. The net consequence is slower
If you're going in the wrong direction, slower progress is to be
I think you're overly critical of the culture of debate that is a
part of open source and especially this project. I know I
decided to pitch in after years of lurking in the newsgroup, I
doubt I'm the only one.
Of course, like anything, debate can be overdone and you're
probably right that it has been at times here. But an open
source project is a fundamentally different thing than a startup,
it requires much more community involvement and deliberation. I
recommend reading this chapter from this book on open source
"Public discussion generally takes longer to make a decision than
a proprietary development group does, but because the diversity
of the viewpoints is greater for an open-source effort the
resulting decision is likely to be of higher quality. This can
translate into a shorter overall development cycle, because
subsequent work will probably not need to be discarded because
the real issues came up after, rather than during, the discussion
Where we need to be is fostering strong contributions and
contributors. The strength of one's say is multiplied by
his/her contributions (and that simply means pulled PRs,
successful DIPs - not "won" debates). Many successful OSS
projects have been quoted as implementing this policy
There are different ways to contribute. One may not have time to
work on a bunch of PRs/DIPs or may be better suited to discussion
of the technical design.
I agree that we need more people contributing rather than just
talking, but I don't think this is the way to do it.
Every person in the room took a significant fraction of the
meeting time to tear me a new one about dub and
http://code.dlang.org. Each in a different place :o). I got to
the point where I consider every day spent with code.lang.org
just sitting there with no ranking, no statistics, no voting,
no notion of what are the good projects to look at - every such
day is a liability for us. We really need to improve on that,
it is of utmost importance and urgency. Martin said he'll be on
that in June, but we could really use more hands on deck there.
Yeah, I mentioned this need before too.
Documentation of vibe.d was also mentioned as an important
problem. More precisely, it's the contrast between the quality
of the project and that of the documentation - someone said his
team ended up with a different (and arguably inferior) product
that was better documented. Literally they had the same
engineer try each for a day. Reportedly it was very difficult
to even figure whether vibe.d does some specific thing, let
alone tutorials and examples of how to do it.
Eh, documentation is going to be sparse for a non-corporate OSS
project. If they're building products with vibe.d, presumably
they can throw some consulting dollars Sonke's way and get him to
Back to community: Successful OSS projects have a hierarchy and
follow formalized paths and processes for communicating up and
down. People are willing to work/wait for months on a proposal
because they have a sense of process and a confidence their
proposal, if properly done, will get a fair shake. These are
good ideas to follow (and indeed I got more confirmation that
investing in our new DIP process is a good thing to do).
Rather, it is a blend, some hierarchy on top of a wide herd of
cats. ;) But sure, improving the process will help.
We need to improve the collaboration and tone in the forums and
github. (I was amazed at how well these business and community
leaders knew who's who in our community.) We can only assume in
the future people will peruse our forums/github to decide
whether to use D in their enterprise. We need to improve on the
current disposition toward fruitless debate not concluding in
As I said above, even "fruitless" debate can help, but like
anything else, it can be overdone.
What hurts us the most and stands like a sore thumb is the
occasional use of abusive language. We need to stop that.
Any large community is going to have it, tough to police.
Many of these things I had a good sense of before entering the
meeting, and was on the way toward improving on them. The
meeting provided a strong confirmation of the importance of
these matters, and good ideas toward doing better.
I'm sure there was some good advice, but I'd caution that these
entrepreneurs were not running an open source project, which
requires a much lighter touch.