A change of maintainership for Mercurial [LWN.net]

A change of maintainership for Mercurial

Posted Jan 26, 2016 7:42 UTC (Tue) by oldtomas (guest, #72579)
In reply to: A change of maintainership for Mercurial by jeff@uclinux.org
Parent article: A change of maintainership for Mercurial

> I am nervous about the decline of tools other than git.

So am I. Although I might qualify as a kind of Git fanboi. After years of CVS (which I kinda enjoyed), suffering under SVN's bureaucracy and trying to wrap my head around TLA (I didn't like Bazaar that much) -- git hit home for me. It somehow resonated with my brain structure. I'm happy with it.

But this tendency (which seems to be accelerating dramatically) of "winner takes all" makes me worry. Not only in the realm of version control systems.

to post comments

A change of maintainership for Mercurial

Posted Jan 26, 2016 16:02 UTC (Tue) by drag (guest, #31333) [Link] (1 responses)

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).

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.