On 12/12/2018 11:14, Rick Moen wrote:
> A key part of the basis of Eric's argument is irritatingly and obviously
> untrue:
>

>    If you want to have more devs, you need to attract a larger userbase.

>
> I'm surprised to see Eric advance this non-sequitur.

I don't think it's a non sequitur, but I do think it's true as much as
your points are true. I agree with both, and don't find them incompatible.

Good, loyal developers are people who use your project and need more
from it. Attracting more users doesn't /necessarily/ attract
developers, but it's still a /prerequisite/ to attracting developers.
It increases the likelihood that out of the total userbase, some
fraction of that userbase will have the desire to contribute something
to the project, and it also increases the /value/ of contributions if
they are widely used.

There are several reasons why this doesn't always hold true. Some
projects are hostile to outside contributions. Others are so complex
that there's a technical barrier to effective contributions. Others
have cliques which don't welcome outsiders, or baroque submission
processes which sap the will of any potential contributor. Or they lack
the infrastructure and manpower to handle contributions effectively. So
in all these cases, increasing the number of users doesn't help much.
But this is a self-inflicted failure.

But if a project is open to new contributors, welcomes and reviews
patches in a timely manner, there's a positive reinforcement where new
users are empowered and encouraged to do just this, and this both
increases the number of users and developers at the same time.

GNOME is an example of the former. I've had good quality, tested
patches sit in its bugzilla for over a decade without review before they
were summarily closed. This is a project which did not value
contributions from outsiders. In the case of libgnomecanvas, they
wasted the time of multiple developers writing at least six slightly
different forks rather than review and apply contributed fixes to the
canonical implementation to make it usable, featureful and performant.
All of these forks, plus the original, are now basically dead with no
users. They did not foster contributions and this led directly to a
decline in both contributions and use of the libraries. It was issues
like this that killed the prospects of GNOME for commercial software
development in the mid 2000s, because we couldn't rely on it when issues
couldn't be resolved in an effective and timely manner.

CMake is an example of the latter. Turnaround time between submission
and review is usually under 24 hours. It's been as little as 20
minutes. After addressing reviewer's comments and waiting for CI
testing to complete, typical time between submission and merging for me
has been between 24-36 hours depending upon the complexity, and for
simple fixes has been as little as 60 minutes. This is a project which
values code contribution from third parties, helps familiarise new
developers with the project's codebase and policies, and this both
encourages repeat contributions as well as grows the user base and
developer base due to the utility of all this extra work going in over
time. As a developer, it means I get bugfixes and new features into my
users' hands immediately from git, or by the next routine point release.

I and many other Debian developers got started because we needed new
software packaging, or existing packages fixing or updating, and we got
stuck in. For myself, I started by packaging my own upstream software
releases for projects I belonged to, and went on from there to do much
much more. We were users who became developers over time. While the
new maintainer process is somewhat lengthy, more users means more people
who find unmet needs that becoming a developer can fulfill. I started
the process because other DDs were getting fed up of reviewing and
uploading my work, and strongly encouraged it. I do believe the same
underlying needs and motivations hold true for Devuan or any other
distribution.

I don't think Eric's points about ease of installation should be quite
so trivially dismissed. It's not like these points haven't been raised
and discussed at length by the debian-installer team for many years.
Any barrier which prevents a user doing an installation and getting a
working system will result in lost users who can't get over that hurdle.
From difficulties finding the correct image, to making the bootable
installation medium, to successfully completing the installation
process. They all matter.

This doesn't mean that you have to dumb things down to the lowest common
denominator. But it does mean that you have to look at what is
unnecessary complexity vs necessary complexity, and try to minimise the
former. Reducing the number of installer images is beneficial so long
as you don't sacrifice hardware support, as is having the most up to
date kernel practically possible for better hardware support. This is
also the same argument I used when suggesting that an initrd should be
the only supported means for booting; the developer cost of the esoteric
stuff has such poor cost/benefit it's simply too much. The same applies
to all the different installation methods. Looking at
https://mirror.netzspielplatz.de/devuan/devuan_ascii_rc/installer-iso/
for example. Do the separate CD and DVD images have much value given
that they only hold the tiniest fraction of the whole archive? Or is
just one netinst or dvd image sufficient for all needs (perhaps combined
with a local mirror or caching proxy server if you are doing multiple
installations)? Could the live images be further combined with the
install images like Ubuntu does? If you look at
http://releases.ubuntu.com/18.04.1/ and
http://releases.ubuntu.com/18.04.1/ you can see that there's just one
server and desktop iso image per platform per release. It's pretty
simple when there's a single obvious choice to make, and they clearly
thought how to reduce the complexity as much as possible. (Note: none
of this is a criticism of the Devuan ascii images; the collection is
quite impressive.)


Regards,
Roger