Note, this is a long post. It also covers a tiny fraction of what is out there to understand. More updates will come about the open-source culture in the future. This text is also mainly written for those familiar with the Linux culture (as I use them as an analogy) – though regular business model analysts are welcome to share their ideas too.

Recently I’ve been analysing quite a bit of the open-source business model and its practicality to actually be introduced into commercial industries. A lot of this was analysed by looking at Linux and smaller Linux-related activities (eg: individual distributions or desktop projects like GNOME and KDE) as an analogy.  So when I talk about Linux, I can be referring to any Linux or open-source project, be it KDE, GNOME, Ubuntu, Gentoo, etc. One of the topics I covered in my analysis was the concept of Kaizen and Kakushin. Seeing that recently Aaron Seigo posted an article related to it and the flaws with its methodology, I decided to have my own say.

Although my analysis covered a lot more than Kaizen and Kakushin, I decided to start with those as they were introduced by another (more influential) blogger and I think it’s good to follow up on his ideas. Aaron Seigo probably has the benefits of actually working in an open-source culture, whereas since I am not a developer in a major project (or even any public ones) I probably can say I do not have the same level of personal experience. Therefore let’s just say my ideas are a lot more generalised, and looks at things from the broader picture, encompassing the users and the developers and comparing the two.

Let’s start with Kakushin. For those who are unaffiliated with this term or haven’t read Aaron’s post, it is when leaps are taken in the progress of development. What happens as that over time, the business would set a new quality standard and everybody will be trained to practice this new standard.  This may be done through many methods, such as a work study. This concept is a manager driven approach, as the manager’s job is to view the “big picture” around this organisation, and decide what the next benchmark will be. Though there are obvious disadvantages, such as the distance between the manager and the project (which may cause misinformed decisions on benchmarking), this technique is the most common in the industries. One example of this is Apple and Microsoft. They release a big version every so often with massive updates, led by managers decision on what the business’ vision is. One visionary would be Steve Jobs from Apple.

If we plot a graph of quality over time, we can see this sort of relationship.

However, Linux seems to follow a different sort of model. The Japanese have come up with the Kaizen model of quality management, also known as “continuous improvement”. This quality management model is workforce driven. Individual workers are self motivated to continually improving every single process existing within the business, be it production, manufacture, services, or even management and administration. This can therefore not be labeled a model, but instead a philosophy. In the case of Linux, our workforce are our developers, each creating features not because they believe it is for the best. The difference with this model when we plot the quality-time graph can be seen below.

Now people who have studied these two concepts before would know that if the graphs are combined, the area, and hence “benefit” of each concept, of the Kaizen model is greater than the Kakushin model. This can be shown mathematically, but here is a graph to explain it clearer.

Therefore, theoretically the Kaizen model should be a lot more successful in terms of the business (or in this case the open-source community). However, as we all can see, Microsoft and Apple seem light years ahead (seriously, look at the average Joe’s idea of an OS) compared to Linux, who seems to be turtling along. Why is this so?

Let’s take a look at Linux’s and open-source’s philosophy. There are quite a lot of theories, and one of them is ‘release early, release often‘. This works very well with version control, and allows a lot of developers to work together without compatibility issues. It is this theory that forms the basis of Linux’s Kaizen approach. It is also obvious that a Kakushin approach to development is ridiculously impractical. People turning up with patches of hundreds of lines of code at a time would lead to a lot of disorganisation, and progress would be hindered. Therefore, it can be said that Kaizen is the most effective for developers.

However, why does Microsoft and Apple succeed with their apparently Kakushin approaches? This is because Kakushin is applied to their marketing strategy, not their developing strategy. This difference between development and marketing is rarely identified in the open-source culture, and is one of open-source’s major flaws. Microsoft and Apple’s developers work in a similar version controlled system, no matter how monolithic the project they are working on. However, to the user, we do not experience the Kaizen that the developers do, instead we experience Kakushin.

Even though we previously theoretically disproved Kakushin’s effectiveness of Kaizen, there are factors which prove this theoretical approach false. The two factors are what I like to call “change rewarding“, and “resistance to change“.

Let’s start with “change rewarding“. When Microsoft releases their new version of Windows, Microsoft’s marketers know that there is going to be a lot of change that the user must experience. In order to cancel out the “resistance to change“ factor, they combat it by creating buzz and excitement about the release. This makes the user more accepting for what they are about to experience. Microsoft also looks at things from a user’s point of view, knowing that interface and fancy eyecandy are one of the things that actually gets noticed, and so therefore tries to put this into every new release. Therefore when users finally check out the product, they experience the “wow” factor, and they love the upgrades. They feel as though it’s new, improved, and they embrace the change. Take this for an example. Let’s say we are developing your average application. A month later, you release a new version, but you only change the splash image. Nothing else. The first impression on the user will be a positive one (unless you choose a crap splash image) – they will embrace the change and expect big things. This is how Microsoft’s Kakushin approach is effective. (Note: I am not saying Microsoft executed it pretty well – for example their release of Windows 7 beta was a huge failure)

However, I’m not saying it’s all good. I’m not saying we should stuff eyecandy and make useless interface changes just to give the illusion that things have improved. Here is where the “resistance to change” factor comes into play.  Change too much and your users will hate you. Take a look at KDE, Amarok, or Vista. (Let us for the moment disregard the fact that sometimes these are required for innovation and survival of the project – more on this will be covered in the future). In fact, I recently read an article where US businesses were starting to say that when Windows 7 came out, they would not switch their systems. This is because they were worried about compatibility. This is very understandable, and shows one of the disadvantages of the Kakushin concept.

