The GNOME platform in the 0 cost application deployment era

We’re living interesting times, the web is gaining momentum, the explosion of the smartphones and the mobile market is changing the ways people think about computing, the model to deliver applications and services to the consumer and his role in the usage has radically changed.

The way people create, build and deploy applications has radically changed, 10 years ago you couldn’t even think about deploying a large application without packaging it in a box with a manual and spend large amounts of money to deliver it to the shop shelves, you couldn’t even think about people actually buying it without some sort of advertising in the hi tech magazines.

Today, all that it takes to check what’s new and exciting is a browser, even if the application you want to try is locally installed. In this regard, the traditional closed desktop provides a pretty well understood deployment model for ISVs willing to create and deliver an application, a .msi installer on windows, a .dmg image for Mac OS X where you just drag and drop an icon to your app folder.

Platforms like the iPhone and Android makes application creation, packaging and distribution a well documented straightforward process, except for one thing, their app stores are censored so we have an advantage here that we are not exploiting.

The Unix world in general, and the Linux world in particular is a little special in this regard. By nature, we have a diversity of tools to manage and deploy applications and libraries in our system (yum, apt, ips, ports…), tools like PackageKit can overcome some of the problems of such diversity, although it is getting mainstream slower that we would like to. In general users should be alright with this as things stand today.

However, it is not the users the ones I’m worried about here, it is the CS students and enthusiast wanting to do small fancy apps, it is the small companies with no resources to employ a team of package maintainers to create and maintain a dozen versions of packaging scripts. The very people with the talent to create new exciting apps that can attract and engage users, the very people that can create an ecosystem where creating and distributing large apps for Linux is not a path full of pain. Applications like Photoshop, Autocad, SPSS are not going to get open sourced anytime soon, some of them may never be, the question is, can we attract them to make the free desktop a more appealing option for users? For some people and institutions those apps are the one and only reason to stick to Windows or Mac, so this problem is worth considering.

Yet, it doesn’t look we are getting close to support application distribution models klik in the upstream desktop environments where you could download a file and run your app straight away. This is what the developers want. This is what the users want. We are just not listening them here.

Creating apps for our stack is a pain in the ass, the good practices are fairly undocumented, essential resources are fragmented within several web sites, with different APIs models, there’s a lack of consistency and ease of use. Yes, I know, this is open source, this is the way it’s been so far, you can’t kill diversity.

But… I think we are in a point in time where it is critical to assure our success, or the spreading of freedom we envisioned might be threatened by our competition and we will lose large amounts of control over our technologies as a community once again. Most importantly, I do not only think these radical changes are necessary, I think that we can actually make them happen with no much effort, we just in need for some focus and learn from what others have done to make their platforms attractive. We can bring our stack back to the peak of innovation and leave behind our early 90’s development and distribution style once and for all.

We already have a compelling desktop people want to use, it’s been a hell of an effort to get where we are, things like the new Shell and Zeitgeist can give us some hype on OSNews and Slashdot, but at the end of the day, innovation happens elsewhere, so we better focus on empowering all that creative and passionate people out there who wants to create apps that their family and friends can use.


