Synching the open source release schedule

Introduction

Both Mark Shuttleworth and myself have discussed this idea before. Because Mark brought it up again in a recent interview, I feel compelled to developer this idea further.

The main concept is that Linux distributions, and open source in general, have a lot to gain by synchronizing their release schedules.

Positive impact on the image of open source

Can you imagine the news articles that would be written if Ubuntu, Fedora, and OpenSuse all released a new version on the same day? Every six months, the world would see that open source has successfully delivered a new version on schedule. Mark Shuttleworth made a great point when he stated:

"We know when the next LTS will be probably with better confidence than we know when Windows 7 will ship. I would take that bet."

Once the distro releases become synchronized, it would create a huge incentive for upstream projects to synchronize on the same schedule.

Currently, we have upstream releases happening all over the calendar. For example, the newest version of Ubuntu includes a beta version of Firefox 3. It also includes OpenOffice 2.4, which is soon to be replaced by OpenOffice 3.0. With the power of a synchronized release, these upstream projects would work hard to get their newest versions into the distributions so that their users can start using the code sooner.

Creates efficiencies in software development

Open source is a very unique software development model, in that the code is freely shared between anyone who wants to work on it. This usually leads to great productivity from the worldwide development team that is formed.

However, there are some friction points in this model. Specifically, this friction happens when Linux distributions are working on different versions of an open source application at the same time. Mark addressed this point in his interview:

"Timing your releases drives a whole bunch of things. It means a greater ability to collaborate on bug fixes. If we are on the same versions of the Linux kernel, it is a lot easier for us to say, 'Hey, here is this patch to make this device work. Do you know any reason why we shouldn't put it in?'

You could just get so much more done at an engineering level between the teams. My engineers regularly collaborate with Novell and Red Hat and, of course, Debian. Barriers to that sort of collaboration are sometimes ideological but, in most cases, are just practical things. We are just on a different version so someone else's patch isn't going to apply. There's a bit of friction there."

How do we accomplish this?

I agree with Mark's short answer to this question. Simply set a hard date and modify your goals to make that release date. That greatly oversimplifies things, but it demonstrates that the long-term benefits of a regular release schedule greatly outweigh any negatives caused by postponing a feature into the next release.

In reality, there are a number of questions that need to be answered before this can happen.

1. On what date will the releases happen? Does it have to follow the current Ubuntu schedule of releasing every April and October?

Mark answered this question in his interview:

"We would be quite willing to revisit the elements of our release schedule in order to make that synchronicity possible, if the fact that we happen to do April and October wouldn't work for the majority of the distros. We would be flexible in that regard."

2. What amount of time should there be between regular releases?

Periodic releases every six months has worked very well for Ubuntu, but not all distributions are currently following that schedule. Six months also works great from a marketing perspective, because the release would always happen in the same months every year. Lastly, the open source motto is to "release early, release often". Six months is an attainable goal that balances the need for incorporating new features with the need for stability and quality assurance.

Call for civility

I understand that a post like this could lead to a distro war in the comment section. Please keep your comments civil and always show respect for other people's ideas. Hopefully, we can come up with some great ideas on how to improve open source software!

Win the desktop, and you will win the server

Or, "Why Red Hat is pursuing the wrong business strategy"

Red Hat has recently announced that they have "No plans for a traditional consumer desktop". Let me explain why I think Red Hat needs to change their business strategy.

First, a short history lesson. Before the arrival of Windows NT Server, Novell Netware claimed 90% of the market for PC based servers. However, Netware made a near fatal mistake when they did not provide a GUI interface soon enough. This comes from the same Wikipedia page linked above:

While the design of NetWare 3.x and later involved a DOS partition to load NetWare server files, this feature became a liability as new users preferred the Windows graphical interface to learning DOS commands necessary to build and control a NetWare server.

So server administrators became familiar with Windows 95 on their desktop, and they naturally preferred Windows NT 4.0 which included the same interface.

Challenged by Ubuntu

Red Hat is in a similar position to what Novell faced, in that Red Hat is facing a time when server administrators will choose to run their desktop operating system on their servers. Specifically, I believe that Ubuntu will soon become the de facto Linux desktop. This means that server administrators will become familiar with Ubuntu and develop a trust for the brand. Eventually, they may choose to migrate to an Ubuntu standard on servers and desktops.

