January 19

On Friday, 19 January 2024 at 15:01:21 UTC, Don Allen wrote:

>

On Friday, 19 January 2024 at 09:50:06 UTC, Dukc wrote:

>

On Thursday, 18 January 2024 at 20:51:48 UTC, Paul Backus wrote:

>

Yes, that's certainly true.

My intent is not to focus on Adam Ruppe's case specifically, but on the broader pattern that also includes former contributors like Sebastian Wilzbach, Jonathan Marler, ag0aep6g, Suleyman Sahmi (SSoulaimane), etc. When one relationship fails, that's unfortunate. When a long string of relationships fail in the same way, that's a sign of a deeper problem.

Even if we grant that there was nothing more to be done in Adam's case, I think D's approach to contributor relationships is leaving a lot of value on the table.

I get the impression that these kinds of problems are more of a rule than an exception in succesful open-source projects though (by succesful I mean attracting dozens of contributors or more). Looking at the lobse.rs discussion Guillaume posted, Hacker news discussion about OpenD and considering what you hear about say Linus Torvalds or Theo de Raadt, strong enthusiasm to contribute seems to go hand in hand with a strong personality. I think keeping those kinds of contributors is simply hard. It might not be that hard for an average Joe were he leading, but I suspect the same qualities that make language creators succesful in the first place tend to make good leadership in these cases hard for them.

I don't think D leadership is doing particulary badly - otherwise they would be developing the compiler alone by now. But sure it's still a critical thing that might well determine the future between stagnation and an explosion in popularity. Therefore you're right we ought to pay attention to it, however understandable the problems are.

Again I agree with you.

Another obvious factor that makes open-source projects difficult to manage is that people are contributing voluntarily. Their livelihood doesn't depend on toeing the line, as it frequently does in paid employment. And they have access to the source code. So when personal styles clash, as I think was the case here, it's much easier for things like we've just seen with this project to happen.

I have personal experience with de Raadt (not good) and have used OpenBSD on and off for years. OpenBSD is absolutely a cult of personality, exactly as you said. But it takes a particular kind of personality to be willing to drink the de Raadt Kool-Aid. And recall that OpenBSD is a fork of NetBSD, the result of some particularly nasty circumstances.

So I think the right way forward is to learn what can be learned from this kerfuffle, but don't over-react to it. You certainly want to try to retain someone like Adam, talented and volatile, but sometimes it's just not possible. C'est la vie.

I should add that I no longer use OpenBSD and will not, because de Raadt, brilliant though he is, is a nasty piece of work and his followers have, in many cases, taken on some of his personality characteristics. This is an example of organizations tending to behave like their leaders. I refuse to subject myself to that kind of aberrant behavior. The software is good but not good enough to put up with that.

Walter sets a very different tone for this project and I value that. The man behaves like a gentleman. Of course he's imperfect, just like the rest of us. But he tries to improve upon the imperfections. de Raadt? His way or the highway and that will never change.

January 19

On Monday, 15 January 2024 at 09:46:11 UTC, Atila Neves wrote:

>

We hope that in time the contributors to OpenD will decide to lend
their time instead to the D language.

maybe dlang should embrace closedness [1] and actually encourage language forks

benefit

  • it will save everyone's time. dlang org spends energy making a great language for their customers, dlang staff don't spend time on N.G.
  • zero expectation. language contributors will know upfront they should spend time on their own thing.

con

  • community fragmentation - not an issue, those who quit are lost forever anyways.

[1]
https://lua.org/faq.html#1.8
https://lua.org/faq.html#1.9
http://lua-users.org/lists/lua-l/2008-06/msg00407.html

January 19
On 1/19/2024 7:46 AM, Don Allen wrote:
> Walter sets a very different tone for this project and I value that. The man behaves like a gentleman. Of course he's imperfect, just like the rest of us. But he tries to improve upon the imperfections. de Raadt? His way or the highway and that will never change.

I do agree that the tone of any organization flows down from the top, so it's up to me to lead by example.

The other thing I've tried to do, perhaps with more success, is to emulate the honor system used at Caltech when I attended it. I enjoyed it and appreciated it very much as a student. It's unique to Caltech (other universities have honor systems, but with "adjustments"), and it's what made Caltech into a top shelf institution.

In the years that followed, Caltech added more conditions and complexities to it, to its detriment. The original (from memory) was simple and straightforward:

"No member shall take unfair advantage of any other member."

It had far reaching consequences. For example, exams were unproctored, take-home, with time limits. Nobody would know if you cheated or not. It was entirely up to one's honor.

Of course, there were cases of cheating. But it was never organized cheating. The students liked the honor system, and would ostracize anyone who took advantage of it. This was why organized cheating never happened. Cheating was a shameful thing one did in a closet, not something one bragged about getting away with. Nor was theft an issue, people would leave their dorm rooms unlocked. The only thefts I heard of were from outsiders who wandered into the dorm.

The other interesting result of that is the professors and students became collaborators rather than adversaries.