24 thoughts on “The GNOME platform in the 0 cost application deployment era

  1. @Andreas:
    You’re missing a bit of perspective here. A huge load of corporate desktops out there are rpm based, there are also instat-on boot customized Linux environments. There’s Moblin now which is rpm based as well.
    Besides, there’s the whole root privileges issue.
    rpm and deb files are fine for platform bits, the desktop, core libraries, services… but for apps like inkscape, skype, eclipse… technically there’s no reason to ask for root privileges to the user for them to use those apps.


  2. > I would advice them to do a deb. Really.
    Creating a .deb is deep magic, esp. compared to the simple “Visual Studio -> F5 -> start FTP app -> upload .exe file from Release folder to my web page” distribution process you can use under Windows.


  3. But how do you propose fixing it? Could there ever be Gnome/KDE specific executables that run on top of *any* linux distro?
    Packaging has always been a major problem with releasing closed-source apps on linux (which, lets face it, the big guys will always want to do) due to things like library versions, licenses etc.


  4. Tools that solve these problems in a lot of ways have been around for so long: AutoPackage, OpensuseBuildService, klik… but no one makes the move to support them officially in the distros. Really there should be some decisions held by the opensource community to make the most important distributions do the move at the same time. Sometimes, the slowness of the progress of opensource desperates me…
    FYI, a blog entry I wrote (in Spanish) 4 years ago about this:


  5. @Nick:
    My proposal would be:
    1) Set a LSB standard with a minimum number of Gtk/Qt/Dbus and other freedesktop standards that are all set as API stable and people can count for in the next few years (a cycke for breackage could be set).
    2) Add klick and some integrated UI support for klik or a similar solution in GNOME, KDE and XFCE.


  6. I consider this barrier to entry to be a good thing, proprietary software should stay on proprietary platforms.
    For situations where people are writing their own apps and not creating a distro-quality package, checkinstall is available.
    For those talking about decisions, FLOSS works by people doing stuff, not by telling people to do stuff.


  7. @s:
    If you keep propietary software in propietary platforms, then you keep users away from being able to choose open source platforms.
    This is a HUGE problem in universities, where most of the time they will be happy to run a 100% Linux environment if they could run a few of those propietary apps. Once the move is done, was way easier to create critical mass to create open source alternatives.
    The alternative right now is to have them stuck in the 100% closed source stuck, where everybody loses but Microsoft and a handful of other companies.
    I’m afraid you have a simplistic vision on how to spread freedom.


  8. > Besides, there’s the whole root privileges issue.
    > rpm and deb files are fine for platform bits, the desktop, core libraries, services…
    > but for apps like inkscape, skype, eclipse… technically there’s no reason to ask
    > for root privileges to the user for them to use those apps.
    And yet, we have PolicyKit, with which one can define on his platform rules like:
    “This user needs to authenticate with his own password to update the system, and permission is granted for the whole session”
    “This other user is denied updating, without even asking him the root password.”
    “This user can install application without entering any password ever”
    And the best part is that PackageKit uses PolicyKit 🙂
    Oh but wait, PackageKit does this for rpm, deb, or whatever (granted there is a plugin for it) based distributions ! 🙂


  9. @Pavel:
    And not, Ubuntu is not Linux nowadays, corporate UNIX desktops are still a RedHat, Novell and Sun business. And this particular issue is quite aligned with the kind of problems those deployments have.
    .rpm and .debs are solutions for a different problem, read the next comment response.
    A user should be able to install applications for personal use, allowing every single user to install any .rpm/.deb files is not a sane policy. It might end up breaking the whole system for a whole environment.
    Applications should be self contained, and its installation should not interfere with the normal operation of the system.
    Multiuser environments should allow users to have applications within their home directory without affecting the integrity entire system.
    Only developers that want to be mainstream or that want to deploy a platform components ought to be shared by many others or installed by default should care about .rpm/.deb/.ebuild packaging.


  10. A good first step would be to standardize package names. For example, the package with Poppler headers is libpopper-dev on Debian/Ubuntu and poppler-dev (maybe capitalized) on Fedora. We need to pick one of these naming schemes and stick with it. I’m sure Fedora can use virtual packages or something to support this without breaking things. This way, an application’s dependencies can be specified in a distribution-neutral way. Then, we need a standard way to describe a package and standard actions to perform on installation and removal. This, combined with adherence to and support for the LSB, should make it easy to package any software for the mainstream distributions.


  11. I tend to agree. Especially the lack of ‘proper’ documentation is devastating. As for the tools; ‘quickly’ seems to be something to keep an eye on, it seems to me somewhat like rails. It even makes packaging and publishing software easy.


  12. I like the klik approach – it seems quite similar to the mac way of doing things (single image).
    My question is then – can a distinction be made between user apps and system apps?
    I know you can install into /home/user but that seems really daft – it’s an app, it should be somewhere else and if someone else wants to install the app they shouldn’t need a duplicate in their own home.
    With regards to collecting and organising the documentation – I’d be happy to help but then the website doesn’t really have a good way of helping in this regard IMO.


  13. “1) Set a LSB standard with a minimum number of Gtk/Qt/Dbus and other freedesktop standards that are all set as API stable and people can count for in the next few years (a cycke for breackage could be set).”
    The LSB already does this, doesn’t it?
    Its only weakness so far is that it is too focused on “Enterprise” distributions, so they only include versions that have already been shipped rather than what should be shipped in the next version.


  14. I agree with a lot of what you said. Personally, I think 0install is more interesting than klik. But both have a similar concept.
    Be nice if there was enough interest to see something like this take place. 🙂
    Speaking of separating user apps and system apps, PC-BSD already does this. You can install system apps using ports and packages, and user apps with their custom pbi system


  15. Perhaps package management is the problem, its solution being clean
    source trees that have been built on more than one distribution before release.
    Try a fresh installation of Fedora or Ubuntu or Debian and see how far you get compiling your own applications.
    For extra excitement, remove all binaries associated with the installed desktop environment and build its current tip-of-tree as a working environment.


  16. As a user, I understand the motivation behind the package management system, but I think it is too complicated for people to use. For example, when I wanted to have Firefox 3.5 installed in my Ubuntu system, it wasn’t so easy, because whatever version of Ubuntu I had installed did not have a package for it. I tried installing non-official packages, and ended up with problem with the icons on the menus, which only when away when I upgraded to Karmic.
    I also don’t want the installation/uninstallation nightmare that is Windows.
    I think the OSX system is pretty intuitive — I like that my software is self contained, and that I don’t have to worry about the package system. I am quite sure that something like 0install would go a long way to make Linux more accessible to the general population, but what I’d really like is something like the OSX package system (I am not sure how similar they are, as I just found out about 0install).


  17. As a user, the last thing I want is to have to mess around with a package management system. No one understands it. Even most developers have a poor understanding of how the system fits together and how to package the apps for it. As a developer, packaging should be a 1 click preocess. Spending days working on scripts fro an application that only took you 4 hours to write is bullshit.
    Linux is stagnating because the filesystem layout and old beard norms of administration are old and outdated.
    We need to move forward and come up with a better, easier and more user enjoyable way to install software. Enjoyable is the key word.
    People are always amazed at how Apple innovate but in truth, all they do is look at what people want and deliver the experience.
    My man point is that we shouldn’t do what we always have because that’s the way it is done. We must look at the desired outcome with fresh eyes.
    Open source gives us the flexibility to tear everything down and build it up that closed source just cant do.


  18. The Windows and MacOS X way of installing packages in much worse for a user than the Debian/Ubuntu way. There is simply no way to ‘leave behind our early 90’s development and distribution style’.
    The situation is exactly opposite – while our development and distribution style is lightyears ahead of *.exe files on a website, we should consider a way to provide a legacy interface for those commercial developers that are still stuck in that 90s style of developement and distribuit that is just puttil *.exe or *.msi on a website.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s