Most people agree that the real money is in server operating systems. If Red Hat wants to keep capturing that server money, they must provide a supported, free desktop operating system as part of a loss leader strategy.

Fedora is great, but it doesn't solve this problem

Don't misunderstand me, I know that Fedora is an excellent piece of software, but it has two fundamental problems. First, most average computer users do not know that Fedora is sponsored by Red Hat. This means that the Red Hat brand is not directly benefiting from the popularity and success of Fedora.

Secondly, Red Hat does not provide any support for Fedora. This means that many business cannot seriously consider running it on their desktops. How will these business get support if a problem comes up? How will they know that their applications are certified to run on Fedora? What if they want long-term support for older versions, without having to upgrade all the time? All of these questions are being answered by the Ubuntu ecosystem.

Red Hat, let me give you a hint. (If you want more hints, I am always available for consulting). Here it is: Change the name of Fedora to "Red Hat Enterprise Desktop" and begin to sell support for it. If you are lucky, it may not be too late to capture a large percentage of the desktop operating system market.

Remove the need for CentOS

Red Hat, I will even give you one more hint for free. Why do let CentOS steal your thunder? You have already published 99.999% of CentOS (everything except the branding). You graciously publish the source code to RHEL to abide by the GPL, but then you let another brand take credit for your work. How can you fix this? Easy! Simply provide a free version of Red Hat Server that is compiled and ready to be installed. Now your users will see even more of RedHat. RedHat on their desktop, RedHat on their servers, and they can buy support for all of it if they so desire.

Most embarrasing meme ever...

What if this was your response to the command history meme?

$ history|awk '{a[$2]++ } END{for(i in a){print a[i] " " i}}'|sort -rn
2184 dir
1631 copy
560 edit
486 type
430 makedir
343 move
281 ipconfig
273 deltree
201 erase
164 format

And how come we never see a meme like this?

cat /etc/passwd;sudo cat /etc/shadow;netstat -plunt;ifconfig;sudo iptables -L

Note: Please do not post funny memes if they have destructive commands. The meme above will display private information about your system that should never be posted online.

Why do people make software for free?

When I first tell people about open source software, one of the most common questions I get is this:

"I just don't understand why people would create software if they don't get paid for it! How does that work?"

This question makes sense, because we all know that people need to make money to provide for their families. And every good capitalist knows that the profit incentive is what drives people to create and innovate. This is true for many industries, but it does not explain why open source software is created. Here is how I answer this question:

The birth of an open source project

Most open source software projects were created by a programmer who needed a piece of software to accomplish a certain task. Rather than purchasing a commercial software product (assuming that one existed), this programmer decided to create the software from scratch. This programmer might have been paid by their employer to create the software, or the work might have been done on personal time. Instead of hording the newly created software, the programmer decided to share it with the world by publishing it under an open source license.

The birth of an open source community

This is where the open source story gets interesting. It is likely that somewhere else in the world, a second programmer has a need for some software that provides the same functionality. Rather than starting from scratch, this second programmer discovers the open source project that was recently created. This second programmer uses the source code to add new features and fix some bugs that they found in the application. This second programmer then submits these improvements to the first programmer, who gladly accepts them and incorporates them into the original project.

This cycle continues as more and more people start using the software. Most people will simply use the software, but a small percentage will contribute to the project. These contributions will be made by programmers, documentation writers, translators, beta testers, artists, web administrators, and many other important roles.

The birth of an open source business

As the community of users grows into the thousands, the size of the community eventually reaches a critical mass. This happens when a need develops for a commercial entity to provide professional services related to the open source project. This need is driven by businesses who require a support contract before they will use open source software. The commercial open source company is driven by a profit motive, but their success is directly beneficial to the open source community.

The future of an open source project?

I hope this post explains how many open source projects were created, matured, and became supported by open source businesses. Not all open source projects followed this particular evolution, but I think it is the most common life-cycle for open source projects.

What does the future hold for open source? It is always hard to predict the future, but if you have been watching closely you will see that traditional software companies have been investing in or purchasing these commercial open source companies. This means that in the near future, your traditional software vendors will actually be developing open source software, and trying to implement a successful business model based on open source.