Re: [Userops] What is "userops", and who does it target?

[Stefano Zacchiroli]

On Sun, Apr 12, 2015 at 11:16:11AM -0500, Christopher Allan Webber wrote:
> This is a good point.  First of all, it's worth noting that "userops" is
> a vague term, totally undefined at this point, more of a rallying cry
> for people working on similar issues, but it's probably worth defining.

Thanks Chris, this is an important discussion to have in the early days
of this mailing list / community.

> Here's attempt one at a definition:
> 
>   Userops is about deployment solutions that target users rather than
>   developers or businesses.
> 
> But wait, that's not right.  Many times, developers *are* users, if we
> think in the "user freedom" style of users.  Sometimes, users are
> hackers.  So, try two:
> 
>   Userops is about deployment solutions targeting user freedom, rather
>   than developer freedom.

I've thought about this, and there is something in it which strikes me
as not-quite-right yet.

The debate about how much more empowered "tech-savvy" users *can* be, in
comparison with "non-tech-savvy" users, is an important one. But I'm not
sure we should base the "userops" definition on top of that.

My main argument for the above claim is that, in a centralized world,
tech-savvy users are not much more empowered than non-tech-savvy ones.
Consider the case in which hackers are stuck using some proprietary
cloud stuff (no matter the *aaS service model), of which nothing is
freely distributed, nor suitable Free Software replacement exist. Those
hackers can not, no matter their technical abilities, deploy the same
infrastructure (or a similar one) on their own servers, and set
themselves free from the centralization grasp.  Sure enough, they are
hackers, so they can sit down and rewrite from scratch a Free Software
replacement, whereas non-tech-savvy users cannot. But that's basically a
truism, which always applies, and does not lead us anywhere IMO.

A counter proposal (not very much fleshed out as of now) of mine would
be to base the userops definition on the kind of *applications* that
should guarantee freedoms to users.

Today, it's pretty clear to me that we know how to set free users of
classical desktop applications that require very little communication
with other peers to work. We might not be there yet for a lot of use
cases, but we (developers) basically know how to do that. We also know
which deployment model works well for users (package managers and/or
"app stores") and enable them to easily install/upgrade/remove
applications. Arguably, we also have a decent market share here, at
least in comparison from where the Free Software movement started
decades ago.

The situation is much different when we look at "distributed
applications", where communication among remote peers is key. There we
neither have a decent market share, nor we know how to decently develop
Free Software replacements, nor we are sure about the most appropriate /
easy to use deployment models.

So, if anything, I'm inclined to think that the userops mission should
be framed in terms of "how can we achieve wide-spread user freedoms for
distributed applications, similar to what we have achieved for desktop
applications". That way of seeing things is absolutely neutral to the
user / developer distinction, and I think that's how it should be.

The main difficulty will be defining properly what a "distributed
application" is. There lies the devil. Because, e.g., mainstream social
network are not "distributed" in the classical sense, then you need to
pick one between "distributed" and "federeted", etc etc etc. But
agreeing (or not :-)) that this is the main angle to focus on would be
an useful step forward, I think.

Thanks for starting this debate (and for this list!),
Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  address@hidden . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »