It’s easy to write code to do things. It’s harder to build a product. It’s harder still to actually draw a line in the sand and decide when you’re “done”. The truth is all software ships with bugs. Someone who tells you otherwise is an idiot. They almost certainly aren’t all discovered, very likely some will be, but they absolutely exist. The general consensus is you want no glaring bugs and you don’t want big bugs in common use cases. Obscure use cases will always be more buggy. That’s the nature of the beast.

Knowing this, it’s easy to understand that changing release cycles will be an arduous process with lots of details to think about. Not everything is quantitative or can be reduced to a math equation. How long is it worth waiting for a feature? Is the shiny button worth 3 days? 3 weeks? 3 months? Indefinite hold? Will it even work as we think? What bugs will it introduce? How long to deal with those? Not an easy decision. Even harder to reach a consensus on. The only thing certain is the lack of a decision will guarantee a failure to launch.

The Firefox Version Problem

Firefox is now a 6 week release cycle. This means features get out the door soon after they are fully baked. That’s a very good thing. That means adoption of modern technologies and the latest in security is out there quickly. We all benefit from that.

The downside however is that upgrades are disruptive. They can break compatibility, and they require extensive testing in large deployments (big companies, educational institutions). That can be expensive and time consuming if you’re impacted.

The other side of this is version numbers get blurred. 4.0, 5.0, 6.0… “WTF is the difference” most users would think given it looks largely the same. But is it really 4.0.1, 4.0.2, 4.0.3? As a web developer, what versions are you supporting? This is now much more complicated (don’t even get me started in testing).

Stable vs. Slipstream

My modest proposal is a Stable/Slipstream (I prefer “slipstream” vs. “bleeding edge”) model. For example:

Firefox 7.0 ships in 6 weeks, September 27 as of this blog post. From then on, every 6 weeks a new release ships and would become 7.1, 7.2, 7.3 etc. For users, it’s just auto-updates every so often. These intermediate releases are disposable as the users are on the slipstream. They rapidly update. A matter of weeks after the release the previous one is unsupported. Previous releases are just a rumor, recognizable only as deja vu and dismissed just as quickly¹. They are oblivious to the concept of “versions” for the most part. After several release cycles (9-12 months), this becomes “stable” at 7.x. The next day 8.x starts and the process starts over.

From then on (I’d propose 12 months) only security fixes will be provided to 7.x. For large deployments who need to do extensive QA, they adopt the stable branch once a year on a predictable schedule and stick to it. For the vast majority of the internet, they adopt the slipstream (default) and get the latest release every 6 weeks. The stable branch is only around for a limited period of time before it moves to the next version. That last release cycle may be a bit more modest and lower risk than the previous ones.

The end result is that nobody cares about a release older than 12 months. Generally speaking only 2 matter. Slipstreamed users are updating rapidly (and will likely update even more rapidly as the process improves). Stable users have 12 months to hop to the next lily pad. This goes for IT, web developers, add-on developers, browser developers.

In the long term (next few years), I think web applications will become more agile and less rigid. Part of what things like HTML5 provide is a more standardized and less hacky way of doing things. That means less compatibility issues with untested browsers. As those older applications are phased out, the test cycles for large deployments will decrease. Ideally some will eventually just migrate away from “stable”.

Version Numbers

Yes, version numbers still exist, but for most users they don’t mean terribly much unless they have a problem or need to verify compatibility with something. In which case, the major release number is likely the important one. They are still a necessary evil, and users do need to know how to get it, even if they don’t need to know it offhand. Browser version number is pretty much the first step of any diagnostics for a web application as it’s the ultimate variable.

Just my thoughts on the last several weeks of debate.

1. Men In Black (2007)

One of the most interesting things is how users actually use the product you make, if they use it at all. Do they use it a little or a lot? Do they use it as intended? Do they find things missing? To robust for their taste? Or do they just find uses and modifications that all the engineers involved never in a million years would have contemplated?

Historical User Innovation

User innovation isn’t a new thing. Our brains were designed to tinker and reinvent. The wheel is nothing more than a plane where all points are an equal distance from a given point (centre). Fire is the oxidation of a combustible material releasing heat, light, and various reaction products. Both are natural logical things that mankind has come up with many clever “hacks” (todays term) for. We’ve even combined this seemingly unrelated geometric wonder and potentially dangerous reaction to come up with the combustion engine powered motor coach (car).

The Flier I, the first plane the Wright Brothers famously flew in 1903 used a chain drive to power the propellers from the single centrally mounted motor. The chain drive is bicycle technology the wright brothers knew well from bike repair and sale business.

Apollo 13 is the story of finding unintended uses for technology and to bring 3 astronauts home safely. First they used the Lunar Module (LEM) as a makeshift “lifeboat”. If that wasn’t clever enough they utilized plastic bags, cardboard, tape, and a hose from a space suit to rig some air filters from the command module to fit the LEM (you can find an amazing picture of that here).

