Web App Trends: Users as Developers

The legend of how eBay got started is a quaint one: Pierre Omidyar created eBay so that his wife could buy and sell her favorite collectibles: Pez Dispensers. The story has been told thousands of times, and most people like to think that the site is a labor of love. Unfortunately, the story turns out to be a little bending of the truth: apparently Omidyar realized the site’s potential before pursuing it.

It is true, however, that Omidyar used the site to help sell his wife’s collectibles. He was one of the first users, as well as the first developer, of eBay. That may sound like an unusual combination: to be both the user and the developer. Our conceptions of both tend to be very different. Users are those people who use stuff. Developers are those who build it.

But what happens when they’re one in the same? What happens when the user is the developer, and vice versa? It turns out to be a powerful combination that leads to unseen advantages that those building for others don’t have (and might not be able to duplicate).

Scratching Your Own Itch

The web application Basecamp was created by a team of web developers at 37signals who had a project management problem.

“Basecamp originated in a problem: As a design firm we needed a simple way to communicate with our clients about projects. We started out doing this via client extranets which we would update manually. But changing the html by hand every time a project needed to be updated just wasn’t working. These project sites always seemed to go stale and eventually were abandoned. It was frustrating because it left us disorganized and left clients in the dark.”

“So we started looking at other options. Yet every tool we found either 1) didn’t do what we needed or 2) was bloated with features we didn’t need — like billing, strict access controls, charts, graphs, etc. We knew there had to be a better way so we decided to build our own.”


( Read more )

Apple pushes developers to deliver 64-bit support with new Snow Leopard beta

As expected, Apple on Wednesday evening provided its vast developer community with a new pre-release distribution of Mac OS X 10.6 Snow Leopard and asked that they focus attention on 64-bit compatibility in their third party kernel extensions.

The seed, true to predictions earlier in the day, is indeed build 10A314, which arrived in tandem with an identically labeled build of Mac OS X 10.6 Snow Leopard Server.

According to people familiar with the matter, Apple is «strongly encouraging» developers to get busy developing and testing 64-bit support in their kernel extensions (typically low level hardware drivers) for the new build.

While relatively few third party developers create kernel-level software, the new operating system won't work in 64-bit if users lack 64-bit versions of the kernel extensions (kexts) they need.

Developers can deliver both 32 and 64-bit kexts that will enable Snow Leopard to automatically boot as a 64-bit kernel on 64-bit hardware, including all Macs that use a Core 2 Duo or Xeon CPU, while also working properly in 32-bit on earlier Macs using Core Solo or Core Duo CPUs.

Microsoft faced similar driver transition issues when it tried to move Windows XP users to Windows Vista, which used a new driver architecture. Windows users have also faced some transition problems in moving from the 32-bit versions of Windows XP and Vista to the 64-bit versions of those operating systems.

Apple's need to get kernel developers up to speed on 64-bit support is somewhat less problematic because Mac OS X runs on a much smaller subset of hardware than Windows does, and Apple develops or manages most of the kernel-level driver software that most Mac users need to use the new 64-bit kernel.

Users who have specialized hardware and want to run Snow Leopard in 64-bit will need to make sure their vendors supply them with 64-bit versions of those drivers by the time the new operating system ships; it is expected to be released sometime this summer.


( Read more )