A change of maintainership for Mercurial [LWN.net]

A change of maintainership for Mercurial

Posted Jan 26, 2016 16:02 UTC (Tue) by drag (guest, #31333)
In reply to: A change of maintainership for Mercurial by oldtomas
Parent article: A change of maintainership for Mercurial

Eventually software, and this is especially relevant for open source, gets to the point were it's just a 'public good'. Just stuff that is used to build other stuff. While previously it was considered of critical importance and was cutting edge.. eventually it becomes mundane and taken for granted as 'just works'.

If you want to avoid the potential problems of relying on software technology that may end up being sub-par then it becomes important for layering and formal APIs. You need to have interfaces that carry out a action, but whose behavior is not tied to a particular implementation. So if your API is command line arguments and environmental variables.. this is good because another tool can come along and provide a interface for compatibility with existing code. However if your application that depends on git goes and does 'fancy' things, like descending into the .git directories and fiddling with bits in there... then it's not going to be robust enough to survive major git revisions, much less replacing git with git++ (or whatever it may be).

to post comments

A change of maintainership for Mercurial

Posted Jan 27, 2016 12:25 UTC (Wed) by oldtomas (guest, #72579) [Link]

> Eventually software, and this is especially relevant for open source, gets to the point were it's just a 'public good'.

I like to squint at it from a slightly different angle. That's why I arrive at slightly different conclusions :)

Ultimately I view the problem of making "the best software" as an optimization problem, faced with a monstrous, ill-defined, constantly changing "goodness function".

Free software attacks it (in the ideal) by some kind of genetic annealing, where solutions in the wild are combined and then start descending some valleys of that function.

If the population is too small, then let's hope we have one solution trickling down the right valley. And that this "ricght valley" doesn't become the "wrong valley" tomorrow.

Actually it's much more complicated than that, because "software" encompasses the mind share and the people around it, capable of care and feeding it.

> If you want to avoid the potential problems of relying on software technology that may end up being sub-par then it becomes important for layering and formal APIs.

APIs (or API philosophies) are just software. Contrast UNIX's traditional spartan-typed ("all is files and streams of bytes") philosophy to old mainframes (structured records, akin to punched cards) or to Microsoft's power shell, passing OO goodness around. That's a lot of constraints which will reflect on the system "evolving" under those respective shadows.

And... the more complex the APIs, the more difficult to implement an "alternative service". That's especially dangerous if "both sides" of the APIs are codeveloped in one project, even in one repo.