These are just a few more notable examples but you could find millions more, from the old “soldiers tricks” you’ve heard time and time again like soldiers in the past using condoms to keep water and debris out of their gun among others.

Historic Computing User Innovation

Computing has long been about user innovation. The most obvious and the least recognized is computer games. Long before computers were ever intended to be used for recreational purposes people were figuring out how to do it. While it seems silly it eventually turned into a multi-billion dollar industry. Not bad for a nerdy trick on a cathode ray tube.

Then you had the geniuses at the Homebrew Computer Club and and the Altair 8800 which helped usher in a new era of computers that people could manipulate to do whatever they wanted. They were hackers, and they remembered that when they starting building computers for consumers. Their machines were customizable with software that could be developed easily (at least relatively speaking). Leading to the modern era of user innovation…

Modern Computing User Innovation

There are many examples of user innovation, but I’ll give just a few to make a point:

Some systems facilitate user innovation for example through extensions and plugins. Just take a look at Firefox and it’s robust addons collection. On occasion features have even become bundled into the browser, for example tab reordering. Other features first get prototyped as extensions (the reporter tool being a perfect example). Users are invited to develop their own features and innovations and share them with others. Clever, but somewhat technical. Removing the technical barrier is being done as part of Jetpack.

Another more subtle example is how people search often then they tend to browse. As many people with a domain name know, a noteworthy portion of traffic will come from people who just Google your domain name rather than enter it in the URL bar. It seems in at least some minds search and navigation have merged much more than in others minds. I’ll touch more on this in an upcoming blog post. For yet another example, leaving tabs open with stuff you want to read later. I’ve even seen (and done myself) the practice of blank tabs as separators between different things I’m working on in 1 window. There are extensions out there to help colorize to help organize as well.

One of my favorite stories is the Twitter hash tag. Hash tags aren’t something that the Twitter developers created or even intended for. They are something users just decided to do, and standardize on. It’s democracy through chaos at it’s best. Despite Twitter’s user generated data stream being compared to a fire hose somehow people caught on and agreed on this standard. Even cooler is how hash tags can spontaneously be created with seemingly little or no coordination. Users solved one of Twitters largest problems (organizing data) completely on their own without any engineering effort.

Even hardware is becoming more open to being modified and manipulated by users. Take for example the Arduino (something I totally need to get and play with).

A standard Web 2.0 feature has been to provide an API and tons of feeds to allow developers to mashup and find new uses for your service. Some have become insanely popular and helped websites, and others have fizzled at best.

There are many more examples of users innovating, but I will stop here. Sites like Hack a Day and Lifehacker do a good job documenting some of these.

How To Capture User Innovation

The big question is how do you capture this innovation and bake it into the product? Some lucky products like Twitter seem to take a life of their own and organically evolve. Others, notably non-web services like Firefox seem to take a bit more nurturing to find the diamonds, shine them up and bake them into the next version. Others still can’t even manage that.

There seems to be two basic paths that an organization can take:

Build the platform and let users take control – This is the Twitter method. Works best for situations where technical knowledge required to shape the product is minimal.
Build the platform and make it accessible for the technically inclined and willing – This is the API and feed route. Let developers build cool things, and hope they will improve your offering in return.

Are there others?

I think open source projects generally have an advantage do to their inherent open nature. They fully intend for users to have control. Those focused on content tend to have an advantage over those that focus on service.

It’s an interesting topic. How can you take this organic user innovation and utilize it to either fix the underlying flaws to make a better product or bundle the innovation to enhance the experience for all users? Just ask? Usability studies? More API’s? Bribery?

User Innovation may be the best there is. No engineer knows exactly how their product will be used and all the real life test cases. Users however are the test case.

So the servers had a giant melt down. That’s hopefully history now. It’s out! Go download it. While your at it, spread the word and help break a world record. After all, how many world records have you participated in so far?

• Awesomebar – Find what you want easier than ever.
• Malware Protection – Stay safer when browsing the web
• Native UI Appearance – It looks better than ever.
• Better Addons/Plugins Manager – Manage plugins with ease, find new addons.
• Download Manager – Resumable downloads!
• Smart Bookmarks – Most visited, recently bookmarked, recently tagged.
• Better Memory Management – Nuff said
• Powered By Robots Not only are they awesome, they obey the Three Laws of Robotics

See Deb Richardson’s Field Guide to Firefox 3 for more details.

For the navigation toolbar the most obvious change is the new keyhole design. My only complaint is that the menu that appears when you click and hold isn’t as intuitive since the arrow isn’t there.

Navigation Toolbar (Windows XP)

Navigation Toolbar (Mac OS X 10.4)

