4 ms·

I'm a Debian developer. It can look a little chaotic from outside. But there are a few simple principles operating here. Mostly they follow from the Debian b

I'm a Debian developer. It can look a little chaotic from outside. But there are a few simple principles operating here. Mostly they follow from the Debian being a collection of 1000 developers, all equal. There is no CEO who can decide what's important and force someone to do something. Instead, Debian is a do'ocracy. If there is a dispute, it always takes the form of two Debian developers wanting to do something different. (This means users don't get a say. Not because Debian doesn't care, but because it's a do'ocracy and users can't do anything without going through the lengthy test and evaluation process that Debian insists all it's developers must go through.) Asking for help, then not taking up an offer breaks this first rule. We don't have two Debian developers doing conflicting things, so there is no conflict. It may not be the nicest way to behave, but shrug no one can force someone to do something like supervise a newbie. After all Debian developers are unpaid volunteers, and you can't force an unpaid volunteer to do something. Lets take it further. Lets say we have two Debian developers proposing to do different things. Lets say a Debian developer wants to upload a new version of libreoffice. A second rule comes into play here: the package maintainer is king of his packages. He can resist just about anything providing he isn't breaking any policies. So providing the libreoffice package is in reasonably good condition - not too old, all CVE's fixed, yada yada he can resist the new version. In fact I've resisted people wanting to update my package to a beta release, so I've don't just that. Now lets say Debian packager of libreoffice has let it languish, in fact languished so much it's accumulating CVE's. And worse, in order to resist he must be actively deleting the new version. So we have two people doing different things, and they conflict. At this point either developer can invoke Debian's dispute resolution mechanisms. Interestingly the team doing the dispute resolution isn't allowed to do something themselves, they can only chose which (or perhaps neither) of the things done can proceed. In this case not updating a package accumulating CVE's breaks policy, so they would probably allow the developer uploading the new version to proceed. This is a very different way of going about getting work done then people normally experience in their working life. A work environment is typically far more hierarchical and authoritarian. A boss can actually order someone to accept help for example :). However, Debian's system is demonstratedly every bit good as RedHat's. Security patches come out just a quickly, and it has far more packages. And clearly as there are 1000 of us developers all pulling together, it can't be too hard a system to work in.

gautamcgoel 6y ago
I understood the second rule, but could you please explain the first rule more clearly? This idea of a do-ocracy is very interesting to me.
- rstuart4133 6y ago
  I imagine you are asking why the grand architect included the second rule, as what it does seems clear enough. The honest answer is I don't know. No one has explained it to me, and I wasn't there when it was born. But Debian being what it is, I'd be surprised there if there was a grand architect, or that it's possible to point to a definite moment in time it became a thing. The formality Debian has acquired over the years looks to be to attempts at codify existing practice after it was challenged. Codifying works to prevent reoccurrences of the unpleasantness associated with such challenges. The practice has always been someone volunteers to maintain a package, they expected nothing but the freedom to do the job in the way they saw fit without fear of interference providing they followed policy, and no reward except the bouquets and bricbats for how it turned out. When put that way it's not much of a reward, but it's been enough to attract a lot of us to the task. The importance of that reward can best be seen by looking at what selfish motivation is left if you took it away. Good deeds are great and all, but when done where nobody can see them or others can easily take over after you've put all the hard work in or worse can claim credit for it, such hidden deeds are not great motivation for sticking at it for years. We are all very aware that binds us and we are protective of it. But human nature being what it is, it can't be surprising the second rule has been challenged on many occasions, which has lead to it being codified in so many ways it's become part of Debian's DNA.

gautamcgoel 6y ago

I understood the second rule, but could you please explain the first rule more clearly? This idea of a do-ocracy is very interesting to me.

rstuart4133 6y ago
I imagine you are asking why the grand architect included the second rule, as what it does seems clear enough. The honest answer is I don't know. No one has explained it to me, and I wasn't there when it was born. But Debian being what it is, I'd be surprised there if there was a grand architect, or that it's possible to point to a definite moment in time it became a thing. The formality Debian has acquired over the years looks to be to attempts at codify existing practice after it was challenged. Codifying works to prevent reoccurrences of the unpleasantness associated with such challenges. The practice has always been someone volunteers to maintain a package, they expected nothing but the freedom to do the job in the way they saw fit without fear of interference providing they followed policy, and no reward except the bouquets and bricbats for how it turned out. When put that way it's not much of a reward, but it's been enough to attract a lot of us to the task. The importance of that reward can best be seen by looking at what selfish motivation is left if you took it away. Good deeds are great and all, but when done where nobody can see them or others can easily take over after you've put all the hard work in or worse can claim credit for it, such hidden deeds are not great motivation for sticking at it for years. We are all very aware that binds us and we are protective of it. But human nature being what it is, it can't be surprising the second rule has been challenged on many occasions, which has lead to it being codified in so many ways it's become part of Debian's DNA.