Proposing a New App Developer Upload Process

[Scott Kitterman]

On Thursday, September 06, 2012 09:28:58 AM Michael Hall wrote:
> On 09/06/2012 09:22 AM, Scott Kitterman wrote:
> > 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
> 
> I assumed that the DE is part of what he meant by "The shell and
> everything that makes" and "official developer APIs"

Right.  To me shell is something completely different, but I imagine you're 
right.

Thanks,

Scott K