Warning: long post. All lazy readers must hide now.

In my original post about the practicality of open source business models, I talked about the differences in Kaizen and Kakushin, how they were used, their benefits and disadvantages, and how each could be used to our benefit. In this post, I have decided to go a bit back into basics, take a broader look at things, and actually consider the nature of open-source compared to other models. I left the ending of the last post asking several questions – I will not answer those questions right now, but hopefully the stuff I consider in this post should help understand what solutions are practical and what aren’t.

Let’s start by considering the nature of Linux – the largest open-source project around (technically not, but you get the idea). Linux is essentially a free market economy, whereas Microsoft is more of a planned economy. For those familiar with the advantages, disadvantages and features of each economy, that sentence should summarise a lot of Linux’s culture. However, I believe analysis based on the type of economic system Linux represents, though interesting, has very little realistic value. It’s much more useful to look at Linux from a smaller perspective. Let’s begin.

The Linux community is extremely modular. Imagine a Lego set – there are hundreds of different types of pieces, and new ones come out all the time, the old ones are still there, but over time get lost, don’t fit so well, or get broken. A user has the image of a perfect creation in their minds, and are thrust upon them a huge mess of Lego pieces, with nobody to guide them on how they fit together. Here’s a graphical representation (no, I don’t care if I made an inaccuracy ):

That, is Linux from Scratch (again, please don’t try and be a smartass here). You build your entire system yourself. There are manuals, but no common Joe is going to bother. Hence we have distributions.  Distributions try to package these Lego bits together, giving you 1) An easier starting point, 2) Easier/faster to get the pieces you need (using the package manager), and 3) a small community which can provide support. There are varying levels of these distributions, such as Gentoo, which still believes in the build-it-yourself philosophy (quite literally! You compile everything!), to Ubuntu, which tends to stick a silver spoon in your mouth.

If you read the first article, you might have noticed that this is actually a very effective use of market segmentation, allowing the average user to enjoy things like Ubuntu, whilst allowing for more hardcore users to push ahead development. It seems as though we’ve already got what it takes – but why doesn’t it work?

Firstly, people are not used to the open-source culture. And it just so happens that the open-source culture is the only culture that gives this sort of choice to “the average user”. The only other place this sort of freedom occurs is in technical industries, aimed at skilled users. Because people aren’t expecting this sort of treatment, they don’t choose this sort of treatment, instead they choose what they’re used to, which are self-packaged monolithic projects. Let’s look at Microsoft’s Windows. Here is a graphical representation:

It’s basically a finished Lego structure, superglued together with a couple bare spots for add-ons.

Looking at Microsoft’s success, does this mean we should get the glue and start merging projects? There are two issues to look at here, 1) Is it really beneficial? and 2) how practical is it?

Competition is beneficial to developers, but what about our users?

Let’s start with how beneficial it is. Due to the large amounts of projects, we get a huge amount of competition. Competition is healthy – it keeps the developers on their toes, always pushing ahead what is expected of them, it increases quality, it increases efficiency of production, and finally also increases the quantity produced. Competition would probably be the child of Linux, and it’s being abused every day. Even though we have competition implemented to breakneck levels, we also have created a hugely confusing world for newcomers who don’t know what’s new and what’s recommended.

Let’s say the TV market had a huge amount of competition and I wanted to buy a TV. If I knew nothing about TVs, I would be at a loss as to what to choose. In this case, I would find a shop assistant (no matter how crappy they really are) to help me. The TV market will not stop its own competition just to stop making it confusing for me, instead, they will simply employ more shop assistants.  Similarly, we should not bring out the glue and stick our projects together.  The interesting point this raises here, is do we have any shop assistants?

Yes, we do have shop assistants. In fact, we have some of the most knowledgeable shop assistants in the world, and they work 24/7. We have shop assistants that practice the beneficial concept of dogfooding (using their own products – thus duplicating the roles of a user and a developer, leading to more useful upgrades), that are constantly being trained, that don’t charge a single cent for their services, are self-motivated, and best of all, treat you as a friend (unless you are an idiot – no joking about this one).

The problem lies with the fact that newcomers have absolutely no idea where to find these shop assistants. That’s because they all lurk in IRC Chat – a system brought about by tech users, maintained by tech users, and not at all bothered to be advertised to the average joe – mainly because the average joe is an idiot to the tech users. This is actually a very serious issue – the amount of patience a lot of the developers have once they meet an idiot in IRC drops tremendously. We can’t blame them, everybody has better things to do. In fact, one of the sad truths is that if the IRC channel identifies an idiot who seems to be disrupting the flow of the channel, instead of being helpful, they will actually take it upon themselves to insult the person, start using inside jokes, and in the end be quite mean to the person. People who use IRC quite a lot can recognise this and know when to shut up, but for newcomers, not only do we stop providing support, we actually repel them from our product. We have thick skins – “You don’t like it? Go away. You won’t use our product? OK, who cares.”

Excessive competition has actually brought about specialisation in the workforce – good or bad?

Right, back to the “is it beneficial” question. Another thing to consider is that what Linux is actually pure specialisation and division of labour. The reason competition has brought about specialisation is because 1) we have the open-source philosophy of “one tool per job”, 2) We have a billion tools for a million jobs, and 3) Our developers work on whatever they like. The developers will choose what they like, or what they are good at. Not only does this make the work on what they’re good at, because they enjoy doing what they do, this is a form of self-motivation. Specialisation is meant to increase efficiency, increase quality and quantity produced. These are all benefits.

