The forked elephant in the room

[H. S. Teoh]

On Mon, Jan 15, 2024 at 10:11:33AM +0000, IGotD- via Digitalmars-d wrote:
[...]
> Also if you believe that the fork was made just because disagreement
> about DIP1036 and DIP 1027 you are mistaken. The dissatisfaction with
> the D management and how the project is run has been growing for
> several years if not over a decade. It is rather surprising that a
> serious fork wasn't made earlier.

This is true, we have been repeating over the last decade or so the
pattern of attracting enthusiastic contributors due to the technical
excellence of D, only to have them turn around and leave after coming to
an impasse with the project's management.  As I have said previously,
the problem isn't so much that things did not go their way; I think any
reasonable person would understand that in technical decisions there's
always pros and cons and one could go either way, and that whichever way
a decision goes, it would work out, one could live with it.

No, the root of the problem is social, not technical. The thing is, the
overall impression a contributor gets is:

1) They have little or no say over key project decisions.

2) There are unwritten requirements that are not communicated
beforehand, but may suddenly appear at any time and land on you like a
pile of bricks, negating weeks or even months of hard work and effort.

3) Preferred solutions will go through by default, and to reverse them
is a long uphill battle.

4) Non-preferred solutions are not even considered by default, and to
get them considered at all is an equally long uphill battle, not to
mention an even longer uphill battle to get them approved.

5) Mistakes in preferred solutions in retrospect will generally not be
acknowledged, or papered over with convenient excuses, while similar
mistakes in non-preferred solutions will result in a ton of bricks
landing on its proponents.

6) Preferred solutions may cut corners in the approval process, but
non-preferred solutions must fulfill every last detail of a bureaucratic
process to the letter even for the most trivial of decisions, otherwise
they will be duly ignored.


These impressions are not necessarily accurate, of course. But they do
seem very real from the POV of would-be contributors, and can be very
demotivating. As long as they are not addressed, D is going to continue
experiencing manpower issues.

Again, this has nothing to do with technical merit; it's a social
problem.  A programming language project involves not only technical
issues, but social issues, because it has to be run by humans. Technical
excellence can only go so far before a contributor decides it's not
worth dealing with the social issues.

Unfortunately, it does not seem that this is going to change as long as
the current project management continues in its present course.  So it's
unlikely that it will ever be addressed.


> If you think that stopping the fork is going to help, think again. The
> behaviour of the D management is endemic and cannot be changed because
> much is linked to your personalities, much to the personally of
> Walter. For me the desire to remove binary literals was the wakeup
> call for me that something is not quite right and it cannot be fixed.

Now this is uncalled for. Where in Atila's post was anything mentioned
about stopping the fork?


> Now I cannot stop the D project to include things from openD and vice
> versa and I see no problems with that. However, trying to infiltrate
> the openD in order to derail it or influence it is benign and will
> lead to missed opportunities.
[...]

This is also uncalled for. Where in Atila's post is there anything to do
with infiltration?


T

-- 
A programming language should be a toolbox for the programmer to draw
upon, not a minefield of dangerous explosives that you have to very
carefully avoid touching in the wrong way.