Code hosting providers

[Ben Finney]

Steven D'Aprano <steve+comp.lang.python at pearwood.info> writes:

> Ben Finney wrote:
>
> > Also worth watching is Kallithea, a new federated code hosting service
> > <URL:https://kallithea-scm.org/>. It supports Mercurial and Git for VCS,
> > code review, and integrates with existing issue trackers. Because it's
> > federated, you won't suffer from vendor lock-in.
>
> What do you mean by "federated"?

A service is federated if an independent, perhaps even competing, vendor
can provide the same service and all users of the service participate,
moving freely from one vendor to another as they choose without losing
any of their data or identity.

Another term is “decentralised”, though that says only what the service
is not. I prefer the term “federated” because it describes what the
service *is*: composed of multiple parties, collaborating on equal terms
enforced for the protection of the people participating in the service.

If a service's features use proprietary protocols or undisclosed APIs or
in any other way make it infeasible for a user joining today to reliably
migrate their accumulated data to a different vendor at some future
time, then that service is not federated and its users are vulnerable to
vendor lock-in.

The email system, for example, is federated: my <ben at benfinney.id.au>
data can reliably (and has, several times) survive migration to any
vendor who provides standard email service, because I lose no access to
any of my history or identity or accumulated data or access or ongoing
functionality with the same data. By “reliably” I mean that I can move
it all from one vendor to another, and even back again if I choose, in
the knowledge that the standard POP, IMAPv4, and SMTP protocols will be
honoured, because to fail in that would be a bug severe enough that the
vendor would be avoided as not providing the service.

Other examples of federated systems include:

* Avatar image serving: Libravatar <URL:https://www.libravatar.org/>.

* Social networking: Diaspora <URL:https://joindiaspora.com/>.

* Version control: Git <URL:http://git-scm.com/>.

* The World Wide Web, and the internet as originally designed
  <URL:http://www.theguardian.com/technology/2012/sep/05/tim-berners-lee-internet-off-switch>.


To the extent that vendor lock-in is possible, the service is not
federated. Corollary: some features of a vendor's offerings can be
federated, and others not; and to talk of the vendor's complete set of
offerings as “federated” can only be true if they all are.

The GitHub service, for example, is not federated, because while mere
Git repositories *are* federated, significant GitHub features (issue
tracker, pull requests, and other important history and project data)
cannot reliably be migrated smoothly to another instance provided by a
competing vendor.

Ned Batchelder and Nick Coghlan have written insightfully on this
<URL:http://nedbatchelder.com/blog/201405/github_monoculture.html>
<URL:https://mail.python.org/pipermail/python-dev/2014-November/137153.html>
with regard to why GitHub – or any non-federated service – is not a good
option for projects that intend to stay viable.


It will be good to see Kallithea <URL:https://kallithea-scm.org/> come
into its own; until then we have GitLab <URL:https://about.gitlab.com/>
and Redmine <URL:https://www.redmine.org/> and even the juggernaut of
Launchpad <URL:https://launchpad.net/>; they are all federated and avoid
vendor lock-in.

We should ask hard questions to projects that choose to host their
irreplaceable data – not just VCS but issues, user identities,
discussions, documentation, etc. – on services that they can't reliably
migrate from. They are demonstrating they don't intend to be around for
long; why should we invest any effort in them?

-- 
 \      “The most common way people give up their power is by thinking |
  `\                               they don't have any.” —Alice Walker |
_o__)                                                                  |
Ben Finney