Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #87351

Re: Code hosting providers

Show all headers | View raw

Steven D'Aprano <steve+comp.lang.python@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@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

Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Google Code Shutting Down Josh English <Joshua.R.English@gmail.com> - 2015-03-12 15:26 -0700
  Re: Google Code Shutting Down Mario Figueiredo <marfig@gmail.com> - 2015-03-13 00:12 +0100
    Code hosting providers (was: Google Code Shutting Down) Ben Finney <ben+python@benfinney.id.au> - 2015-03-13 12:37 +1100
      Re: Code hosting providers (was: Google Code Shutting Down) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-13 14:17 +1100
        Re: Code hosting providers Michael Torrie <torriem@gmail.com> - 2015-03-12 21:28 -0600
        Re: Code hosting providers Ben Finney <ben+python@benfinney.id.au> - 2015-03-13 15:22 +1100
        Re: Code hosting providers Ben Finney <ben+python@benfinney.id.au> - 2015-03-13 15:27 +1100
      Re: Code hosting providers Paul Rubin <no.email@nospam.invalid> - 2015-03-12 22:17 -0700
        Re: Code hosting providers Chris Angelico <rosuav@gmail.com> - 2015-03-13 19:33 +1100
          Re: Code hosting providers Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-13 19:59 +1100
            Re: Code hosting providers Chris Angelico <rosuav@gmail.com> - 2015-03-13 22:46 +1100
              Re: Code hosting providers Paul Rubin <no.email@nospam.invalid> - 2015-03-13 14:13 -0700
                Re: Code hosting providers Gene Heskett <gheskett@wdtv.com> - 2015-03-13 19:38 -0400
                Re: Code hosting providers Mario Figueiredo <marfig@gmail.com> - 2015-03-14 01:48 +0100
                Re: Code hosting providers Paul Rubin <no.email@nospam.invalid> - 2015-03-13 19:30 -0700
                Re: Code hosting providers Gene Heskett <gheskett@wdtv.com> - 2015-03-13 23:13 -0400
                Re: Code hosting providers Mario Figueiredo <marfig@gmail.com> - 2015-03-14 04:41 +0100
                Re: Code hosting providers Paul Rubin <no.email@nospam.invalid> - 2015-03-13 20:45 -0700
                Re: Code hosting providers Rustom Mody <rustompmody@gmail.com> - 2015-03-13 22:03 -0700
      Re: Code hosting providers (was: Google Code Shutting Down) Mario Figueiredo <marfig@gmail.com> - 2015-03-13 11:02 +0100
      Re: Code hosting providers Paul Rubin <no.email@nospam.invalid> - 2015-03-13 14:35 -0700
  Re: Google Code Shutting Down Ian Kelly <ian.g.kelly@gmail.com> - 2015-03-12 22:33 -0600
    Re: Google Code Shutting Down Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-13 19:47 +1100
  Re: Google Code Shutting Down Josh English <Joshua.R.English@gmail.com> - 2015-03-13 12:53 -0700

csiph-web