Proposing a New App Developer Upload Process

[Scott Kitterman]

On Thursday, September 06, 2012 09:36:05 PM Matthew Paul Thomas wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Scott Kitterman wrote on 06/09/12 14:22:
> > Matthew Paul Thomas <mpt at canonical.com> wrote:
> > 
> > ...
> > 
> >> Scott Kitterman wrote on 05/09/12 18:54:
> > ...
> > 
> >>> - In this brave new world, what is the definition of "Ubuntu
> >>> itself"? If the application developers are unshackled then it
> >>> must be some subset of what we consider Ubuntu to be today.
> >> 
> >> The shell and everything that makes it work (down to the kernel
> >> and init system), the toolchain, official developer APIs and the
> >> software that implements them, and whichever apps are installed
> >> by default.
> > 
> > ...
> > 
> > I suspect not everyone shares your definition of what Ubuntu
> > is/will be.  Even the I favor a more traditional scope myself, I'm
> > very surprised you didn't include the desktop environment (e.g.
> > Unity, Plasma, etc.).
> 
> That's what I meant by "the shell".

Yes.  Someone else pointed that out already.

> > I think it's critical that there be some shared vision of where we
> > are going and even though there won't be resources to do
> > everything at once, a broad outline of the chunks of work needed to
> > get there.
> > 
> > To pick just one example, rolling delivery of applications and
> > offering multiple versions of the same package (which is what the
> > BSD Unixes do, although not in a way I've personally found at all
> > satisfying as a user) implies huge changes in package management.
> > Not the least of which is the ability to support downgrades,
> > including migrating per user settings back to previous versions.
> 
> Windows, OS X, iOS, and Android all let an author issue a new or
> updated application within a week or so of wanting to, which I guess
> is what you mean by "rolling delivery". This whole discussion is
> predicated on that being a requirement for a mass-market OS.

On iOS and Android there's rather more extreme sandboxing than is being 
proposed here that make potential interactions between applications less of an 
issue.  The term DLL hell was invented for Windows.  I don't think it's at all 
obvious that replicating the existing systems is a path to success.

There is an assumption here that there's a vast user base that awaits if only 
it weren't so hard to run the latest versions of things.  While there are 
certainly many such people in the geek community, the vast majority of non-
technical end users neither know nor care about what version of anything they 
are running.  The class of users that will tell their friends "I just bought 
Facebook" to mean the bought a computer isn't interested in such things.  To 
give a specific example, it was only about 5 years ago I got my father off of 
Office 95 and that took pressure.  He saw no reason to change something that was 
doing what he needed.

If Ubuntu wants to hit the mass market, it needs to find ways to be better, not 
ways to be the same, but cheaper.  Personally, while I know that application 
developers get grumpy about it, I think that the stable model with periodic 
upgrades if desired is something most users would like better than what they 
experience with other O/S's.  It's still good to find ways to make the flow of 
fixing actual bugs work better, but I don't think there's a huge market for 
getting every single application update and working through new sets of 
issues.

> None of those OSes offer application downgrades (though individual
> applications might). None of them migrate user settings to previous
> versions. ("The file “iTunes Library” cannot be read because it was
> created by a newer version of iTunes. Would you like to download
> iTunes now?") And absent that settings problem, OS X is the only one
> that makes multiple application versions moderately easy ("portable
> apps" on Windows being the exception rather than the rule). That tells
> me that while they might be desirable, none of those three things is a
> requirement for a mass-market OS.

It is also quite normal for things to get screwed up on other operating 
systems and people do a full reinstall to fix it.  One of the fundamental 
design principles behind package management in Debian and by extension Ubuntu 
is that once installed, systems can just be upgraded.  Reinstalls should not 
be needed.  I think this is an important feature that should not be lightly 
abandoned.  I think the implication of that is you've got to find a way to 
support downgrades.  I think it's feasible, perhaps using something like 
etckeeper, but it would take work.

Allowing areas where we beat the proprietary competition in quality/ 
capability to degrade to their level is not a recipe for success.

> > It doesn't give the user much to give them the ability to choose
> > when to upgrade a package if you don't also give them the ability
> > to change there mind if the experience is poor with the new
> > version.
> > 
> > ...
> 
> Even if that's a problem worth solving, that doesn't necessarily mean
> it's best solved at the same time as the app developer upload problem,
> or that it even affects the solution for that problem. If you think
> either is true, perhaps you could explain why, and describe how the
> solutions might coexist.

The app developer story is only one small part of a larger story.  Without 
having some understanding of the broader visions, it's hard to know what's 
suitable and what's not.  While I think the proposed changes, modulo resolving 
the file conflict issue, are largely suitable to the goals that are proposed for 
them, that doesn't follow that this is a step towards delivering all 
application this way.

The current ARB process and this new proposal are focused on a specific class 
of applications that make use of some specific restricted features of the 
operating system.  The current proposal is geared towards that.  If the real 
goal though, is to deliver all applications this way, I think this proposal is 
not very useful because I don't think it's extensible in the ways it would 
need to be to grow into that.

So if the goal is the class of applications that the ARB has been focused on 
so far, it's a decent proposal that with a little work is probably worth 
doing.  If the goal is ALL (or almost all) applications, then that's a very 
different story.  I think it's probably a dead end path.

That's why I believe it's important to have the larger picture in mind and 
some consensus around it before plunging in to implementing bits of it that 
may or may not prove to be useful to the actual long term goal.

Scott K