Follow

In my experience, existing contributors who are comfortable in their workflow is a known value, and thereotical new contributors who might be more comfortable in a different workflow is an unknown value. I would sooner cater to the former group, who have already demonstrated a history of consistent contributions under an existing workflow.

This is why sway and wlroots are still on GitHub, despite the fact that, you know, I am the CEO of a competing service. I am in a position to force these projects to move to sr.ht, but it would be disruptive, risk alienating established contributors, and likely be a net negative for the project.

@sir

> In my experience, existing contributors who are comfortable in their workflow is a known value, and theoretical new contributors who might be more comfortable in a different workflow is an unknown value. I would sooner cater to the former group

Decisions like this are really tough, imo. For example, consider this argument:

> Surveys of Rust users show that the language isn't too complicated, proving that it's not too complicated

Well, that *or* all the people who care were put off

@sir

My point (obviously) isn't that Rust is/isn't too complicated, it's that opinions of *existing users* don't provide much info – we have to have the argument from first principles.

I'd say the same for forges. Changing forges may or may not increase the pace of development by bringing in more/more active contributors than they drive away, and the opinions of existing users don't provide much evidence either way.

@codesections I'm not saying that change is bad - but if you're forcing a change which *alienates* your existing contributors, you should reconsider. This is basically always true.

@codesections maybe you need to invest more in convincing your contributors, or addressing the problems they bring up, or need to rethink your approach entirely, but forcing it in is going to cause more grief than success.

@sir

> if you're forcing a change which *alienates* your existing contributors, you should reconsider. This is basically always true.

Meh, I'd downgrade "always" to "often".

Sometimes, communities die a slow death, with gradual attrition/aging out over time. Ideally, you solve that problem without pissing off a big chunk of existing contributors, but that doesn't always work. And, if that's not an option, a change that alienates existing contributors is *sometimes* the right move, imo

@codesections I'm just going to go ahead and register strong disagreement here. This attitude kills projects much faster than attrition.

@sir

> I'm just going to go ahead and register strong disagreement here. This attitude kills projects much faster than attrition.

I absolutely agree that it often kills them faster.

It *sometimes* saves them from a slow death. It turns a slow decline into a sudden crises, which is going to be resolved quickly (either way).

Depending on the situation, that *might* be worth it. (Though it's *very* easy for leadership to talk themselves into thinking it is when it isn't)

@codesections it's also worth remembering that software does not always *need* to have a lot of change. One person's "slow death" is another person's "long tail of bugfixes". Change is not always good.

@codesections I think what can often happen is that those pushing for change get frustrated with the pushback from others. It ends up being a lot more work than they expected to make the change palatable to more people. They're in a position to make the change happen, so they rationalize away the protests and force things through.

@sir

> I think what can often happen is that those pushing for change get frustrated [and just] force things through.

Yeah, I agree that often happens.

(I haven't followed this story, but from the article you linked it sounds like RedHat just decided not to pay for Pagure development. That sucks, but also means "sticking with the status quo" wasn't really an option – other than by the community taking on a lot of new dev work. Not sure if/how that changes things, though)

@codesections oh, I meant to include this link as well:

lwn.net/SubscriberLink/817668/

For a similar problem Debian is working with.

community management 

Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!