[libreplanet-discuss] Tackling Network Effect (Re: Skype Replacement?)

[Michał 'rysiek' Woźniak]

Dnia poniedziałek, 14 maja 2012 o 13:05:05 Ramana Kumar napisał(a):
> On Mon, May 14, 2012 at 11:16 AM, Michał 'rysiek' Woźniak
> (...)
> 
> > We need something like this for Free Somftware based services, as
> > currently we are all taking a beating due to network effect (look
> > at Twitter, Facebook, Skype, Dropbox - it's all network effect
> > at work). And we cannot tackle network effect if we do not build
> > a vast network of users.
> 
> Can you describe ways in which we might do this in more detail?
> Perhaps we can figure out a good solution here and then do it!
> Be concrete, perhaps using my "skype replacement" problem as a
> motivating example.

Sure thing. I did it already (partially) in the "New GNU" thread (by 
the way, where are the list archives?..), I'll try to do a better job 
here, though.

We could create a *simple* directory protocol (no, LDAP won't do) for 
finding out people's e-mails, JIDs, etc (if, of course, those people 
would provide such data); integrate it into available solutions 
(client-side: Pidgin, mail clients, Diaspora, etc.; server-side: 
ejabberd, mail servers, Diaspora, etc.) - when providing profile data 
(like e-mail addr) users could select to make that info available for 
federated access by other servers and clients.

We could create a website for "leave your proprietary network/service 
day", hold such a day say once per two months. People could log-in 
with their proprietary network logins (Facebook/Twitter/Google+) and 
pledge leaving the network for a libre one (like Diaspora) or at least 
setting up an account on a libre network  on a given day, or when the 
number of their friends pledging the same reaches a given number.

This would obviously be sent to their walls, timelines or whatever 
it's called in their proprietary social network of choice. their 
friends would get the message and see that maybe they are not alone in 
their idea of leaving Facebook.

This is obviously just a preliminary idea, it would need to be 
properly thought through and blueprinted.


Second idea that I might start realising soon myself is firing up 
cloud service providers that integrate many libre software services 
(like XMPP, e-mail, Diaspora, StatusNet, OpenID, Mozilla Sync, 
ownCloud, etc.) so that people would have a chance of using a *single* 
service for all their communication needs, while retaining control 
over their data (using standard, free software projects would mean 
switching the provider would be much easier than leaving Facebook).

These two ideas should for obvious reasons be put into practice about 
the same time.

> Describe the world where I find out Skype is nonfree and then [go
> where] ([why there?]) and [do what] to get a free replacement,
> that anyone can easily do.

http://podupti.me is just such a place to go for "Facebook 
replacement". It needs better exposure, and much better information 
on-site, but it's the right idea.

> > > One word: email.
> > 
> > I also love this example and I use it whenever I can.
> > 
> > However, thing is: when e-mail was just picking up steam, it was
> > de facto the only service to connect users. Hence everybody
> > happily set- up their accounts and actually used it.
> > 
> > Currently the users cannot be bothered with Yet Another Protocol
> > or Social Network, because they already use a multitude of
> > those.
> > 
> > That is one of the reasons why Diaspora, StatusNet, XMPP, SIP
> > hasn't picked up users as fast as we would like them to. And
> > they won't as long as using them is more cumbersome than
> > proprietary, centralised networks/protocols.
> > 
> > I think we have the technology already; we need to focus on
> > tackling the network effect and on heavily usability.
> 
> Do we have the manpower to solve these problems?
> If so, where is it?

Problem is, in my opinion, that we need to refocus.

We - the FLOSS Community - are by and large great technicians, 
programmers, we have the manpower and will to tackle *technical* 
issues.

However, our problems currently are not purely technical; Free 
Software is often technically superior to proprietary/centralised 
solutions, yet users still use the proprietary platforms (ICQ/AIM 
being one of the examples).

Why? Reasons are many. Sometimes it's the usability (like with Skype); 
sometimes it's the network effect - already vast amounts of users use 
the proprietary solution, so the incentive to use it is much stronger, 
as the aim is to keep in touch (Skype, Facebook, ICQ/AIM, etc.).

These two problems are not easy to solve for us, as we are not that 
competent in those areas. Especially usability would need new sort of 
people joining in and helping out - UX designers and the like. This is 
one of the reasons why I feel that while many things Canonical does 
are really bad (please, let's not get into a "Ubuntu is Evuhl" flame 
now, m'kay? ;) ), we are still - as a community - getting a lot of 
good stuff from the fact they are employing UX designers, for example.

Now, the network effect thing is more "tackleable" by us. It's really 
a question of focusing on creating ways for people to feel that they 
are in a group. they are connected, easy ways to find other people, 
etc. Diaspora, as I wrote already, does it well. We should simply move 
this up on our priority list, so that our techie community would find 
that important to work on.

Specifically, I strongly believe that tackling the network effect 
problem is more important than Gnash, Google Earth, FLOSS network 
router drivers. I think it should (after finding a suitable way of 
describing it) make it to the priority projects list.

-- 
Pozdrawiam
Michał "rysiek" Woźniak

Fundacja Wolnego i Otwartego Oprogramowania

P.S.
I strongly believe that centralisation (of data, of communication 
means, etc.) is as big of a problem as something being proprietary - 
because both are related to control. When fighting for Free Software 
we need to fight for decentralisation, too.

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