| |
 | Posted by H. S. Teoh
in reply to IGotD- |  Permalink Reply |
|
H. S. Teoh 
Posted in reply to IGotD-
| 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.
|
