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 04:39:
>> 
>> On Tuesday, September 04, 2012 06:01:56 PM Steve Langasek wrote: 
>> ...
>>> 
>>> There's a general sense that the Ubuntu archive can't scale out 
>>> to the degree it needs to in order to take on the next challenges
>>> for the platform. While Debian packaging isn't hard for you or
>>> me, and while it's definitely gotten much easier over the past 4
>>> years or so, it's still not so easy that we blindly trust outside
>>> contributors to get the packaging right without review by an
>>> Ubuntu developer.  We do not have an infinite supply of Ubuntu
>>> developers to do this review. Should the set of software
>>> available to Ubuntu users through apt be limited to only that
>>> software that Ubuntu developers (or Debian maintainers) have time
>>> and interest to take care of directly?  Or should users have
>>> better (not perfect, but better) ways to install software that's
>>> not gotten the attention of the elite inner circle?
>> 
>> First, this elite inner circle has an open door.
>
>Which requires using Launchpad Bugs (regardless of where you actually
>track bugs for your application), knowing what "Debian" is, using the
>archaic IRC chat system, signing a "Code of Conduct" that is almost
>entirely about contributing to Ubuntu itself, and other things that,
>for a typical application author, have no relevance whatsoever.
>
>This inner circle didn't deliberately set out to be elite.
>
>> Second we also have a limited supply of ARB reviewers.  Starting a 
>> new review process (ARB) because their aren't enough reviewers was 
>> clearly doomed from the start, so much of my "I don't understand 
>> this" comes from the current process where we substitute one review
>> process with insufficient reviewers for another one with 
>> insufficient reviewers.
>
>Yes, I sighed when the ARB was announced for the same reason. But the
>conclusion should not be to go back to the first process that still
>has insufficient reviewers. It should be to find a process that does
>not require reviewers -- or at least, requires them to spend on the
>order of a hundredth of the time per application that they do now.

I don't disagree with that, but we ought to build something designed to scale and while I think this design would be a step in the right direction, I think it will fail to scale sufficiently if it is successful in the way you envision.  It would be better to get a design that has sufficient potential for scalability rather than one we know we'll have to throw but and redo.

I think application quality is a much bigger issue than the difficulty of getting such applications in Ubuntu.

>> Additionally, I think the notion that "Oh, X has a bazillion apps, 
>> so we need that many too" is mistaken in many regards.  How many 
>> office suites do we need? I'd say one that works robustly, 
>> reliably, and compatibly with it's proprietary competition (and 
>> despite a huge amount of work by people deeply interested in 
>> solving this problem, IMO we don't have it). How many solitaire 
>> games do we need?  I'm not sure, but I'm confident it's fewer than 
>> one finds in whatever Android Marketplace is called now.
>
>Nearly two decades have passed since operating systems were judged
>primarily by their office suites and solitaire games. Photo
>retouching, online note syncing, genealogy, kiosk-style UI for the
>elderly, music notation, home accounting, calendaring, paying taxes,
>making greeting cards, chess, Web design, screencasting, CAD, school
>timetabling, wedding planning, screenwriting. For thousands of "long
>tail" genres like those, competing OSes have multiple applications to
>choose from -- but the published choices in Ubuntu are either
>non-existent or, not to put too fine a point on it, terrible.
>
>Now, there are many reasons for that: difficulty of publishing is far
>from the only one. But it would be a subtle error to think that an
>application not existing for Ubuntu at all means that difficulty of
>publishing is unimportant. It may be one of the reasons nobody
>bothered to develop the application in the first place.

It's possible, but considering we have many major application classes without a single entry that really qualifies as a peer competitor (including ones that did get in), I think this is very unlikely to be a significant factor.

>> Historically, Linux distros have included a curated collection, 
>> some larger, some smaller, of relevant applications, libraries, etc
>> that can be used on the base operating system.  That curation 
>> process is one of the real strengths of Linux distributions...
>
>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.

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.

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

 - How do we deal with library transitions?

 - If application author s are getting unleashed, why can't library authors get unleashed too?

 - What about packages that provide both applications and libraries?

 - What does it mean to be a distribution?

>> ...
>> 
>> There are a LOT of Debian/Ubuntu developers and non-developers 
>> involved in packaging, so I suspect the good stuff will get 
>> attention (I may be wrong).  If such a system existed, then, if it 
>> was really clearly distinct from Ubuntu, I think it might make 
>> sense, but what's been done so far doesn't meet that goal and 
>> neither does what's specified.
>> 
>> ...
>
>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 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.

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

Scott K