The disadvantages of specialisation, which are mainly boredom and immobility of labour are also removed, as when the developers get bored, they simply leave and work on something else. There are no obligations to stay, and no managers to get annoyed at them. Developers, also due to their nature of shifting around a variety of projects also pick up a huge variety of skills – meaning that labour is quite flexible. Thus immobility of labour is removed. If a good developer leaves, there will always be somebody with the capabilities to replace the person – true, the rate of development might still decrease, but the project will still survive (unless the project is doomed due to competition or just an extreme lack of developers).

Strangely, even though it seems to be a very one sided argument saying that open-source’s modular construction is beneficial, Microsoft is still (decently) ahead of us. The reasons are obvious – they have backings of lots of other financially structured companies, and it’s this financial backing which causes a lot of the influence around nowadays. A lost cause, then, for Linux, eh? Not really, there are a lot of financially structured companies going for Linux, such as Sun Microsystems, Oracle (which recently bought over Sun), Google, Nokia (yes, Linux is the most secretive monopoly of the mobile phone market – your phone probably runs Linux), etc. And in these economically pressing times, the chances are that Linux will get even more companies running for them. The idea of having backing from financially-structured firms will be very important when I consider the practicality of implementing these ideas in a future article.  This brings us to the practicality of merging out projects together.

How practical is it to actually merge our projects together?

Short answer – impossible. That will be the equivalent of asking America to turn into a communist country. In fact, it’s easier to cause a derogatory schism in the form of resource-wasting project forks. Keeping that in mind, we can say this:

Competition is good, but if applied excessively it can actually waste resources, being a disadvantage to both consumers and the workforce, and hinder development.

As mentioned countless times before, the open-source business model is no longer a business model – it is a culture. Just like any civilisation, we need a government. However, since we’re so good at having different views, I suggest:

We should have a government like Belgium.

Belgium is probably one of the most screwed up countries (sorry – no offence) in terms of governments. There is the Federal Government, the Flemish Government, The Government of the French Community, Government of the German-Speaking Community, Government of the Walloon Region, and the Government of the Brussels-Capital Region. Going to the Belgian embassy? Which one? Haha.

Oh, and we do have a government(s) like Belgium. Except we have too many.  They also seem to be limited to governing a single project. Those, my good sir, are not governments, those are influential boards of directors. A government, in my opinion, is the noble FreeDesktop Project. The FreeDesktop aims to standardize development within the plethora of desktop environments and window managers. For those unaffiliated these terms, suffice to say they are user interfaces that a user can pick. There are a lot of them (ooh, a list! XFCE, GNOME, KDE, LXDE, Rox, Fluxbox, Blackbox, IceWM, Ratpoison, Ion, Openbox, and so on). If you had a hundred different interfaces all following their own rules (and using their own toolkits even – thank goodness they don’t), nothing will look integrated, and this will give a bad user experience. The FreeDesktop project realised that, and decided to come along and try to put things in order.  They didn’t actually interfere with development, but acted as a sort of mediator for agreeing on standards. Another type of government would be the Linux Foundation, responsible for representing Linux in legal issues (yeah, a bit hard to sue otherwise).

But alas, talking about governing our legal and marketing issues is to be saved for another post. At the moment I am talking about competition and the nature of the open-source culture. So what I suggest is that we have more mediators like the FreeDesktop project to govern development. These will be grouped by project type – such as Desktop Environments, Linux Distributions, or Kernel Development.  Unfortunately, as I’m not a developer, I cannot say which groups would be the most effective, so that is where you, the community, come in.

These government bodies will have the responsibility of deciding standards and taking major decisions on which technologies will be brought forward. One example of when this would be useful is the recent controversy between Webkit and KHTML. Perhaps if this were decided users won’t have to choose between so many browsers (I’m not saying only a couple of them aren’t crap – choice is always good!). Another function of these government bodies will be to decide when technologies can be shared. One great example is KDE creating all these behind-the-scenes systems for audio and semantic desktops. These resources can be shared within other desktop projects, such as GNOME. (eg: Phonon can be used by GNOME too).

Overall, these government bodies will have one function – to reverse the effects of competition when deemed necessary. Or as a spin doctor would put it: to act as a mediator to allow synergy between projects.

IN A NUTSHELL.

As examined in the beginning, we saw the modular nature of Linux. We also saw how the user was unused to this concept, and then moved on to seeing how this competition can actually be harmful to development. I also deviated for a short while to consider the structure of our support system, which seems very well hidden We then considered how financially-structured organisations have much more influence than a hundred smaller projects, and finally I propose to have these government bodies to tackle the fact that:

Competition in the short term is good, but in the long-term, what we need is synergy.

Well, that’s about it for this post. I apologise for the lack of fun diagrams, and hope that I touched upon a simple idea that should be implemented. I left a lot of points open for discussion in the text above, and I hope to use that in a future post, meanwhile, I can only hope it serves to bring about other beneficial ideas about the open-source culture. Thanks for reading, the support I got in IRC, and I hope one day these posts will become more than just a post (is that even grammatically correct?).