My only objection about the prefs is that the Windows privacy option is a great example of an icon that’s seemingly impossible to interpret what it’s supposed to represent. The light switch for “Main” is also a little odd, but I can manage with that much better than the privacy icon. Other than that, I think they look pretty good.

Options (Mac OS X 10.4)

Options (Windows XP)

That’s all for now folks. If warranted, I’ll post again with updates.

First, there’s street cred: People want to garner approval from their peers and build their reputation. Second, there’s self-actualization: Working on these projects is enjoyable in and of itself, and it also provides the opportunities to practice your skills, collect feedback, and grow as a geek. Third, there’s pure altruism: Let’s save the world, one squashed bug or “[citation needed]” at a time.

Interesting stuff. I definitely fall in the “practice your skills, collect feedback, and grow as a geek” category.

Also noteworthy: 97.8 percent of open source programmers are male. Like there was any surprise that it’s somewhat of a sausage fest on #developers. Anyone ever check the ratio on about:credits? Come up with an automated way to do that’s licensed under MPL/GPL/LGPL and you’ll earn some serious street cred not to mention save the world and practice your text analysis skills.

I guess this is even more extreme than the Dave-to-Girl ratio.

Robert O’Callahan’s got a got a great blog post on some of his observations of things Mozilla would likely make good use of. He also mentions one thing worth quoting:

It’s worth reflecting that if Microsoft was doing this, they’d likely be hauled before a judge, in the EU if not the US. In fact I can’t recall Microsoft ever pulling off an undocumented-API-fest of this magnitude.

This is a very valid point which I 100% agree with. Microsoft wouldn’t get away with this.

Safari developer David Hyatt (former Mozilla developer from when Lizards roamed the earth) commented about this issue. Essentially he justifies the decision based on it not being a good practice to use some of these methods, and other aren’t even used anymore. This of course raises the question: Should Apple be deciding what other software developers can do, when they themselves can’t follow the same standards? I’d say that if WebKit feels it has to use it, there’s likely others out there in the same situation regardless of “best practice”.

See, I’m not too much of an Apple fanboy to criticize them .

Adobe Air vs. Mozilla Prism vs. Microsoft Silverlight

Google Gears vs. HTML5 Offline support

Android vs. iPhone SDK vs. Symbian

Ruby On Rails vs. PHP

Not every case will have a true “winner”. That’s not really a bad thing. Choice is good. In some cases they will merge to form one standard, such as what’s likely for offline web applications.

What is interesting is that SQLite really dominates right now. Adobe Air, Mozilla Prism, Google Gears, Android, iPhone SDK (likely through Core Data API), Symbian, Ruby On Rails (default DB in 2.0), PHP 5 (bundled but disabled in php.ini by default). It’s becoming harder and harder to ignore that SQL survived the transition from mainframe to server, and now is going from server to client.

No longer is the term “database” purely referring to an expensive RAID5 machine in a datacenter running Oracle, MySQL, DB2 or Microsoft SQL Server. It can now refer to someone’s web browser, or mobile phone.

This has really just begun to have an impact on things. The availability of good information storage, retrieval, and sorting means much less of these poorly concocted solutions and much better applications. Client side databases are the next AJAX.

Edit [2/27/2008 9:14 AM EST]: Added Symbian, since they also use SQLite. Thanks Chris.

..up to 130 million requests per day, with periods of sustained bandwidth usage of 350Mbps, for resources that haven’t changed in years.

They also make a few requests which really all developers should follow. Here’s my summary:

• Cache as much as possible, to minimize your impact on others (not to mention improve your performance).
• Respect caching headers
• Don’t fetch what you don’t need
• Identify yourself. Don’t use a generic UA.
• Try not to suck.

It should be noted that this stuff isn’t finalized and will definitely be tweaked. In the past things were adjusted until the very last moment, I expect we’ll see the same. Also don’t forget things like the planned keyhole shape aren’t even in place yet.

Navigation Toolbar (Windows XP)

My general thought on this is that Windows XP has thus far been left behind. Linux and Mac OS X look absolutely awesome. Vista doesn’t look to bad, though in general I think the OS design is an ugly turd. For XP, the reload and stop button are particularly what looks the strangest. Both seem to thin and small. It really doesn’t fit the rest of the UI. Home I think actually is actually an improvement. A step away from the “dirty house”. Back/Forward haven’t been updated yet as I mentioned before.

Navigation Toolbar (Mac OS X 10.4)

Simply awesome. Enough said. Not even shown is the new tab design which is also better. I’ve got to put together a screenshot post of Mac OS X thus far so others can drool.

Options (Windows XP)

