UserLinux has been for all practical purposes dead for months now. The
most immediate points of failure and a brief history were covered in last
week's edition of LWN. There were no
messages on the UserLinux list for over 30 days, ending when the thread
titled "Anyone still alive" was started on September 3rd. UserLinux today is a non-issue and of little
worth other than to learn from.
I spent a notable amount of time on this project, writing the Mission
Statement and other key components. Though UserLinux has failed, at least
I gained some worthwhile experience. As with other failures, there are
things to be learned from an autopsy after death.
Points of failure for UserLinux
Inability to deliver product
The immediate cause of death was an inability to deliver software. Today
there still is no real delivered product, over three months after the
release of Debian Sarge. A common claim was that UserLinux would have a
release out about a day after the Debian Sarge release and when
this didn't happen, confidence decreased for the project.
Untimely delay of Debian Sarge release
There was an artificial delay in the move towards the initial 1.0 release
and this had a notable, but non-fatal effect on the project. This was not
the ultimate cause of death, however, and delivering as promised a short
time after the Debian Sarge release would have livened the project back
Lesson: Dependence on outside sources can cause painful delays. Be
prepared for the consequences.
Lack of roadmaps
The "when it is ready" mantra is not sufficient for a lot of people. They
want an estimated schedule to look at and an idea of where things are
headed. Even if one is looking at third party development, or in the case
of UserLinux, there is an overlap of developers between the project and
Debian, confidence goes up if time estimates are made. People are used to
roadmaps and popular projects such as Mozilla Firefox (roadmap) and OpenOffice.org
roadmaps as do many commercial software vendors. Yes, roadmaps are often inaccurate, but like weather forecasts,
people like an idea of what is going to happen in the future, even if
is imperfect. It helps in planning, which is especially nice if
a migration is being considered. Given that an area of interest for
UserLinux was to encourage migration from Microsoft platforms,
roadmaps would have been very beneficial.
Lesson: Don't fear the roadmap. People appreciate and sometimes even
Late on departmentalizing into teams
There was no serious effort to divide the project into teams until about
10 months after the project started. The lack of teams encouraged problems with naming and engineering focus.
Not much went right with the name. The name was a nonproductive
distraction to the project that was never fixed.
- Nonproductive Distraction: Everyone seems to want to name things. A
co-worker of mine was genuinely fascinated by the prospect of naming this
new distribution that he had no real interest in otherwise. This is an odd
piece of human behavior. Open source projects tend to have bad names which
lead to less than desirable first impressions. This genuinely hurts
adoption, especially in more corporate environments. We had our share of
mindless naming suggestions like "Rabbitware Linux" that had no real purpose other than to appeal to the person suggesting the name.
A notable chunk of the overall list traffic for UserLinux was related to
the name and though it wasn't all as bad as "Rabbitware Linux" (rwLinux
for short), marketing and positioning were often not considered foremost
when suggesting names.
- Never Fixed: The name UserLinux had three key flaws:
- People in general do not like the term 'User', and the hatred seems to
grow as the user base gets less technical. This is counterproductive,
especially with the existing Microsoft desktop market as a key area for
- Domains. It is a very good idea to have at minimum the .com domain, and
if running a non-profit, the .org domain for a given name. UserLinux did
not have the .org which can be confusing since a .org
domain is expected for organizationally based projects. Given the
primarily online nature of the project, strong domain presence is
- It was occasionally confused with UnitedLinux by people familiar with
the Linux market. UnitedLinux is the old Caldera, Conectiva, SUSE and
- The naming problems could have been lessened by having a
marketing-specific group handle the task. The group should have had
the authority to establish
concrete naming guidelines. Unfortunately, neither was the case.
- Think of the audience when creating a name for a project or software.
- Understand the primary points of contact for an organization and if you
cannot sufficiently meet those needs with a particular name, find another
name that will work.
Engineering focus Engineering was distracted by marketing activities.
Marketing talk was initially on the same list as engineering, which
distracted and annoyed some people who might have contributed more to the
Engineering Lesson: The marketing list should have been created earlier.
Overall Team Lesson: Departmentalization should have been done earlier.
Teams help keep people focused on where their strengths are.
Multiple downtimes for the list seriously hurt participation, as did an
obnoxious amount of spamming on the wiki that could have been handled much
better and more swiftly.
Lesson: If web infrastructure is the primary point of contact for people
working on a project, maintaining those systems is remarkably important.
Group mentality baggage
Using KDE as a desktop environment alone or with GNOME was not in the best
interest of the project for a variety of reasons, but some would propose
that not including both desktop environments was unfair to the developers
of both environments.
Here is an example from the mailing list:
I think we (ok, not especially me, but the people involved in UserLinux)
don't have the right to prefer one of the two big DE projects over the
Wrong. The real injustice is to force feed extra software with the
associated bulk, security risk, and training because one group of people
thinks that if their software isn't force-fed needlessly on users there is
some injustice occurring. Of course, the real injustice is not looking out
for the best interest of the people using the software. Put the people
using the software first. The focus on a developers-first attitude was
particularly disturbing to me. More recent announcements like the
Subversion team recommending against use of Subversion
for the Linux
Kernel development team show this is not a universal problem for all free software. Outside of KDE, UserLinux really didn't have many of these problems. My introduction to KDE, outside of running KDE occasionally as a desktop environment, was people on the list speaking out for KDE like in the example above.
- People will form in groups and argue for whatever their group thinks is
right, and while at it they are not afraid to put their interests first.
Software is not immune to this phenomena, unfortunately.
- Individuals working on software sometimes think of themselves first,
with little regard for the end user.
- If someone's first impression of a project is similar to what I
experienced with KDE, those actions are likely doing that project a
disservice. There are plenty of good people working on the project, but the
memory of interaction like the above has the biggest impact on the overall
impression, especially when it is the first interaction you've had with
people from a specific project. Over the course of months, people would
ask about that Linux project I'd mentioned I was working on some weeks
earlier. At the time ,the primary response they would get is me mentioning the problems with KDE people. I wasn't in a KDE camp or GNOME camp (yes, I did design the
GStreamer logo while at RidgeRun but we used GST for embedded applications
independent from GNOME), but KDE, through the actions of a few, started to
look ugly to me very quickly. And for what? Hopes of gaining a foothold in a
project that ended up amounting to nothing. We never had problems like this with other software decisions such as PostgreSQL vs. MySQL or Postfix vs. Exim.
Things done right
The concept of a non-commercial distribution with a limited set of
software accompanied by certifications and ISV support is superb. The
ultimate failure was in delivery. Some of the other ailments above could
have possibly been solved over time. The idea was not the failure, it was
Specialized work teams
Departmentalizing is a good idea even though it was accomplished too late and not sufficiently strong.
The Mark Protection Policy is an
excellent idea. UserLinux software packages should have been named with
separation from the UserLinux name earlier than they were, and the Policy
itself should have been written better, but the idea is excellent. I
strongly recommend Mark Protection for free software projects.
Non-software organizations have learned the value of this from abuses many
years ago, and it is about time free software did too. Mozilla's Firefox
has protections in place today which is encouraging. Abuses like what has
occurred with Debian's open use mark, as mentioned in the UserLinux Mark
Protection Policy, need to be stopped.
It is most impressive how people from throughout
the world will translate something of interest if given the chance to
contribute. For example, the UserLinux Mission Statement is available in
over 10 languages. In retrospect, this was the most delightful surprise from working on this project.
This helped people focus on the task at hand and
helped explain the purpose of the project quickly to people who would
hopefully consider migrating to UserLinux in the future.
The road ahead
Ubuntu has largely grown into the simple, effective distribution UserLinux
hoped to be. UserLinux is currently hoping for resurrection.
This seems unlikely.
The largest differences between UserLinux and Ubuntu are how they are funded and how the groups behind each distribution are designed to function. Beyond that, provided Ubuntu remains a streamlined distribution, remains free, includes a notable ISV support network, and
provides a reasonable certification program.
Ubuntu will largely deliver on
the UserLinux Mission Statement:
Provide businesses with freely available, high quality Linux operating
systems accompanied by certifications, service, and support options
designed to encourage productivity and security while reducing overall
Time will tell if Canonical will have commercial success with Ubuntu. They
already have made successful inroads into the early adopter market. If
they can cross the chasm into the early mainstream desktop market
adoption, they should be quite successful delivering custom OEM install
packages, certification services, and high-end customization and support
services. Key areas for success will be getting large OEM PC manufacturers
to create serious offerings with Ubuntu, establishing standards and tests
for certifications, and getting a network of Independent Software Vendors
(ISVs) behind Ubuntu Linux. This will not be an easy task, but it is
to post comments)