Re: Opining on "modern" development practices (was Re: Merging the “binary” NPM importer?)

["Ludovic Courtès" <ludo@gnu.org>]

Hi Katherine,

Katherine Cox-Buday <cox.katherine.e@gmail.com> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> It’s an unusual situation, but it seems that “modern” development
>> practices make it hard or impossible to meet our standards in the first
>> place; yet, we’re missing out on a whole range of free software packages
>> by not doing anything.  Offering the tool while not compromising on our
>> standards seems like a reasonable middle ground.
>
> I think this is yet another example of the "worse is better"[1] debate, seemingly still ongoing in the world, thirty years later.
>
> I don't have much practical to say on the subject, but a few things have often occurred to me which someone may find useful or interesting to ruminate on:
>
> 1. The premise of the "worse is better" philosophy seems to me to have been
>    proven true. Development tools and environments which are easier to get,
>    start using, and distribute, proliferate. And these communities produce the
>    most software. As you pointed out, some of the software itself is free and
>    useful.
>
> 2. Sometimes these ecosystems (e.g. Javascript) are so volatile, bad things fall
>    out. It is difficult to stay abreast of changes, there are security issues
>    (e.g. tainting a very common dependency, bootstrapping issues, etc),
>    maintenance issues, and lots of wasted effort rewriting things. Still, a
>    large percentage of developers' time and energy goes into that ecosystem
>    because of point one, and they create useful things.
>
> 3. Sometimes these ecosystems are so volatile, good things fall out. Through the
>    lens of experience, solutions and tools are created which address the hard
>    won lessons.
>
> 4. This seems to be how nature and evolution work.
>
> Me? I like well-ordered things that have been thoughtfully produced. But I think about number four a lot.

I do too.  :-)

My early free software experience was that of a project managed in
typical MIT style: the Hurd; I learned a lot from that.

In Guix, I think we’ve always tried from Day 1 to do the Right Thing,
but also from Day 1, we’ve always tried not to go too far and to “cut
corners” when doing the Right Thing would have jeopardized practicality.

The package simplification work that landed this summer in
‘core-updates’ is an example of a case where the Right Thing was delayed
for several years because it just wasn’t attainable in a timely fashion
back then.

Merging the “binary” npm importer IMO is one way to acknowledge that
there’s a very concrete use case, that we’re unable to address it the
Right Way, but that we offer a middle ground for users.

Ludo’.