A particular interesting case where this comes up is setting up a governance from scratch.
All code bases start out zero lines long, and someone has to start writing them. If the code base is not already being originated within the context of some kind of cooperating organisation with an existing governance, then it probably starts off as one person's project, and grows more developers later on as people notice it, like it, and join in.
So, at least to start with, it will have the default governance structure of a dictatorship. The project originator may give other people commit access, but can remove it again by virtue of being physically in charge of the git repo. So in case of any disagreement over what ought to be done with that access, the originator de facto has the final say: I can always revoke your commit rights and then revert your objectionable changes. Probably I would do that in a sufficiently deserving case (say, if one of my long-trusted committers turned out to have perpetrated something like the libxz backdoor). The only thing that stops me doing it capriciously, if one of my committers does something I only mildly disagree with, is my desire to keep some goodwill and not have all my co-developers leave in disgust.
(IME "benevolent dictators" in charge of software projects are more likely to be actually benevolent than the ones in charge of countries, although still not 100%. But then I would say that, wouldn't I :-)
Once a code base is in that governance situation, who persuades the dictator to let go of the reins and hand over ultimate control to the Foo Foundation or the Foo Steering Committee or whatever?
Ultimately, this involves persuading the dictator not to have full control over the project any more. Even if you have a transitional phase in which they're still the chairbeing of the committee and retain most of the decision-making power (maybe unless outvoted by a sufficiently huge margin), you're still telling them to sign up for a situation which can lead to them being voted out of their own project.
This surely isn't likely to seem attractive to them. In political terms, they won't want to give up power, or have their autonomy threatened. Inside their own head, they're going to see it in terms of "But what if the new governance makes some terrible decision? If I keep control I can make sure that doesn't happen." Assuming the software matters to the developer – and surely it must, in any case where there are also enough people around to try to form a governance structure – they're going to think of that as a very real risk that they care about.
I suppose the easy case is if the originating developer is tired of the project and wants to hand it on to a new maintainer anyway. Then it's as easy to hand it on to a governance structure as to hand it on to a new single individual. (Perhaps even easier, if the governance structure has enough transparency that it looks easy to tell if it's trustworthy?)
Perhaps this is the one case where forking is a reasonable solution? Even with a program small enough for one person to maintain, a big problem with forking is persuading people to switch to a new fork with no reputation or track record, despite the existing maintainer being generally known and trusted. But if the would-be Foo Foundation is better funded than one programmer maintaining Foo at weekends, then perhaps it would have the resources to make a fork and do lots of actually useful work on it, establishing the track record it needs for Forked Foo to become known as a better option than Classic Foo.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
(no subject)
Date: 2025-05-02 07:23 am (UTC)A particular interesting case where this comes up is setting up a governance from scratch.
All code bases start out zero lines long, and someone has to start writing them. If the code base is not already being originated within the context of some kind of cooperating organisation with an existing governance, then it probably starts off as one person's project, and grows more developers later on as people notice it, like it, and join in.
So, at least to start with, it will have the default governance structure of a dictatorship. The project originator may give other people commit access, but can remove it again by virtue of being physically in charge of the git repo. So in case of any disagreement over what ought to be done with that access, the originator de facto has the final say: I can always revoke your commit rights and then revert your objectionable changes. Probably I would do that in a sufficiently deserving case (say, if one of my long-trusted committers turned out to have perpetrated something like the libxz backdoor). The only thing that stops me doing it capriciously, if one of my committers does something I only mildly disagree with, is my desire to keep some goodwill and not have all my co-developers leave in disgust.
(IME "benevolent dictators" in charge of software projects are more likely to be actually benevolent than the ones in charge of countries, although still not 100%. But then I would say that, wouldn't I :-)
Once a code base is in that governance situation, who persuades the dictator to let go of the reins and hand over ultimate control to the Foo Foundation or the Foo Steering Committee or whatever?
Ultimately, this involves persuading the dictator not to have full control over the project any more. Even if you have a transitional phase in which they're still the chairbeing of the committee and retain most of the decision-making power (maybe unless outvoted by a sufficiently huge margin), you're still telling them to sign up for a situation which can lead to them being voted out of their own project.
This surely isn't likely to seem attractive to them. In political terms, they won't want to give up power, or have their autonomy threatened. Inside their own head, they're going to see it in terms of "But what if the new governance makes some terrible decision? If I keep control I can make sure that doesn't happen." Assuming the software matters to the developer – and surely it must, in any case where there are also enough people around to try to form a governance structure – they're going to think of that as a very real risk that they care about.
I suppose the easy case is if the originating developer is tired of the project and wants to hand it on to a new maintainer anyway. Then it's as easy to hand it on to a governance structure as to hand it on to a new single individual. (Perhaps even easier, if the governance structure has enough transparency that it looks easy to tell if it's trustworthy?)
Perhaps this is the one case where forking is a reasonable solution? Even with a program small enough for one person to maintain, a big problem with forking is persuading people to switch to a new fork with no reputation or track record, despite the existing maintainer being generally known and trusted. But if the would-be Foo Foundation is better funded than one programmer maintaining Foo at weekends, then perhaps it would have the resources to make a fork and do lots of actually useful work on it, establishing the track record it needs for Forked Foo to become known as a better option than Classic Foo.