Modify Colors
Posts in shuttleworth
A Story About Nothing: Shuttleworth Says You Can't Make Money From the Linux Desktop
The sky is falling! Mark Shuttleworth, the same person who founded what is probably the most popular Linux distribution and has essentially been betting his time and money that desktop Linux can turn a profit, said today in an interview that “I don’t think anyone can make money from the Linux desktop.” Or did he…?
The answer is both yes and no. Yes, he probably did say the words, but no they don’t mean what you think they mean. A ComputerWorld article (not that I am criticizing ComputerWorld or the author, many places did it) on the interview gives some more details, under the eye-catching headline of “Ubuntu’s Shuttleworth: “I don’t think anyone can make money from the Linux desktop.”"
Apparently, Shuttleworth continued to explain his point. The critical part of the article is this:
The point is, Shuttleworth continued, “I’ve never seen selling shrink-wrapped packages of free software as a workable idea.” Instead, Shuttleworth sees “The only way to build business around software is with [added costs] services.”
This is an important distinction. Though this is probably not how Shuttleworth meant it, I, and apparently many others, first interpreted his quote to suggest that he had give up on Ubuntu ever making money. Instead, all he is saying is that you can’t make money by selling free software in a box. OK. I agree. That is nothing new, just a restatement of what he and others have said in the past.
As far as I can tell, the story that is being reported all over the place is a story about nothing. Like, most interviews with Shuttleworth, though, there is a lot of other interesting infromation in it.
And South Africans Are Going to Contribute To Windows?
Recently, Jason Matusow, a Microsoft employee, made the comment that “Deep dev of the core OS is not likely to happen in South Africa today on any large scale. Students at the university still grappling with coding skills are not going to dive into the inner-working of Linux.” Of course, as has already been pointed out, the statement holds no credibility due to South Africa being the birth place of someone named Mark Shuttleworth who happens to be the founder of Ubuntu.
If that is not, however, reason enough for you to discount Jason’s statements, consider this: a person from a company who is located primarily in the US and has basically all of their top management in the US is saying that South Africans will never be able to get involved with Linux, an open-source effort which has developers, leaders, art people, marketers, etc, etc everywhere in the world.
Microsoft, making fun of you is getting too easy.
Optional OSS Synchronization
Recently the issue of synchronizing open-source software releases has come up quite frequently. Stories are being written about it. Shuttleworth (founder of Ubuntu) has stated his opinion on the topic. Seigo (from KDE) has also given his input. Basically, the topic is becoming a point of a lot of discussion and controversy.
Before I launch into my ideas on the topic, what is the whole synchronization idea? (Feel free to skip this part if you already know.) The idea of synchronizing open-source software is that all the Linux distributions will release their new versions on the same day and upstream projects (projects whose code goes into Linux distributions) will time their releases according to the distribution schedule.
Now onto my ideas: The debate seems to come down to a single major issue. There may be side topics, but the core issue seems to be time-based releases versus feature-based releases. Time-based releases, as you may know, are releases based on a set time schedule. For example, Ubuntu does time-based releases, because they release a new version every 6 months. Feature-based releases, as you may also know, are where the software is not released until all the features have been implemented.
The advantage of time-based releases is that they offer predictability for businesses and software developers, goals to force the developers working on the software to keep moving, and easier scheduling of how long support for each version will last. On the other hand, though, time-based releases may discourage major new features and allow bugs to slip through the cracks and make it into the final release. As you can see, there is no clear best option.
So how is this related to synchronization? Synchronization would force projects into a time-based release schedule. This seems, at least to me, to be the biggest issue surrounding synchronizing releases.
Personally, although I don’t have a strong opinion, I think time-based releases are the best way to go because they make it easy to see that development is progressing steadily and encourage steady development. Also, with good management and the help of version control software, it should be possible to still introduce new features and keep bugs out.
Even though I prefer time-based releases, I recognize that it may not be the right choice for some projects. Initially, I made the argument that if the features were not ready in a piece of software or there were still bugs, that piece of software would just skip that release date and release at the next date. The problem is that a piece of software might finish with months left before the next release date. That is why I think optional OSS (open-source software) synchronization is the right way to go.
What I mean by optional OSS synchronization is that the projects that already use time-based releases would all synchronize, while feature-based release projects would continue with their way of doing things and their code would be incorporated as needed when it it possible. This would allow a major synchronization effort, without stopping the projects for whom feature-based releases work better.
Additionally, I suspect (correct me if you think I am wrong) that most of the projects that are serious about getting mainstream adoption will go with time-based releases, because of its appeal to businesses.
For all these reasons, I think optional OSS synchronization–having the projects that already use time-based releases synchronize while the others remain as they are now–is the best solution to the synchronization question.