[Top][All Lists]

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

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

From: rysiek
Subject: Re: [libreplanet-discuss] Truly decentralized/federated software development platforms?
Date: Sun, 22 Mar 2015 11:47:29 +0100
User-agent: KMail/4.13.3 (Linux/3.13.0-46-generic; KDE/4.13.3; x86_64; ; )

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 ::

Attachment: signature.asc
Description: This is a digitally signed message part.

reply via email to

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