On Tuesday, 9 January 2024 at 15:01:28 UTC, H. S. Teoh wrote:
> On Tue, Jan 09, 2024 at 02:02:36PM +0000, BlueBeach via Digitalmars-d wrote:
>> On Tuesday, 9 January 2024 at 13:22:08 UTC, Timon Gehr wrote:
>> 
>> > ... See druntime.
>> I'm not familiar with this case. It is part of the DMD repository. Can you link/give a little more background?
>
> [...] In 2004, after attempting to work with upstream, these developers were left
> 	with no option but to fork the language to keep their
> 	contributions [...]

Thanks for the info and wow. Thats 20 years ago (already) ...

> After more than 10 years of this very same pattern repeated over and over -- someone comes on board, actively contributes, sometimes makes major contributions, then leaves in a huff or withdraws from active contribution -- one cannot help asking the question, why?  What are we doing wrong that's driving willing contributors away?  What should we do to change this?

Since you asked , I hope it is OK if I share my opinion on this topic although I'm mostly a lurker and not active in the community.

I think the main reason for some of the reoccurring organisational issues and their unpleasant side effects are unresolved questions around Walters authority. Since Dlang is an Open Source project, there are expectations on a certain level of democracy. Nobody is perfect and a flawed democracy would probably suffice, but a lot of people seem to experience the Dlang community as a flawed oligarchy where only a minority has a saying and sometimes even those people are omitted. Maybe a less nice way to describe the style of this project is a mix of meritocracy and dictatorship. While nobody is against leadership by merit, there is a reason why autocratic forms of government are disliked: They are poor in words and highly unpredictable.

In the end only Walter as the founder of the project can decide how and if he wants to define and exercise his authority and how fundamental democratic structures should be. One thing I know for sure: If you want a more democratic and predictable leadership you are not getting it by chance. It is not the natural state and you really have to fight (or work) for it.

On Tue, Jan 09, 2024 at 05:06:20PM +0000, BlueBeach via Digitalmars-d wrote: [...]
> I think the main reason for some of the reoccurring organisational issues and their unpleasant side effects are unresolved questions around Walters authority. Since Dlang is an Open Source project, there are expectations on a certain level of democracy. Nobody is perfect and a flawed democracy would probably suffice, but a lot of people seem to experience the Dlang community as a flawed oligarchy where only a minority has a saying and sometimes even those people are omitted. Maybe a less nice way to describe the style of this project is a mix of meritocracy and dictatorship. While nobody is against leadership by merit, there is a reason why autocratic forms of government are disliked: They are poor in words and highly unpredictable.
[...]

>From the first paragraph in Adam's blog on 2024-01-01:

	While the oft-repeated claim that D is a closed-source language
	is not really true (the D-specific parts of the compiler were
	GPL'd as early as 2002, leading to an all-GPL compiler (what we
	now know as gdc) being released in 2004), it is true that D's
	development methodologies are not especially open and that
	decision making has very little meaningful input from the
	community, and this has been true for its entire history.

It has always struck me as somewhat incongruent that while D's *code* is open source and licensed under an open source license, its development methologies are very much entrenched in the proprietary (commercial), closed source mentality. A mentality where decisions are made behind closed doors and there is no obligation to provide any rationale.  This leads to a lot of friction with contributors who come in expecting a more open style of development that one would expect to find in an open source project, but discovering to their chagrin that it's being run as if it were a closed source, proprietary project.

Of course, this project was initiated by Walter and he has the right to choose whatever development methodology he wishes, and if you wish to play ball in this project then that's just what you have to work with. And I'm not saying that this style of management 100% doesn't work.  But D's history has shown us time and again that it is at least one of the sources of much frustration on the part of contributors who are expecting an open source project that's run more like an open source project.

Given our track record so far, perhaps it's time to reconsider the very fundamental principles by which D is being managed.  From a technical standpoint, D has no parallels that I know of -- it comes very close to my ideal of what a programming language should be.  But the way it's managed leaves a lot to be desired.  It would be a pity for this beautiful language to languish when under a different style of management it could be flourishing and taking over the world.


T

-- 
Never criticize a man until you've walked a mile in his shoes. Then when you do criticize him, you'll be a mile away and he won't have his shoes.

On Tuesday, 9 January 2024 at 17:42:11 UTC, H. S. Teoh wrote:
> [...]

I dont see how a D fork managed by Ruppe could be managed in a better way.
That would be a downgrade. You oppose someone who spent years into trying to maintain a community to someone who gets crazy over a single disagreement.

On Tuesday, 9 January 2024 at 15:01:28 UTC, H. S. Teoh wrote:
>

Great comment.

I love Andrei but yes that Good Work vs Great Work thing was meant to be motivational BS but was actually just plain BS.

Andrei also teased the community with leadership-backed evolution of Phobos, but then he failed to show up.

A few birds-eye view observations of my own:

* D is Walter's baby and his life work. As other people come and go, as they are wont do with any project such as D, he knows he will be left holding the baby and maintaining it. That is why he will not accept PRs unless they appeal to his taste and he is confident they are a net positive and don't complicate the whole thing too much. I fully expect Adam to start behaving like this BTW, for the same reasons.

