[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libreplanet-discuss] Truly decentralized/federated software develop

From: Ramana Kumar
Subject: Re: [libreplanet-discuss] Truly decentralized/federated software development platforms?
Date: Sun, 22 Mar 2015 20:45:00 +0000

Just came across this, which might be relevant to this discussion:

On Sun, Mar 22, 2015 at 10:47 AM, rysiek <> wrote:
Dnia czwartek, 19 marca 2015 15:32:09 אנטולי קרסנר pisze:
> rysiek <> wrote:
> > the Gitlab/Gitorius situation rekindled my interest in what I would call
> > the "next step" in software development management -- a truly
> > decentralised/federated platform.
> >
> > First step could be to have different instances being able to "talk to
> > each other" (...)
> > Next step would be to have a truly decentralized solution, a bit like what
> > Twister[1] does for microblogging.
> > (...)
> It doesn't have to be fully distributed. Actually it makes sense not to make
> it distributed, because the last thing we want is a huge ever growing
> "blockchain". What you can safely have is redundancy: distribute copies of
> the repo content on many servers, and allow the front server to choose
> between them, so it's harder to block/censor/DoS the system.

Now, that's something Twister handled quite well -- the blockchain is only
used for very specific information ("who owns what"); the data itself resides
in DHT, which scales much better. So "large blockchain problem" isn't really
an issue.

On the other hand, when you have "servers", you have "admins": people who have
power over the given network. While I myself am an admin of many services, I
can see that this is a liability: admins can be coerced, admins can be
required by law to do or refrain from doing certain things. And most
importantly, server-based infrastructure can lead to secondary centralisation
(e-mail -> GMail et al).

We need to put the very same full-blown peer-to-peer decentralisation that is
(more or less) present on all the lower OSI model layers into the application
layer. The fact we haven't yet is precisely why we have a growing walled
gardens problem.

There are no admins on Twister or BitTorrent, hence there is no way to "take
down content", and no easy way to centralise these solutions (and then exert
control over users). I believe we need something exactly like that for code
and issue tracking.

> I think having a DHT for worldwide project and user search is a good idea,
> and use local development platform serves which can federate. For example,
> in a team of developers works on a project, one of them can host the git
> server at home, or some other truly trusted location, and not in the
> "cloud" managed by greedy selfish corporations.

We *really* need to move beyond the "server" narrative. As I said, federated
servers is a stepping stone, sure, but we need to go in the direction of full
decentralisation/peer-to-peer solutions.

Otherwise we *will* land in the "cloud" of greedy selfish corporations yet
again, just in a bit different manner.

It's also about how easy it is. People choose GitHub over their own repos due
to how easy it is to use it, and then share the code, issues, pull requests,
et al, with other GitHub users (and the assumption is: "everybody has

I look at Twister and I see a solution that requires no setting-up, no
configuration and no upkeep. I just fire up my Twister daemon (or, soon, GUI
client) and I'm already on the network, being able to talk, PM, retransmit,
comment, etc., with all other Twister users.

Imagine something like that with regard to code and issue tracking, and you'll
start seeing what I'm getting at.

> So global things like project and user search can use a DHT, and operations
> across instances (forking a repo from another server, sending merge request
> to a repo in another server, etc.) can work using a federation API, e.g.
> based on Activity Streams like Jessica Tallon's plan mentioned already in
> this thread.

As I said, that can be the first step. But servers are a liability, and
introduce weak points. We can (and should, IMVHO) attempt to move beyond
client-server architecture.

There is also another, more long-term reason: peer-to-peer, fully
decentralised services are something that -- once introduced -- no closed-
source, corporate power can easily hijack. *Only* the free software (which
does not mean "free of charge", mind you!) crowd can and will be interested in
their development. This could be the next "killer feature" of the free
software movement -- no closed/walled corporate service will be ever able to
replicate that, as there is no closed-source business model to build on it,
plain and simple.

On the other hand, freedom-preserving business models are actually *easier* to
build on a peer-to-peer infrastructure, as that means all users contribute
resources (disk space, network bandwidth, etc) so that a libre business
doesn't have to pay for these. Makes it much easier to focus on providing
services (implementation, support, feature requests/bounties, etc).

But that's a broader thing I am thinking about.

Michał "rysiek" Woźniak

Zmieniam klucz GPG ::
GPG Key Transition ::

reply via email to

[Prev in Thread] Current Thread [Next in Thread]