Free Software: the road to a Universal bundle, a powerful app store, and world domination

Short URL:


Apple is doing it again: they are releasing an app store for OS X on the 6th of January. Just like the iPhone app store, and the Android app store, this is going to be a hit: the OS X ecosystem will get a giant boost from it, and we are left -- once again -- with a lot to learn. Before you mention that GNU/Linux doesn't need an app store because it's free software, and before you even say that GNU/Linux already has an app store through one of the many software managers (Synaptics, Ubuntu Software Center, apt-get), please read this article.

The technology behind an app store

I am going to sound like a broken record to those readers who are unlucky enough to have read my editorials over the last few years. To keep things simple, I will make this a point list. Please note that by "application" here I mean a user-oriented, GUI application (think of Chrome, OpenOffice, Pidgin, Rhythmbox, Gnutella, and so on).

Here are the requirements -- and technical solutions -- for a GNU/Linux app store.

  • Self-contained applications. This means that an "application" needs to be a self-containing folder with libraries, icons, etc. "Installation" must mean "copying the folder over", and needs to be possible on a per-user base. At the moment: in GNU/Linux an application will spread itself all over your disk, making it impossible to have per-user installations and making it impossible to just copy an app over. What an app store needs: Every user on the system must be able to have their own apps installed, independently from other users, and needs to be able to copy it "as is" so that it works on a removable media, or on another users' computer.

  • Apps need to work in every complying distribution. This means that there must be an established subset of libraries that every complying distribution will have to provide. (Yes, both KDE and GNOME libraries would need to be present) Applications will be able to expect that subset, and will need to be statically linked to the extra libraries they need in order to work. At the moment: Each distribution has a set of libraries, and each application needs to be compiled on a specific distribution in order to work. What an app store needs: Every app needs to work on every complying GNU/Linux distribution.

  • Apps need to warn the user if they need updating, and they need to be able to be registered to open specific file types. Basically, this means that every application is registered on a per-user basis. At the moment: generally speaking, in GNU/Linux, applications are installed by a package manager (RPM o DPKG) which will deal with upgrades, while the user interface (Gnome or KDE) decides what application to run for specific file types. What an app store needs: a GNU/Linux app store will need an update mechanism that is not distro specific, and a way to associate self-contained applications to a file type.

  • It needs to be possible to rate apps in a central database and it needs to be possible to forward one to all of your friends. This would make it possible to have "viral" apps, and it would help create something that is missing in GNU/Linux now: an app culture. At the moment: users need to actively go and look for applications, and all sorts of non-graphical applications will pop up in most searches. What an app store needs: the ability to share information about an app, in a centralised way: votes, comments, suggesting an app to your friends, etc. Focus on GUI applications.

  • It needs to be possible to make apps that will run on different CPUs. I am not advocating something impossible: basically, the package would contain several directories, one for each CPU. It will be up to the packager to support several CPUs (if possible). Initially, this could be just a "theory" -- and get started with Intel CPUs. At the moment: the multi-CPU issue is pretty complicated, if not impossible to solve, with today's package management. What an app store needs: the ability to have self-contained applications that will work on several CPUs.

The application developers themselves should be responsible of creating the binaries for their applications; distributions should facilitate the process by providing ready-to-go build environments.

The technical side is something that should be taken for granted. GNU/Linux's fragmentation made such a technical scenario impossible -- at least for now. Major end-user distributions would have to agree on a set of libraries, as well as a common way to find out an app's version. They would also get their hands dirty together to develop a cross-distribution system to register the installed apps, and update them. Such communication between distributions might be impossible. As a result, distributions might end up sticking with what they have, and go their own way -- ending up with half-baked app stores.

Just to make it clear: the current way of installing software in GNU/Linux distro is not going to make a good app store possible. Having a nice interface to deal with a million dependencies behind the scenes" is like putting lipstick on a pig. The limitations imposed by the current "spread the app across the filesystem" are too far-fetching. In the GNU/Linux eco-system, having a distro-dependent app store means further fragmentation and less adoption. Having only system-wide installation implies that every user needs to be an administrator to install apps.

