Maintainerless Debian?

Posted Dec 7, 2016 12:18 UTC (Wed) by itvirta (guest, #49997)
In reply to: Maintainerless Debian? by matthias
Parent article: Maintainerless Debian?

>> group ownership requires more people
>Sounds logical, but is this really true.

I think you mean _isn't_. But adding people by necessity adds communication overhead
within the group (which for a single maintainer is zero), and therefore requires more work.

Maintainerless Debian?

Posted Dec 7, 2016 13:14 UTC (Wed) by mfuzzey (subscriber, #57966) [Link] (3 responses)

The communication overhead probably depends on the type of work being carried out.

For software undergoing heavy development then yes the communication overhead to keep people stepping on each others toes and moving in the same direction with a shared vision could be significant.

But if the software is mostly in maintenance mode the overhead could be very low since, at any given time, there may well only be one maintainer actually working on it.
For example a "timeslot" system could allow N maintainers to work on the same package with little to no synchronization overhead (developer 1 works on the first week of the month, developer 2 on the second etc). Not saying this is necessarily the best way to do it but it does allow the bus factor to be increased for little communication cost.

And we are talking about packaging here rather than full blown upstream development work which probably makes things easier (packagers try to change as little as possible of the upstream sources, consistent with the distribution policies).

Maintainerless Debian?

Posted Dec 7, 2016 13:51 UTC (Wed) by anselm (subscriber, #2796) [Link] (2 responses)

Also consider that there are more than a thousand people working on Debian. In the days of SUSE Linux and Red Hat Linux as commercial end-user packages, these companies managed to maintain fairly large distributions with teams that were at least 1–1.5 orders of magnitude smaller.

Maintainerless Debian?

Posted Dec 8, 2016 3:56 UTC (Thu) by rahvin (guest, #16953) [Link] (1 responses)

Your comparison is disingenuous IMO. Debian's distribution has significant more software than those commercial distributions and because it's mostly volunteer it's part time work. Even still if you actually did a fair comparison where you only included the Debian contributors that worked on the same packages provided by the RedHat commercial distribution you would find Debian is doing pretty darn good given the volunteer nature.

It's simply not fair to compare a distribution with (made up numbers) 2000 packages against a distribution with 500 and then claim the 500 package distribution is so much more efficient. AFAIK RedHats previous commercial end-user packages never included anywhere close to the depth of the Debian repositories. Even today on RHEL I doubt the official RPM's are even 25% of whats in Debian. The only fair comparison would be to pin down contributors on a completely equal package basis.

Maintainerless Debian?

Posted Dec 8, 2016 13:16 UTC (Thu) by anselm (subscriber, #2796) [Link]

Nobody says that Debian is inefficient – it's just organised differently. If instead of volunteers maintaining a small handful of packages each in their spare time you have full-time paid staff who do nothing else but maintain packages, you can get by with a smaller workforce. And that probably involves a greater degree of co-maintainership from the get-go.

(Also, comparing the numbers of packages between Debian and Red Hat/SUSE doesn't make a great deal of sense because these distributions tend to split upstream packages up differently. Also, back in the days of commercial SUSE Linux, Debian was considerably smaller than it is now, and consequently the two were probably much closer in size and scope than they are today.)

Maintainerless Debian?

Posted Dec 8, 2016 3:48 UTC (Thu) by rahvin (guest, #16953) [Link] (1 responses)

All project managers should know that adding bodies to projects isn't a zero sum game where 1person produces X while 2 people produce 2X. The reality in the world is that as you add people to projects the people involved get less and less efficient.

There is an ideal staffing level and once you pass that point every person added will start significantly lowering the productivity of the group. Things like doing tasks out of order because you need to get someone working, this often create rework. As mentioned you add to your communication overhead which in a rotten situation with too many bodies can consume more time than the actual task. The increased communication load also will start causing mistakes on it's own because person X didn't see change Y.

There are a bunch of other things that happen, the list is quite long so I'm not going to list them all but needless to say adding bodies creates problems all on it's own, even with ideal staffing for the task the more bodies the task requires the more management and overhead time there will be.

I personally don't think group ownership could succeed in a volunteer FOSS project unless it was a very small, very tight group where there is strong respect and near equal skill levels among the members. IMO FOSS, particularly volunteer FOSS succeeds better under the benevolent dictator model. The trick is finding the dictator.

Maintainerless Debian?

Posted Dec 9, 2016 5:51 UTC (Fri) by JanC_ (guest, #34940) [Link]

Of course there will be some communication overhead, but that often was already necessary because usually packages maintained by a group are used together, or depend on each other, or are otherwise related.