brainstorming for UDS-N - Application Developers

[Krzysztof Klimonda]

On Tue, 2010-10-05 at 12:57 +0100, Matthew Paul Thomas wrote:
> > 
> > Yes, it is a problem but not that bad. If application is popular there
> > is a good chance that both upstream and ubuntu developers know about it
> > and keep it maintained. That leaves a lot of packages that don't have
> > any active Ubuntu maintainer - some of them are cared by upstream
> > developers who ask us -- either by sending mail to the u-d-d mailing
> > list or by asking on #ubuntu-devel/#ubuntu-motu IRC channel -- to
> > upload a fix. That of course, leaves quite a bit of applications but,
> > at least in my opinion it's not that usual to say that we have to
> > revamp it.
> 
> That's to be expected, if people heavily involved in that process seldom
> compare it with other platforms.

Point taken, I'm awaiting the "Application Developers" track where we
can discuss that and present differences.

> 
> >> There has never been a "big distribution". No distribution, Ubuntu
> >> included, has ever had more than 2 percent market share.
> > 
> > big in terms of developers, of processes used for development etc
> > rather than the market share
> 
> The worst of both worlds, then: complex processes *and* low market
> share. :-)

But I'm trying to point out the the processes are fitting the current
development style.

> >...
> >> Yes, that's part of the problem. Packaging should not require that
> >> experience and understanding of the system. Thirteen-year-olds write
> >> and sell iPad applications.
> > 
> > No, they can't. You have to be of the legal age (and pay $99 a year) to
> > even get a chance to send your application for a review.
> 
> <http://itunes.apple.com/us/app/ichalkboard/id322491414?mt=8>
> 
> When iChalkboard 1.0 was released, its primary developer was 13. Its
> designer was 14.

Great project but they still had to have a help with submitting it to
the Apple. It's hard, for me, to tell how easy had it been for them to
do it - and there are both 14 years old maintainers and 14 years old
programmers in the FOSS world.

But yes, we could make the process easier - there actually has been some
work being done on this front in Debian. The DEP-5 proposal (machine
readable debian/copyright) would also make it possible to generate
copyright file from the IDE - most projects are fairly simple in license
terms anyway.

The hardest part of packaging that remains is debian/control and it also
could be made simpler if our plugin for Anjuta had enough informations
from other sources.

> >> Do you think that more than one in a thousand users of the average
> >> Ubuntu application have ever looked at its changelog?
> > 
> > So? Are you suggesting that we should not care about those, more
> > technical and knowledgeable users?
> 
> No -- just that changelogs, as they are currently written and presented,
> fail miserably at the task of making "it easier for our users to make
> sure what can they do with their software". I'm sure we could fix that
> in ways that don't require packaging to remain complex.

Yes, they could be better - and their quality doesn't really depend on
the complexity of packaging. It's just both tedious and, in some cases,
hard to write a decent (i.e. readable and interesting) changelog. We
should probably split changelog into two parts - a maintenance changelog
where we keep all the changes that has been made to the packaging and
the one for application - where new features and outstanding bugfixes
are mentioned.

> >> <https://wiki.ubuntu.com/PackagingGuide/Complete> is 16518 words long.
> >> Even the "Basic Packaging" section alone is longer than the US
> >> Declaration of Independence, and the original US Constitution,
> >> combined.
> > 
> > But that's a different problem - yes, we can work on getting our
> > documentation fixed. At the same time creating a packaging for a single
> > Desktop application takes few minutes assuming it uses autotools or
> > another build system supported by debhelper - e.g. debian/rules is 3-4
> > lines long, debian/changelog is created by dh_make, there is no need
> > for maintainer scripts other than those created by debhelper.
> 
> I take your word for that, but everyone I know involved with packaging
> (up to and including Michael Vogt) tells me that it's unreasonably
> difficult in general.

The complexity quickly grows as the packaged software gets more complex
- it's much harder to package and maintain library or system-wide
daemons then it is to package a "leaf" program - some Desktop
application for example.

> 
> As Marc Deslauriers says, we could have a one-click "Package and submit
> to Ubuntu Software Center" plugin for Anjuta, and similar for other
> IDEs. That would be a good step. But we'd still be subject to the Law of
> Leaky Abstractions: if anything went wrong, it would be hard to figure out.

Yes, that's true for any application written on top of files that were
created with manual edition in mind.

> 
> >...
> > But is it because the process is wrong or because people are not aware
> > of it? Maybe promoting backports (and allocating more resources to make
> > it snappier) is a better way.
> 
> It's worth a try, sure. But we don't have enough decades to try things
> like this one at a time. Let's try other things as well.

Sure, that's a great plan but I'm not sure if that's going to work. At
the end the process that is going to get choosen is the one that more
resources has been put into.