The economics behind an app store

This is the nice part of the article. Having a cross-distribution (or even cross-CPU) app store, where applications work regardless of what distro they are installed, opens up a world of opportunities.

Imagine this scenario:

  • You look for a GPL app, and find it. You download it, and start using it. It's free. However, a window pops up: it tells you that the author would love you to fund $1.5/year for its development. You can say "yes", "no, never", o "remind me next month". If you say "yes", you will help fund that application

  • You could have a system-wide setting, where you allocate $5/month to every application installed. The system would then monitor which ones you use the most, and partition those $5 amongst the apps you use. You should also be able to have a list of registered applications, and enlist the ones you want to share your monthly donation to.

  • Distro could be responsible of managing payments, and take a small (declared) cut for each payment. Distributions would then be in touch with the developers, and remit funds to them

  • Really popular applications would receive a lot of funding. However, the critical mass here is the real deal: with millions of GNU/Linux users out there, it becomes possible to write an application that has say 50000 users, and therefore receives $75000/year from its users.

All this is possible primarily because there are now millions of GNU/Linux users who rely on free software. Amongst them, there is a small percentage who would be willing to give back some money if they had an easy, fast way of doing so. 0.1% of millions is still a very big number. To me, this is a potential that is being left completely unexploited.

This is only a dream now. Could it become reality?

Could this little dream of mine become reality? I definitely hope so. The most concerning part is that it could also go horribly wrong, with distros implementing pseudo-stores and missing the real point: the cross-distro, user-specific, self-contained nature of such a setup. This kind of applications would work well on GNU/Linux desktops as well as tablets. Android's market us thriving. the iPhone market is thriving. It's a model that works, and that should to be copied. But, a bunch of people "up there" need to get together, and decide to give up some of the control they have.



chrys's picture
Submitted by chrys on

Although I downvoted this article (by mistake of course!) I totally agree with your ideas Tony. However, can you be more specific about the people or companies that can implement this idea?

admin's picture
Submitted by admin on


I am putting together some more specific research about this project.
I will let everybody know as soon as I have some more info...


begemot's picture
Submitted by begemot on

You mentioned static linking, which is the worst thing ever invented on computers.

Some of the other things in the article are already being worked on.

Seems like a generally misinformed article to me.

More comments here:

admin's picture
Submitted by admin on


(Grumpy hat on)

Please back your comments, especially if you call the article "stupid".
I didn't mention static linking. I mentioned the fact that any "uncommon" library should be available with the app, and it should be used IF it's not available in the system.

Please mention _where_ the other issues are being worked on -- maybe you mean LSB, which doesn't cover 10% of what I talked about.

Please also point out which parts of the article are misinformed -- especially if you call it "stupid".



Terry Hancock's picture

"Every complying distribution". :-D

I think a real response is going to require a full post, but as long as you're okay with excluding "non-compliant" distributions, your description is very nearly met by any of the major binary package distributions.

The "app store" environment, in fact, sounds very much like Linspire's CNR, which was basically just an extension of what GUI APT tools like Synaptic provide. The "Ubuntu Software Center" retains some of these concepts.

The differences get down to pretty fine engineering choices, and I'm not convinced that switching to a single-directory/per-user model would really help with the dependency and compatibility problems.

admin's picture
Submitted by admin on


Terry, I really think that this goes _way_ beyond an engineering issue. It's a philosophical issue more than anything else. The limitations that are a clear consequence of the current "package management" system are too far-reaching (I listed them in the article). And no, they cannot be fixed. Per-user installation, root password requirement, multi-architecture, etc. (see the article for the details :D )

My idea does not involve pigs and lipstick. It involves a clear design and a neat way of doing something.



Ryan Cartwright's picture

I'm not convinced by this idea. For one, splitting "GUI user" apps into an app-store while I presume leaving server apps to be managed by apt-get or whatever seems a little fraught with danger to me. It sounds good on paper/screen but in practice things are not that clear cut. I run a couple of development machines which have both GUI user apps and server apps on them. Managing such a machine becomes fragmented and troublesome in the environment you suggest. Yes that's my lookout but I choose my distro carefully depending upon the machine and I think a lot of other people do as well.