I've never made any explicit mention of this with the DLF, but it's the way we operate. To my great satisfaction, the DLF members adhere to it. It's really marvelous.

For example, at our DLF conferences, nobody worries about leaving their possessions laying around.

But we did have an incident at the last DLF where a couple laptops were stolen. Unsurprising to me, the culprit turned out to be a person who wandered in off the street, not one of our attendees. Our response for the next DConf is to hire a security person to gate keep at the door.
January 20
On 20/01/2024 6:48 AM, Walter Bright wrote:
> I do agree that the tone of any organization flows down from the top, so it's up to me to lead by example.

I mentioned about this to Atila in another post.

But I am hoping that he will continue to drop in on Discord to check for pings on a regular basis moving forward.

Ideally you too.

Why? Your email has been down for a while and I'm currently waiting on you to reply to a ping on GH.

Having leaders where the people are shows that you care, and want to be needed in that way.

As Mike said, the us vs them mentality has to go, and this could help to do it.

There are other things but I'll let Adam Wilson talk about it.
January 19
I get a constant stream of requests for attention. There's only so much I can respond to. Adding another source will likely just make me less productive.
January 20
On 20/01/2024 7:52 AM, Walter Bright wrote:
> I get a constant stream of requests for attention. There's only so much I can respond to. Adding another source will likely just make me less productive.

I can certainly understand that.

But all of these giant drama threads are already doing that, not to mention the loss of productivity of others.

That's the problem with leadership, you have to delegate, you can't do everything yourself.
January 19
On Friday, 19 January 2024 at 18:56:52 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 20/01/2024 7:52 AM, Walter Bright wrote:
>> I get a constant stream of requests for attention. There's only so much I can respond to. Adding another source will likely just make me less productive.
>
> I can certainly understand that.
>
> But all of these giant drama threads are already doing that, not to mention the loss of productivity of others.
>
> That's the problem with leadership, you have to delegate, you can't do everything yourself.

i thought this was the definition of open source software, you can do things without needing a leader. Can't community discuss about things without leader, if leader declines it (which is unlikely if most of the people actually want it), then you can always fork.
January 20
On 20/01/2024 8:39 AM, Hors wrote:
> On Friday, 19 January 2024 at 18:56:52 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> On 20/01/2024 7:52 AM, Walter Bright wrote:
>>> I get a constant stream of requests for attention. There's only so much I can respond to. Adding another source will likely just make me less productive.
>>
>> I can certainly understand that.
>>
>> But all of these giant drama threads are already doing that, not to mention the loss of productivity of others.
>>
>> That's the problem with leadership, you have to delegate, you can't do everything yourself.
> 
> i thought this was the definition of open source software, you can do things without needing a leader. Can't community discuss about things without leader, if leader declines it (which is unlikely if most of the people actually want it), then you can always fork.

Yes, but you have missed the very important point. He hasn't got the time to see something to decline it.

It is the old worker vs leader conflict. People don't have the time to perform both roles at full capability. Trying to keep both at full result in doing neither well. Not a good thing.

January 19
On Fri, Jan 20, 2024 at 07:39:07PM +0000, Hors via Digitalmars-d wrote: [...]
> i thought this was the definition of open source software, you can do things without needing a leader. Can't community discuss about things without leader, if leader declines it (which is unlikely if most of the people actually want it), then you can always fork.

Don't confuse the *license* of the software (license gives you the right to access and modify the source code) with the *development methodology* of the software (community decides what features to implement vs. leader makes final decision vs. anything in-between).

D has always been closer to the closed development model where Walter has final say over what goes in and what doesn't. Not quite as closed as Lua (devs don't even grant access to the code repo, you only get the code snapshot at release time, they may or may not listen to community feedback and are not obligated to explain why), but still pretty near the closed end of the spectrum than your average open source project where the community's voice plays a bigger role.

However, in spite of what the open source / open development model propagandists may say, it remains an open question which end of the spectrum (or whether the exact middle) is more effective.  Having a BDFL can help move things along when the community is split over some controversial decision, and he can also ensure the big picture is not lost in the forest of immediate decisions. OTOH having everything go through one person has serious bottleneck issues and adversity issues (when the community at large disagrees with the leader's decision). There are pros and cons whichever way you take.  I have my opinion on where on the spectrum things are more ideal, but it's not possible to know for sure without actually doing it.  It's not an easy issue.


T

-- 
Notwithstanding the eloquent discontent that you have just respectfully expressed at length against my verbal capabilities, I am afraid that I must unfortunately bring it to your attention that I am, in fact, NOT verbose.
January 19
On 1/19/2024 10:56 AM, Richard (Rikki) Andrew Cattermole wrote:
> That's the problem with leadership, you have to delegate, you can't do everything yourself.

Then I delegate anyone who uses Discord and thinks an issue there needs to be raised in the n.g., to please do so.

And, as always, bug reports go on bugzilla. It's only fair to give priority to bug reports where the bug reporter made an effort to post them there.

Bug reports of the form "the latest release broke my code!" with no further elucidation are completely and utterly useless. There is nothing I nor anyone else can do about them.