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.
Lesson: Deliver!

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 up.
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 (Roadmap) use 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 the forecast 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 expect roadmaps.

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.

Naming

Not much went right with the name. The name was a nonproductive distraction to the project that was never fixed.

1. 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.
2. Never Fixed: The name UserLinux had three key flaws:
   1. 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 potential growth.
   2. 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 important.
   3. It was occasionally confused with UnitedLinux by people familiar with the Linux market. UnitedLinux is the old Caldera, Conectiva, SUSE and Turbolinux initiative.
   Naming Lessons:
   1. 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.
   2. Think of the audience when creating a name for a project or software.
   3. 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 project otherwise. 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.

IT Problems

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:

Lessons:

1. 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.
2. Individuals working on software sometimes think of themselves first, with little regard for the end user.
3. 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

Concept

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 the implementation.

Specialized work teams

Departmentalizing is a good idea even though it was accomplished too late and not sufficiently strong.

Mark Protection

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.

Internationalization

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.

Mission Statement

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:

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 doable.