Of course, Kaizen isn’t perfect either. For example, Kaizen needs variations in its curve. Even though Kaizen seems to work forever in a culture (such as Linux), Kaizen is not self-sustainable within a single project. Incremental upgrades all the time with no big successful release is demoralising to the workforce (our developers – [one of] our most important assets). Imagine if you never tagged a release version in the version control? Well, this is what we result in.

Of course, this can be eliminated through effective developer sprints – also known as a Kaizen blitz according to Aaron. Variations should be introduced.  One example of a project that needs this (please, no offense) is GNOME. Google does this extremely well in its Google Summer of Code projects, and I know this is also done in KDE (such as Kamp KDE and so on), and this sort of activity should no longer be considered an every-so-often event of the developers, but a required part of the open-source business model in order to succeed.

This (highly summarised – sorry, but it is a blog post after all) analysis does not say Kakushin or Kaizen is better. What it does say is that they both have their benefits, and can be each be effectively utilised – what matters is the manner in which they are both combined. It can therefore be said that open-source businesses, or in this case, we are beginning to see the emergence of a culture of open source, should recognise users needs and developers needs.  We don’t just need hackers – we need artists, business orientated people, marketers, multimedia specialists, people who understand management and delegation. I believe this was also recently stressed on another blog post in Planet KDE.

In order to bring Kaizen and Kakushin to a practical business model – or culture, which I shall now refer to it as, we need to understand people’s needs.  Developers in the open-source model are workforce driven – they don’t need a manager. The Kaizen approach is effective for them. However, the users (not all users! Please do not be mistaken) need to experience the “wow” factor more than ever. However, we should obviously not overload them with changes, which brings me to my next section.

Users are a whole different ball game that most developers don’t understand.  Proof that you (no matter how wonderful you all are ) don’t understand is that Linux is still highly considered a geeky or techies’ system by the average Joe.  You can’t argue with that. Because the developers don’t understand it, they just decide to impose their own ideas on users, and if they don’t like it, get out.  There are advantages to this ideology – for example, it keeps out idiots which may hinder development (wow, that was blunt!). However the developers need to understand that we actually can accommodate these idiots whilst not hindering development!

Allow me to explain. There are many levels of users. Some may be power users who dream in code, and some might be your grandmother down the street. Therefore what we can do is segment our market (users) based on their tech savvyness. I use Gentoo myself, and I have seen this segmentation employed in the form of Portage overlays. This may be compared to as Debian unstable, and developer releases of Ubuntu. What this does is allow average users to enjoy the stable system and experience the “wow” factor, whilst it allows more technically literate people to enjoy the Kaizen incremental improvement, staying more bleeding edge. It seems that knowledge/interest of the industry is proportional to the persons preference of Kaizen over Kakushin. This, of course, ties in very well with the open-source philosophy of choice.

If you’ve understood much of what I’ve written, you would have realised that what I am suggesting is that segment the market further, but at the same time blend in the change from Kakushin to Kaizen based on the users’ choice and preferences. Users must be given the knowledge that they have a choice, and hence freedom of what they want to experience, how they want to experience, and when they want to experience it. The benefits of this can be seen in the graph below.

As can be seen, the wow factor is increased (higher jumps in Kakushin), and due to the increased blend in change from Kakushin to Kaizen for developers, as this makes it easier for developers to contribute to the project, this will also accelerate development, resulting in a higher gradient. This shows a wonderful benefit for both users and developers. (and of course, like Aaron mentioned, there’s nothing wrong with developer sprints!)

Of course, there are a couple quirks still to be worked out, and since this blog post is…well, a blog post, I shall probably save these for future posts.  However, for those interested, here are the quirks.

1. To what extent should the “wow” factor be increased until we encounter a “resistance to change”?
2. How do we apply this concept? It is impractical to suddenly lump a bunch of managers into a highly technical industry and ask them to create this difference in change. (I shall cover a proposed method to introduce this changes in a later blog post)
3. How do we communicate this choice of how “into” the project they become to the users? How will they know which “level of complexity” is appropriate for them?
4. The open-source culture is very modular, how do we enforce uniformity between all the different projects? Each have their own development cycle, and how do we ensure compatibility is continued? (Imagine is all of a sudden KDE 5 was introduced, and all the people who ported their applications to KDE 4 had to re-port everything – they would hate it!)
5. To what extent should we segment our market before it gets too confusing? (For both developers and users)
6. and finally, how economical is it for this change to happen?

I thank you for taking the time to read this post, and I hope you have feedback, as I believe over the course of these posts which I plan to talk more about my ideas about the open-source culture there are actual practical solutions which can be put into place. For example, the Linux Foundation for a start.

I hope you enjoyed reading it!

Edit: I want two things to be understood. 1) There is plenty more stuff to consider and cover- which I will likely release in future blog posts, and 2) It isn’t that our Kaizen system is bad, it’s just that there is a whole market segment of users who do not appreciate the Kaizen approach (just if you like it doesn’t mean everybody else does too – it’s all about choice!) – it’s just not suitable for them (like your grandma, perhaps).