Steven D'Aprano <steve+comp.lang.pyt...@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 <b...@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 -- https://mail.python.org/mailman/listinfo/python-list