At some point in the history of D it was realised there needed to be a way to make the evolution of D more democratic. This is when DIPs were introduced. However, Walter's reluctance to accept DIPs made them an infamous time sink and often a dead end.In my view this is not unreasonable but it's certainly annoying for would-be contributors.

* Languages such as D need a BDFL who spends more time managing and orchestrating developments than cutting their own code. However, if often doesn't work out like that. Walter becomes a bottleneck and until he steps back from CTO, he will remain so.

* In the python world, the standard library is considered to be the place where libraries go to die, because the API becomes frozen. I agree with that take, and would concentrate on having a good packaging system where it's easy find the popular and well maintained libraries for given tasks e.g. XML, json, database clients etc. Forget about fighting to get stuff into Phobos, it's too hard and a fool's errand.

On Tue, Jan 09, 2024 at 06:09:19PM +0000, user1234 via Digitalmars-d wrote:
> On Tuesday, 9 January 2024 at 17:42:11 UTC, H. S. Teoh wrote:
> > [...]
> 
> I dont see how a D fork managed by Ruppe could be managed in a better way.  That would be a downgrade. You oppose someone who spent years into trying to maintain a community to someone who gets crazy over a single disagreement.

You are free to form whatever opinion you like of me or Adam, it doesn't bother me. But I have worked with Adam before, and he's generally much more open to contributions than Walter, and generally more pragmatic about not holding things up and letting the perfect be the enemy of the good. And he doesn't strike me as the "crazy" reactionary type, even though lately, before the fork, he did seem unusually riled up. Which, given the frustrations he has gone through in the past years, isn't entirely unexpected either.  And it is far from a merely "a single disagreement"; that was merely the last straw that broke the camel's back after many years of pent-up frustration.

I'm not 100% in agreement with his approach either, but given D's track record, which I've already elaborated on at length and won't repeat here, I'm interested to see where this leads. It may lead nowhere as the naysayers are already saying, but it may also lead somewhere D ought to have been but hasn't gotten to so far for the aforementioned reasons. It will be educational to see how this all pans out.  Ultimately, I, and Adam himself as he already expressed privately to me, hope that this fork will lead to D moving past its present roadblocks and making progress instead of continuing to stagnate.  The goal isn't to oppose Walter or anything in the current D leadership, but to bring D forward.


T

-- 
Frank disagreement binds closer than feigned agreement.

On Tuesday, 9 January 2024 at 18:09:19 UTC, user1234 wrote:
> On Tuesday, 9 January 2024 at 17:42:11 UTC, H. S. Teoh wrote:
>> [...]
>
> I dont see how a D fork managed by Ruppe could be managed in a better way.
> That would be a downgrade. You oppose someone who spent years into trying to maintain a community to someone who gets crazy over a single disagreement.

Adam's been around for ages, come on now.

FWIW I contributed to both projects over the weekend because I view the fork as more of an opportunity to try things out rather than the future necessarily, and it was a lot easier with the fork.

A lot of the practices and layout of the main D project are either antiquated or just bad, a fork is a nice way to try out new stuff and learn something rather than making a plan to make a plan about how you might fix things.

On Tue, Jan 09, 2024 at 06:23:47PM +0000, Abdulhaq via Digitalmars-d wrote: [...]
> A few birds-eye view observations of my own:
> 
> * D is Walter's baby and his life work. As other people come and go, as they are wont do with any project such as D, he knows he will be left holding the baby and maintaining it. That is why he will not accept PRs unless they appeal to his taste and he is confident they are a net positive and don't complicate the whole thing too much. I fully expect Adam to start behaving like this BTW, for the same reasons.

Adam is already doing this. There's been a ton of proposals and ideas, and while he hasn't straight out turned down anyone yet, he *is* already warning that everything will be evaluated based on whether they bring a net positive, or will simply be too costly to be worth the effort.

There are nuances to such management, though. Take Linux for example. Linus still calls the final shots for whatever makes it into the kernel. But he knows how to delegate -- he has not a small number of trusted delegates that look after major subsystems, and he trusts them to make decisions of their own without always needing to go through him. He can still override their decision if he sees something obviously wrong, and he can (and has) reverted stuff that he feels were wrong after the fact. But the key point is that he does not demand that every decision go through him, and that's what keeps him from becoming a bottleneck.

We do have something similar in D to some extent, but nowhere near the point where Walter ceases to become a bottleneck.  The whole process could use more streamlining. A LOT more.


> At some point in the history of D it was realised there needed to be a way to make the evolution of D more democratic. This is when DIPs were introduced. However, Walter's reluctance to accept DIPs made them an infamous time sink and often a dead end.In my view this is not unreasonable but it's certainly annoying for would-be contributors.