Secondly who manages the app-store. Implied within your idea is the concept that the end-user will expect any application they get from the app-store to "just work" once it is installed. So who determines whether and when applications are fit for release? In the case of the OSX store that will be Apple (and we've seen the problems associated with that). For Android that is Google (again with associated issues - witness Creative's attempts to get their tablet approved to use the store). So who manages the free software app-store? Who decides whether an app is ready and how they are categorised? Right now these decisions are made by distributions and the criteria differs greatly. Ask the users of Debian, Mint and gNewSense if they can come to a common consensus.

This is an interesting concept but I think that is all it can and should be. As Terry appears to be suggesting the real problem with any idea like this will be getting distribution buy-in. Not just the popular ones but the smaller ones as well.

Equitas IT Solutions - fairness, quality, freedom

Gary Richmond's picture

Regardless of your article and the comments on it, I just like to cheer you all up with a link to a review of Apple's App Store for Mac OS X on Lifehacker:

It's an absolutely scathing review. It couldn't be worse and regardless of how any GNU/Linux app store would be implemented it would not be hobbled by the restrictions listed in the article. Whatever else Apple have done right with the iPad seems not to have been replicated in their new Mac OS X app store.

Toshiba will be bringing out their own (bigger) version of the iPad later this year, featuring Honeycomb (Android 3) customised especially for tablets. That, in my opinion will be where free and open apps come into their own rather than on conventional distros on desktops and laptops.

Ryan Cartwright's picture

My experience tells me it is not well received by Mac users either. Several of the ones I know (particularly the experienced Mac users) have been moaning about it since its launch. Complaints include from applications not being available, lack of a clear way to upgrade applications and slow speed. These are not scientific research nor my experience (never touched a mac, never want to), they're just hearsay.

Equitas IT Solutions - fairness, quality, freedom

Ryan Cartwright's picture

Whilst Apple are not known for reverting their stance, VLC is such a popular app that I'd be surprised if they don't revert this decision if enough users complain (or enough with the money to back it up).

This does highlight another downside to app-store's though: control. As I said above somebody needs to manage an app-store - even one for free software. Whilst a free software "store" would not be run along the same lines, this incident highlights the issues with such a service. If you are a dictator like Apple then you can do what you want (as long as you sell it as a benefit). if you are running a community service then you can't and pretty soon you'll end with death-by-committee.

Equitas IT Solutions - fairness, quality, freedom

openuniverse's picture

well, at least we know how an app store works now. but let's get something straight, we don't have "so much to learn" from app stores, we have so much to teach them about respecting users and choices. so let's reserve the phrase "world domination" for people cheating and imposing themselves, not for advocates of user-empowerment ok? no one should be "dominating" anything.

success is another matter, i'm all for it. before you put too much stock in a system like the one you're describing, have a look at it should give you an idea of how much such a system will actually be embraced.

for every .deb package and arch tarball, how many programs out there with no standard way to install on any distro? how will those things fit into the app store? let's call it what it is then: not a radical new package management system worthy of designing most mainstream distros around, but an advertising system based on the illusion of choice, like american idol or x factor.

once we're less enchanted with the magic that the app store doesn't really bring to the table, we can still talk about looser, less top-down ways to implement one for fun. yeah, domination is top-down, and free software (by definition) isn't.

i would not be averse to a "universal repo," even though it wouldn't be universal. it would be the opposite of GLFS, it would be a repo, with sourcecode, pre-compiled binaries for everything in it, and i suppose then it would have to have some kind of "universal kernel." the kernel wouldn't be optimized, except for two or three cpu types, and all the other binaries would have to support it too. from this repo you could build all kinds of distros, really build your own. you could setup your "app store" using the same repo. it could be funded and maintained kind of like wikipedia is. but nag windows, tony? really? i think we can skip that kind of promotion. we haven't all moved our brains to the cloud yet.

Author information

Tony Mobily's picture


Tony is the founder and the Editor In Chief of Free Software Magazine