> 
> >...
> >> In the past four years, not one but two operating systems have each,
> >> starting from zero, accumulated more than 20 *times* as many
> >> applications as Ubuntu has. What we are doing is not working. It's
> >> time to try something else.
> > 
> > Why? Most of application for both iPhone and Android are completely
> > useless. You can hear people complaining about it all the time - dozens
> > of applications doing the same thing, "fart apps", direct clones. Sure,
> > they inflate the number of total applications but I'd disagree that
> > they make platform more appealing to users.
> 
> Any sufficiently large collection of things is subject to Sturgeon's
> Revelation. But iOS and Android customer growth speaks for itself.

But are they growing because of tens of thousands applications available
or because both are that much better than their competitors and both get
an enormous media campaigns?

Yes, we need more great applications. But are we going to get them only
by making publishing them easier? People are willing to do everything to
get their application published in the iTunes store because they see
others making hundreds of thousands of revenue out of their
applications. 

> 
> >...
> >> Why would a developer want to bypass checks that would help save them
> >> from disappointing their users?
> >>
> >> Do you have any examples of sanity checks that produce unfixably wrong
> >> results?
> > 
> > Yeah, If we make it easier and easier to get applications into our
> > software center it's going to get worthwhile for attackers to use
> > software center as a point of attack for users' computers. To either
> > tamper with their data or to just use new computers for a botnet of
> > sort.
> 
> Attackers can do that with a PPA right now, where it's even less
> tractable -- there's no "Report as inappropriate" button on a PPA page.

Yes, and that's my biggest problem with the PPA model. There were a
discussion about creating something like "a trusted PPAs" for people who
are Ubuntu or upstream developers so they could, for example, distribute
nightly builds of software.

> 
> Keeping our OS secure, by having processes that result in it having few
> applications, is just a large-scale form of security through obscurity.

It's a much easier thing to screen application the way Apple does with
the iTunes Store when you have a complete control over a platform. It's
also much safer not to verify applications (Google doesn't have an
approval process afair) when your platform is designed to be as safe as
possible. Our platform is neither designed with this goal in mind or in
our total control.

We could start working on a sandbox for applications - but is it really
how we see the future of Desktop Linux?

> 
> >...
> >>> [1] I use "for our users" quite a lot - that's because what is good
> >>> for developers (or even for us) is not always good for the users of
> >>> our distribution - for example developers want to push their new
> >>> software to as many people as possible in as little time as possible
> >>> but, on the other hand, not all users are interested in the newest
> >>> and greatest stuff.
> >>
> >> That decision should be up to individual users and organizations.
> > 
> > But if we don't prepare small patches for applications the choice we
> > leave our users with is whether they should keep current software and
> > deal with bugs (and security patches) or should they update. Various
> > upstream projects use different development models and not all of them
> > release point releases with bug fixes.
> 
> Ubuntu users already have that problem, in the worst possible way. Your
> organization needs the new version of LibreOffice? Oh, sorry, you'll
> have to upgrade your entire operating system, getting new versions of
> every other application at the same time. Good luck with the retraining!

That's what -backports are for. They don't work because there are so
little people working on them.

> 
> >...
> >>> Things like this are done - beta tests etc. but not at this level. It
> >>> would feel like we, as Ubuntu, are limiting our users.
> >>
> >> Things like this are often done at this level, and at much larger
> >> levels. Twitter is doing it right now with 105 million registered
> >> users. Microsoft does it for Office's half a billion users. And
> >> Facebook also often does it with half a billion active users. They
> >> would be incompetent if they didn't.
> > 
> > And neither of those companies and projects is based on free software
> > and a community of supporters, developers and advocates. It's one thing
> > for developers of closed applications or services to decide that they
> > want only a part of their users to have an access to new software
> > version (and we should provide tools for them to do that) and a
> > different one for free software projects to do that - if only because
> > it's not entirely free and open model.
> 
> I don't see any reasons there. How does the licensing model have
> anything to do with the rollout process? For example, I'm pretty sure
> that any changes to Launchpad's rollout process since it was closed
> source have nothing to do with the fact that it's now open source.


Everyone has a choice to use the edge Launchpad server. My understanding
of the proposal was that the developer chooses how many people are
allowed to use a beta software and others don't have access until later.

> 
> >...
> > All points I'm making here (and in the previous email) are probably
> > only valid if we keep the current development style. But the email I
> > was answering for was not about whether we should change Ubuntu from
> > the current model (where its, in fact, a software distribution) to the
> > model where we ship only a base system, a software store/center and a
> > set of libraries for developers to develop for Ubuntu. I actually
> > believe that it would be a really good idea to focus ourselves only on
> > a core system, but that requires quite a lot of discussion.
> >...
> 
> Cool. Those aren't the only two options, though. We could ship a basic
> set of applications (browser, mail client, basic word processor, media
> player, etc) like Windows and Mac OS X do, *and* change the model for
> distributing other applications.

Yes, by the "base system" I've meant both the system, DE and a set of
applications that are choosen as default. Also, what about libraries?
Who should package them?

-- 
Sent from Ubuntu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20101005/29df20e8/attachment.pgp