It's definitely reasonable. Walter is the one who decides what goes into D and what doesn't, so naturally he needs to be fully convinced of the value of a DIP before he will accept it.  His standards are naturally high -- D being what it is, it could hardly be otherwise.  Unfortunately he has also shown time and again that he often misunderstands exactly what is being proposed, and appears reluctant to take the time to understand the proposal before shooting it down.  It's his prerogative, of course, but it does make working with him a rather challenging task. One that not many would-be contributors would be willing to go through.


> * Languages such as D need a BDFL who spends more time managing and orchestrating developments than cutting their own code. However, if often doesn't work out like that. Walter becomes a bottleneck and until he steps back from CTO, he will remain so.

And this is where we have trouble: Walter and Andrei are technical geniuses, but the way they interact with the community is, how do I put it, lackluster.  This thread is a prime example: when confronted with a full-out fork of the project, any manager in charge would at least be, to put it mildly, *somewhat* concerned, and at least try to engage with the issues being presented, even if it is to disagree.  However, here we have dead silence on the core dispute and instead lots of activity on a tangential technical issue.  OT1H it shows where Walter's strength is -- grappling with technical issues -- but OTOH it also leaves a lot to be desired on the management side of things.


> * In the python world, the standard library is considered to be the place where libraries go to die, because the API becomes frozen. I agree with that take, and would concentrate on having a good packaging system where it's easy find the popular and well maintained libraries for given tasks e.g.  XML, json, database clients etc. Forget about fighting to get stuff into Phobos, it's too hard and a fool's errand.
[...]

But why does it have to be this way?  Why must the standard library be held to such unattainable standards that nobody but a rare few could reach it?  Maybe it's time to reconsider how it is managed.  Why can't it be open for the community to maintain?  Delegate each major module -- std.json, std.xml, std.db (hypothetical), etc., to one or two competent people who are enthusiastic about it and who can maintain it long term, then take your hands off and just let them do their job. Micromanagement helps no one and only hurts in the long term.  People need to earn their trust, it's true, but once they've earned it, they also need some room to do what they do, rather than be stifled by onerous demands or unreasonably high standards.

I'm not saying this is a silver bullet that will solve all D's problems, but why not give it a try and see?


T

-- 
The diminished 7th chord is the most flexible and fear-instilling chord. Use it often, use it unsparingly, to subdue your listeners into submission!

On Tuesday, 9 January 2024 at 15:01:28 UTC, H. S. Teoh wrote:
> It's not just the slow procesing of PRs. It's the arbitrary shutdown of contributions after months, often years, of silence, with no prior warning and no regard of the amount of work put into maintaining said PRs over that length of time. And often while totally misunderstanding what was actually done, as is being shown right at this moment with the discussion on DIP 1036e.

Though I don't have a long-standing track record of contributing to D, my futile attempts to even get anywhere were so painfull I just stopped bothering very quickly. It always sucks to get critisized, but it sucks extra when you're not even told what to do with this criticism. Most of the time, D community seems to try and look like it cares about the end user, but in reality (this thread is a confirmation) it's just pointless bantering about something that the end user doesn't care about. More importantly, this pointless bantering is used as an escape goat to shut down changes that DLF doesn't want/like, yet DLF itself never bothers with breakage if it implements some kewl new feature that nobody asked for.

As a result, the string interpolation that works very well right now in opend, can't get into upstream D because someone just doesn't want to accept it. On the other hand, the same someone has spent an entire year on a feature that still doesn't work even remotely well.

> It's fascinating that Walter did not relate to this at all, but readily jumped into a lengthy technical discussion of a
> tangentially related topic.

Which is why a fork was created in the first place.

> I dont see how a D fork managed by Ruppe could be managed in a better way

Actually, Adam might be the only person that is genuinely interested in getting things done. He is very quick to answer and __never__ goes down to pointles philosophical discussions.

On Tuesday, 9 January 2024 at 19:19:51 UTC, H. S. Teoh wrote:

> But why does it have to be this way?  Why must the standard library be held to such unattainable standards that nobody but a rare few could reach it?  Maybe it's time to reconsider how it is managed.  Why can't it be open for the community to maintain?  Delegate each major module -- std.json, std.xml, std.db (hypothetical), etc., to one or two competent people who are enthusiastic about it and who can maintain it long term, then take your hands off and just let them do their job. Micromanagement helps no one and only hurts in the long term.  People need to earn their trust, it's true, but once they've earned it, they also need some room to do what they do, rather than be stifled by onerous demands or unreasonably high standards.

Maybe create a collection of libraries? Something like a boost for c++, which is community-driven. Some libs from boost time-after-time got merged to std.

On Tuesday, 9 January 2024 at 19:19:51 UTC, H. S. Teoh wrote:
> [snip]
>
> And this is where we have trouble: Walter and Andrei are technical geniuses, but the way they interact with the community is, how do I put it, lackluster.  This thread is a prime example: when confronted with a full-out fork of the project, any manager in charge would at least be, to put it mildly, *somewhat* concerned, and at least try to engage with the issues being presented, even if it is to disagree.  However, here we have dead silence on the core dispute and instead lots of activity on a tangential technical issue.

There's a bit of "damned if you do damned if you don't" on this point.