brainstorming for UDS-N - Application Developers

[Matthew Paul Thomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Krzysztof Klimonda wrote on 04/10/10 19:22:
>...
> On Mon, 2010-10-04 at 15:31 +0100, Matthew Paul Thomas wrote:
>...
>> The usual consequence of the current approach is that people have to
>> suffer a bug for up to six months after the application developer has
>> released a fixed version.
> 
> 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.

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

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

>...
>>>  Adding a detailed changelog makes it easier for our users
>>> to make sure what can they do with their software. detailed
>>> dependencies make it easy to make transitions etc.
>>
>> 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.

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

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.

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

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

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

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

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

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

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

- -- 
Matthew Paul Thomas
http://mpt.net.nz/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyrEpcACgkQ6PUxNfU6ecq5sQCgmLnJMlq8rLnQIWXlQF59sNbH
taoAmQHo55jTZBMMLiV0M6wkasNpdEA9
=6sJt
-----END PGP SIGNATURE-----