I think this overall is better than the toolbar. I still have a few issues with it. For one the “Main” icon abstractly looks like a switch, but I’m not sure how apparent that is if you didn’t know what it was supposed to be. “Tabs” looks slightly distorted (that’s one tall tab) but otherwise good. I like the concept behind “Content” but I’m not sure I can tell what any of that is. Images is clearly in there, it would be nice if it was more obvious you can control popups from in there. “Applications” seems to work well. I’m really not even sure what “Privacy” is supposed to depict. Anyone know? “Security” and “Advanced” also very nice.

Options (Mac OS X 10.4)

It’s pretty much the same old, nothing to report here. Looks good.

So there you have it. My 5 minute rundown of some icon changes. There will be more, and a lot more polish I’m sure. I’ll try and post a follow up later on and show how it’s changed. For anyone who hasn’t seen it yet, hopefully this gives you a little taste of the great UI design work being done.

I’d say the answer is somewhat more complex than a simple yes/no. There are many different types of projects out there with entirely different circumstances. However I suspect a projects impact could be gaged on a few key aspects of it’s operation:

Purpose – The purpose of the project is likely the most critical aspect. For example, I don’t think there would be any significant impact on projects like the Linux kernel which is essential to many products out there including server infrastructure that powers much of the web and many companies computer systems. Then you have consumer products like TiVo, Google Android etc. Because it’s purpose is so broad there are enough people with a financial interest in seeing development continue. WebKit, Mozilla, Apache, are good examples of this. They have broad usage by many. Something specific to a more obscure task would have more trouble due to it’s more limited market.

Development Team – Of course for a project to succeed it needs one or more developers. During a recession one could theorize that many would be less inclined to participate. This may not necessarily so. First of all, quite a bit of open source development is loosely sponsored. Several projects have actual staff, paid employees who write open source code. For example Apple employees people to work on WebKit. Mozilla has staff working on Firefox. There are people paid to work on Linux (Red Hat, IBM, Novell, etc.) and many other open source projects. There are also companies who contribute some code that would be of strategic value to them. There’s also those who are simply willing to sponsor some work they want to see happen. All of which fund developers of larger open source projects. But would developers who aren’t sponsored or employed to code still participate? I theorize most still would as they don’t depend on it for income during good times, presumably a job during a recession wouldn’t generally prohibit participation and more than a job during years of economic growth. There’s also the impact of college students who participate partially for the educational aspect. The early 2000′s was a recession and still showed a fair amount of growth of open source. In fact many of todays stars really started to take shape during that period. For example:

• WordPress (2003)
• Apache2 (2002)
• BitTorrent (original client) (2002)
• VLC (2001)
• OpenOffice (released as open source in 2000)
• Pidgin (formerly GAIM) (1998, though really grew up between 2003-2004)
• Filezilla (2001)
• 7-Zip (2000)
• Wikipedia (2001)

Funding – Somewhat obvious: Funding is key. Who pays the developers (partially the last aspect I discussed)? Who pays for the projects needs (servers, etc.)? Many of the more popular projects (almost all of the above) have either an organization of for-profit company around built around it. That company often sponsors the needs of the project. Unless the needs of that companies product/service is no longer needed during the recession, funding likely remains. That’s partially the first aspect I discussed.

It’s my belief the larger and more popular open source projects would feel a minimal impact during a recession. I think history has shown this, and common sense agrees. They are mostly low development cost, adequately funded (often from diverse sources), stable, and have a broad team of developers. The projects that are in trouble are the ones who have very few or only 1 developer, even worse if they share the same sponsor, even worse if there is little community around the project. Most projects would generally experience a slight slowdown in development the degree would depend on the above. A few may go dormant for a period of time. Thanks to things like GPL licensing, another developer can pick up should there be a market in the open source ecosystem.

Overall I don’t think open source would be nearly as impacted as most businesses during a recession. The model is very different. Open source when successful has a community and many different sponsors. The diversity allows the project to survive even when recession causes some sponsors to need to reduce or eliminate involvement. Open Source also by definition is used to this type of environment. It’s used to developing on a budget, soliciting sponsors to help cover costs, etc.

The interesting thing about recession is that it impacts everyone, but the degree to which someone is impacted varies. For example construction and housing are generally harder hit than other industries. People tend to cut back on new home purchases before they cut back on other things. Each of those industries has computing needs, sometimes met by open source. This all feeds into the open source ecosystem.

I’d suggest that all of the projects I have mentioned here will do ok during a recession. Many with a slowdown, but all will still continue as long as they provide value. A notable situation is Mozilla’s income comes largely from Google which is based on ad revenue. During a recession and bubble bursting this would likely dramatically reduce the revenue brought in. This isn’t being ignored. As the 2006 Financial FAQ states:

First, the cash reserve is of course a form of insurance against the loss of income. We will continue to maintain enough of a reserve to allow us flexibility in making product decisions….

It seems that an open source project with a diverse stream of funding from individuals and companies of various industries, as well as developers in different situations is in the best position to survive.

It’s an interesting topic.