Request For Candidates: Application Review Board

[Allison Randal]

On 08/18/2010 02:40 PM, Scott Kitterman wrote:
> Quickly, when it was developed was described as being aimed at the
> opportunistic developer who needed something relatively simple to solve a
> local need.  The distribute side of the equation for these kinds of developers
> is a local problem and not one for Ubuntu.

Yep, the team who started Quickly focused on simple, local apps, and it 
was the right place to start. But, the sharing component was embedded in 
the idea from the beginning. Scratch wouldn't be a success without both 
pillars: easy to create, easy to share. To really do that well, creation 
and sharing need to be tightly integrated. In Scratch, there's a "Share" 
button right in the IDE. Click the button, enter a title and 
description, and hey-presto your app is distributed. We're a long way 
off from that, but it's an inspiration for future potential.

It could be anyone's problem, but the Ubuntu project is in a unique 
position to make it happen, and one of the core principles at the heart 
of Ubuntu is taking disruptive, visionary, game-changing steps that pave 
the way to the future.

> I think that targeting these kinds
> of developers was and is important, but that is orthogonal to the post release
> apps process, so I think post release apps process is a logical next step only
> after you've redefined the problem, but in the end, I don't think it actually
> gets us there at all.

I'll flip that around and say that this new apps process is a result of 
redefining the original problem (lightweight app sharing), in the 
context of an already working solution to a different problem 
(Debian-esque package distribution). With refinement over time we'll be 
truer to the original idea.

> No one (that I recall) has argued against the idea of making it easier to get
> new apps to users.  The argument (at least mine) has been that inventing an
> entire new infrastructure and set of processes rather than building on what we
> have right now is not the best way to go about it if we are delivering Debian
> packages.  If we want to radically simplify the process to achieve this goal,
> then we need to change in infrastructure to support applications.  The thing
> IOS and Android have that we don't is a sandbox structure to limit the risks
> of installing untrusted/lightly reviewed applications.

Completely agreed, "if we are delivering Debian packages". That is, if 
the whole purpose of this new process was to improve the Debian 
packaging process, we should do that by improving the Debian packaging 
process. Okay, that's a tautology. :)

But, while it made sense to use (very simple, often automatically 
generated) Debian packages for this phase to take advantage of existing 
infrastructure, there are also many ways in which Debian packaging is a 
less-than-ideal fit for lightweight app sharing. This is really 
something new and different, a fork in the road. Not an "either/or" 
fork, but a "both/and" fork. That is, we continue with improvements to 
backports, etc. for the Debian packaging system which is (and will 
continue to be) the core of the Ubuntu family of distributions AND we 
explore the possibilities for lightweight app sharing.

> I'd like to see the foundation work for providing a similarly safe environment
> (sandbox) precede  this new process it rather than follow.  I also think that
> labeling this the Ubuntu process for getting applications to users post
> release is very confusing for people who are interested in more traditional
> packages that can already be delivered to users via backports.  We need a
> different term for these sandboxed applications that can be quickly delivered
> in a lightweight process.  Users will still want traditional packages and so
> we need to clearly distinguish between the old and the new in technical
> structure, language, and process.  Doing the process first puts the cart before
> the horse.  It is confusing at best.

The naming is confusing, we'll need to do some work on that as a community.

And it would be wonderful to have the sandbox in place from the start. 
But, at UDS-M the discussion all centered on whether there was any way 
at all a lightweight app sharing process could be crafted that would fit 
with community policy, satisfy the requirements for security and quality 
control, and be approved by the technical leadership. We were still in 
the early "feasibility" stage, a long way from writing specifications 
for advanced features that require substantial development.

And there's a bit of a chicken-and-egg problem getting volunteers (or 
paid developers or the managers who allocate their time) to invest in a 
new idea. You need to show it's possible, and then get enough working to 
show that it's usable and desirable. It's a whole lot easier to get 
people involved in fixing a seedling, than in bootstrapping something 
completely new.

> I'm still not clear that absent a true sandbox where it is 'safe' to install
> applications that are not fully trusted, there's any point to this at all.  I
> think there are active risks associated with this process of dilution of
> talent and end user confusion.  I would prefer it if people would take this
> feedback and defer deployment of anything until there is something that will
> usefully distinguish these new [whatever we are going to call them]
> applications from applications delivered as Debian packages.

I expect that at UDS-N we'll have at least one blueprint on sandboxing. 
But I also wouldn't want to hold back the whole idea for one feature 
(even an incredibly important feature) when we can phase it in gradually 
as it's developed. As we offer stronger sandboxing, we can lighten the 
process for sandboxed applications, lower the demands on the application 
reviewers, and even broaden the pool of people who can participate in 
application review. (A modestly sandboxed application could be reviewed 
by any reasonably skilled Python developer, while reviewing heavily 
sandboxed applications could be a task for new developers. More on that 
in reply to Robert.)

> There is definitely a problem that needs solving, so I'm interested to help
> work on it.

Excellent, thanks! And thanks for your thoughtful comments!

Allison