Proposing a New App Developer Upload Process

[Scott Kitterman]

Matthew Paul Thomas <mpt at canonical.com> wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Scott Kitterman wrote on 05/09/12 18:54:
>> 
>> Matthew Paul Thomas <mpt at canonical.com> wrote: ...
>>> 
>>> That's a near-tautology. "Distributions" are named after the 
>>> assumption that selecting and packaging other people's software
>>> is a way to produce a useful operating system.
>>> 
>>> That may work for a few hundred thousand or even a few million 
>>> notebook/desktop users, but it has failed to grow beyond that.
>>> The distro model discourages application developers, slows
>>> application updates (making the installed base less reliable and
>>> less secure), and distracts Ubuntu developers from improving
>>> Ubuntu itself. Eventually the time comes to say "enough, let's
>>> try something else".
>> 
>> This though is a much bigger step than just providing an easy
>> entry point for additional apps.
>
>Sure. It's necessary but not sufficient.
>
>> It brings in many fundamental questions that need to be answered 
>> before we can really start to proceed:
>> 
>> - 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.
>
>> - How do we provide stability for users that are more interested
>> in using what they have than the latest upstream crack that was
>> pushed out the door at 2am last night?
>
>By presenting application updates as opt-in rather than opt-out.
><https://wiki.ubuntu.com/SoftwareCenter#updates>
>
>> - How do we deal with library transitions?
>
>Others on this list can answer that far better than I can.
>
>> - If application author s are getting unleashed, why can't library 
>> authors get unleashed too?
>
>Because those are mutually exclusive (at least for libraries that are
>part of Ubuntu itself), and on a successful platform application
>authors are far more numerous and distributed.
>
>A library that wasn't part of Ubuntu itself could be unleashed in the
>same way, but it would be application authors' responsibility to judge
>how serious the library author was about backward compatibility.
>
>> - What about packages that provide both applications and
>> libraries?
>
>They would have to play by library rules: preserve backward
>compatibility, and/or not be part of the official APIs.
>
>> - What does it mean to be a distribution?
>
>A distribution is to an operating system as a runway is to a flight.
>It's the expensive but vital buildup of momentum before takeoff.
>
>> ...
>>> 
>>> There are a lot of developers involved in packaging, compared to 
>>> what? Two years ago there were 160 MOTUs. Today there are 149.
>>> That isn't how you scale to an order of magnitude more
>>> applications.
>> 
>> Certainly, but that's also the result of a determined effort to
>> kill off MOTU from which that community has never recovered.  There
>> is some good work going on now to bring in new blood, so I expect
>> the numbers to start to improve.
>
>I'm surprised to read of "a determined effort to kill off MOTU", but
>if those numbers increase then good. MOTUs will be vital for years to
>come.
>
>> I do agree that we need something different to scale to an order
>> of magnitude more applications.  I don't agree that doing that 
>> particularly solves any problems we're having.  I can't remember
>> the last time I wanted a tool to do a job and there wasn't one
>> handy, with the exception of cases where a free software solution
>> wasn't legally possible.
>
>That's great, but not particularly telling, because if it wasn't true
>perhaps you'd no longer be here to discuss this.
>
>>> Maybe the current proposal isn't the best way to solve the
>>> problem. But the first step is to recognize the problem.
>> 
>> I understand the problem statement.  To the extent there are real 
>> problems (e.g. key applications out of date), this proposal is
>> barely the tip of the iceberg of what would need to be addressed to
>> make the transition to a model where we outsource that to
>> application developers.
>> 
>> ...
>
>So, assume that we can't do everything at once, but we want to act as
>soon as possible. What do you suggest we do as well, or instead?

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.).

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

In short, there ought to be some shared vision we can work towards.  To twist the story of the blind men and the elephant, if you're making a tail, it's really hard to tell if you're doing it right if you don't know it will go on an elephant.

Scott K