Hi Ted, I disagree with your application of some points to the Debian Project. I agree with others.
(Why is this in -devel and not -project?)
At 2025-02-08T23:09:55-0500, Theodore Ts'o wrote:
> So for example, if you serve on the board of a church, or a non-profit
> orgaization like Usenix, or the Rocky Enterrise Software Foundation
> (RESF), if there is a motion where you might benefit depending on how
> the decision comes out, the CoI policy will mandate that you abstain
> from voting on the motion. This is where the "refrain from
> participating from a decision" language might come from.
When I served on the SPI board, I had a personal rule (one that I did
not expect or demand of others), that I would abstain from voting on my
own motions. This worked out fine. I don't recall a motion of mine
ever stalling out in a tie due to my habit, nor one that would have tied
if only I had voted. I thought the practice to be a worthwhile shield
against even the notion of self-dealing. People can of course levy such
charges on no grounds whatsoever, but it seemed a helpful bulwark and
was easily done. Tied or near-tied votes can inflame the passions
within boards and memberships alike. I wanted to stay away from that,
and I recall SPI board meetings as invariably highly collegial.
> Howeer, it is quite common that someone with that potental conflict of
> interest is often a subject matter expert. For example, if you are a
> primary owner of a general contracting company, then you will know a
> lot about building construction; so if the vote is about which company
> should be hired, the board would *want* to hear your insights. So
> typically the conflict of interest would be disclosed, the expert
> would give their opinions, insights, and other expertise to the board
> --- and then the expert might abstain from voting on the actual motion
> if they were a board member.
Seems like sound practice to me.
> The problem is that in Debian, we rarely vote when we make decisions.
> This does happen, of course, such as when the Technical Committee
> votes on something that might be a very close call. In that case, it
> would make sense for a TC member who might have conflict of interest
> to step aside.
It's odd to me that you didn't mention the GR process (except by
reference to DPL elections). I think it is significant because of how
distinguishable it is. I may be on the stern and searching side of
disclosures and conflict-of-interest recusals, but I would not expect a
Debian developer to lose their franchise in the GR process for _any_
reason short of expulsion. That's because it _is_ the franchise. Our
constitution commits us to a democratic form of government.
You and I are both U.S. people, so we know well, though others may not--
the United States has a sorry history of stripping its citizens and
residents of the franchise (or never extending it to them in the first
place). Frequently this practice occurs on a racialist basis, to
prevent African-Americans from exercising their voting rights. Because
overt racialism was unfashionable for a while, numerous proxies for
black skin arose, like felon status. The ACLU has a useful primer.[1]
I think Debian has striven to avoid that sorry example, and largely
succeeded. (More precisely, I don't think our constitution's primary
drafter, Ian Jackson, nor its charter ratifiers, had any desire to
emulate the more wretched codicils of the U.S. Constitution's own
letter, which was racialist not through carelessness or latent biases
but explicit design. Beyond the standard reference--the _Federalist
Papers_--Thomas Jefferson's _Notes on the State of Virginia_ (1785) is
instructive in this respect.)
> However, many decisions take place via discussion / debates on public
> mailing list --- so what does refrain from participating in a decision
> mean in that context? That the people who might have the most
> expertise must not participate in the debate? That
> seems.... counterproductive. So there, probably the best you could do
> is to make sure people should be asked to disclose conflicts of
> interest up front, although in many cases, it might be obvious (for
> example if the e-mail address has canonical.com....).
Yes, I think they should disclose--both their potential/actual CoI and
their expertise. If they behave more professionally and compose more
factual, better-reasoned, and more completely supported and documented
cases for action (or inaction) because they feel the weight of their
employment affiliation upon them more acutely in that context--how is
that bad?
I'm trying to imagine the internal narrative of a person disincentivized
as you posit.
"Jeez, if I weigh in on this I'm going to have to produce really
high-quality output. Yeesh. You know what? Screw it. These guys can
muddle through without my insight."
It's noteworthy to me that the richer a person's compensation package in
our field, the more prone they are to resentment.
> Another such situation is if a maintainer makes a decision as it
> relates to a package where they are the primary maintainer.
[...big snip...]
> Ultimately, this is a case where I think we do have recourse already,
> which is if a package maintainer makes a decision which is detrimenta
> to Debian, that decision can always be appealed to they TC.
Two caveats here:
1. The value and desirability of the package maintainer model has come
under deep reconsideration in recent months (or even years). In
some circles, individual package maintainership (in a 1:n mapping)
is considered a petty tyranny; "true collaboration" can only be
achieved, it is claimed, through something akin to a major
Gitlab-mediated reform placing all packages under collective
maintainership, akin to the *BSDs' (or XFree86's) historical CVS
"commit bit", but with a "core team" rescoped to the entirety of the
Debian developer+DM population.
These two scenarios are extreme points on a continuum, and people
reasonably occupy various positions in between--I suspect because,
having acquired specialized expertise in some area, they're aware of
the hazards of ignorance in that domain. If anything, the diversity
of perspectives and potentially elaborate future status quo makes
the interaction of CoI considerations with package--let's say
"responsibility" rather than "maintainership"--potentially more
complex, not less.
2. The Technical Committee has repeatedly stated a policy of, and
manifested a refusal to deliberate upon, decisions that it
collectively regards as non-technical. Now, I won't say that they
have never deviated from this practice, particularly when beseeched
by the rest of the collective membership for help reasoning
carefully through an especially thorny problem, but that it is the
ever the case obviates your claim that a decision "can always be
appealed to the TC".
Unless, that is, you perceive only "technical" decisions as having
any capacity to work to the detriment of the project. But if I had
to bet, I'd wager against that being your opinion. (In any case, as
I recall, the TC can decline to hear even an issue universally
categorized as technical.)
> So I could imagine COI policies for specific, small bodies in Debian
> where decisions get made via voting, such as the TC.
I think a policy should certainly apply there.
> However, I don't believe it makes sense for large bodies; for example,
> excluiding people from voting on a GR just because they might have a
> conflict of interest means that we could potentially depriving people
> of their franchise, which I think would be a Bad Thing. So if someone
> adopted this as a constitutional amendment, I would vote against it.
I agree, and I would vote the same way. GR participation is for all
developers, full stop. If we collectively feel that someone is unfit to
exercise that franchise, our duty is to expel them, not contrive
extra-constitutional measures to punish or restrain them in partial
measures.
But there are more than two alternatives open to us. The best
substitute for a bad CoI policy is a good CoI policy, not no CoI policy
at all.
There _is_ a hazard in ruling out GR franchise from the domain of a CoI
policy; it is conceivable that a single employer could retain so many
Debian Developers on staff that it can exercise outsized and
undemocratic influence on the project's decision making processes.[3]
> The final thing I would note is that our structure means that in some
> cases, the ultimate authority rest with the DPL.
Relatively few, as it turns out. Wikipedia's article on the Debian
Project has a useful diagram summarizing our power dynamics; I think it
originates in a similar one in Martin F. Krafft's (excellent) book.
https://en.wikipedia.org/wiki/Debian#Organization
> So I'm not sure we *can* have a COI policy that applies to the DPL
> without it making a fundamental change to our governance structure.
> The wise DPL would delegate their authority if there wasa clear
> conflict of interest, of course.
>
> And if a DPL abuses their authority, then they can be voted out at the
> next election.
This bit of fatalism is reminiscent of Federalist Society jurisprudence
regarding the powers of the U.S. President, which is now binding
precedent under Trump v. United States (2024).[2]
There is of course another mechanism available to the developers, and
that is the recall of the DPL by General Resolution.
This is not a theoretical notion.
https://www.debian.org/vote/2006/vote_005
> But saying that the DPL "must not participate in a decision", per the
> ChatGPT authored statement, I would argue does't work given what trust
> and power we vest in the DPL.
I think delegation is an entirely appropriate mechanism for achieving
non-involvement given the parameters our constitution puts on
delegation. See §8.2:
"The Delegates are appointed by the Project Leader and may be replaced
by the Leader at the Leader's discretion. The Project Leader may not
make the position as a Delegate conditional on particular decisions by
the Delegate, nor may they override a decision made by a Delegate once
made."
The latter sentence is the salient one here.
Regards,
Branden
[1]
https://www.aclu.org/news/voting-rights/racist-roots-denying-incarcerated-people-their-right-vote
The culture of policing in the United States has developed
concomitant traits. To preserve the racist "balance" (imbalance) of
political representation, police are incentivized to harass black
folks more frequently and more harshly than whites. Through a
variety of mechanisms this leads to more felony charges and
convictions, and consequently more disfranchised black folks.
Here's the incentive structure in action.
https://en.wikipedia.org/wiki/1999_Tulia_drug_arrests
Consequently, when police know that light is being thrown on the
early stages of citizens' and residents' encounters with police,
their levels of impartiality and professionalism, and sense of
proportion, veritably skyrocket. (Though I'd experience no surprise
if they were to measure at gutter levels in an absolute sense.)
https://gritsforbreakfast.blogspot.com/2024/04/most-contraband-found-at-texas-traffic.html
[2]
https://www.scotusblog.com/2024/07/justices-rule-trump-has-some-immunity-from-prosecution/
[3] Personal recollection:
I remember this being stated as a concern (very informally [as in,
on IRC]) when Ian Murdock co-founded Progeny Linux Systems (and
hired me and...I think only one other DD initially). That rumble
got much louder when Canonical Software appeared on the scene and
proved to possess a more capacious payroll budget, coupled with a
highly respectable recruitment policy that drew disproportionately
from the U.K., rather than filling the ranks with uncouth Americans.
The project's collective discomfiture was not alleviated in any way
by Mark Shuttleworth's initial community liaising strategy of high
visibility and frequent self-congratulation for his billionaire
status, which caused Ian Murdock substantial anguish. (If we had
ever been curious what Eric Raymond would look like with real wealth
rather than vaporous VA stock,[4] we found out.)
[4] https://www.zdnet.com/article/eric-raymond-how-ill-spend-my-millions/
signature.asc
Description: PGP signature
