Are You a Sharecropper? If you're developing software for the Windows platform, yes. Or for the Apple platform, or the Oracle platform, or the SAP platform, or, well, any platform that is owned and operated by a company. They own the ground you're building on, and if they decide they don't like you, or they can do something better with the ground, you're toast. They can ship their own product and give it away till you go bust, then start charging for it; and use secret APIs you can't see; and they can break the published APIs you use. All of these things have historically been done by platform vendors.

OK, don't trust software companies they are EVIL. Gotcha.

How Not to be a Sharecropper If you develop server-side software that runs on Unix (by which I mean any platform that runs bash and creates processes with fork(), which includes GNU/Linux, Solaris, AIX, and many others), you're not a sharecropper. They're not 100% compatible, but they're enough alike that you can move around and nobody really owns the turf.

So you are not a share cropper if the platform is a commodity? I don't see how this relates to his definition of a sharecropper. The fact that you develop using only the basic UNIX APIs or whatever standardized APIs exist on your commodity platform doesn't leave you any better off if one of the UNIX vendors incorporates your functionality into their OS. It seems that all this helps you with that if one UNIX vendor alters their standardized APIs in a way that breaks your app then you can switch platform. This seems like a fringe case but let's go on.

You're not a sharecropper if you're building around the Apache webserver and the increasingly-large suite of associated software. Nobody owns it, and it runs on anything; nuff said.

This point seems even more irrelvant. The fact that my firewall app runs on Linux or my XML Web Services engine is built on Apache doesn't leave me any less fucked if Linux incorporates my firewalling functionality into the kernel or Sam Ruby & co. add whatever WS-* functionality I ship as part of some core Apache bits. Again, it only seems that you are protected if they deliberately try to sabotage your app and since you have the source you can catch them. Is this really that commonplace in the software world?

Let's go on.

You're not a sharecropper, especially not a sharecropper, if you're building on the Web platform. If you can define your value-add as a series of interactions via a browser, or an interchange of XML messages, nobody can whip the land out from under you.

If you are a web developer then your platform is the web browser. Then again, since this is Tim Bray talking and he's one of the W3C wonks his definition of Web may be different from mine. So I'll assume we are using the W3C's definition which seems to be "network interaction involving HTTP on the global internet". So I assume he means that if you limit yourself to HTTP and XHTML/XML then you aren't beholden to any platform which I tend to agree with.

Thinking about it, Tim seems to be saying that if you want to avoid being depenent on any particular platform then you are best off building against the lowest common denominator UNIX APIs and hosting some web application.

Good For the Customers, Too It's pretty obvious that it's healthier not to be a sharecropper vendor. But a little thought shows that it's better not to be a customer on a sharecropper's platform. When something good and new comes along, the chances are less that it'll be scooped and monopolized by the landlord, and greater that it'll develop into a healthy ecosystem.

Interesting. If you are a user products produced by Microsoft, Apple, or the Apache project you are getting shafted and are better off moving your application needs to a web-based application because users are screwed when the underlying platform shafts people that build on it.

But it`s especially good for the customers to be on the Web platform. The notion of routing everything through the browser (with one significant exception, which I'll discuss below) is incredibly user-centric, user-friendly, and user-empowering. Because once they know how to use the "Back" button, to click on highlighted text, and to fill out a form, then they don't need much training in how to use your application.

This is probably the wrongest thing I've read in a long time. The web browser is a limited interface that has passed its prime and showing its age. I'm not just saying this because one of the inventors of the web browser said so but because as a developer and user of a news aggregator I say things like I used to surf the web, now I traverse RSS feeds and Blogs. I also tend to remember the following quote from Alan Cooper, "Running your application in the browser is like having your office in the elevator".

The rest of Tim's rant is just more of the web browser is the only interface you'll ever need which I've already said I disagree with.

I'm not really sure what the bottom line is here. Tim Bray seems to think that serving every app over HTTP or on an Open Source framework prevents you from being at the mercy of any sole technology or specific product. Although this may be true to a limited extent (more in the Web case than in the Open Source case) this seems to primarily matter if you have a paranoid fear of the folks developing your platform. If you are the kind of person who believes that every person developing a Java application need to move to the Web because McNeally could pull the rug from under them at any time, you are the kind of person who should heed Tim Bray's advice ASAP.

Aight, I'm off to do some API spec writing for work. I hope this bored ramble makes sense to someone.

--
Get yourself a News Aggregator and subscribe to my RSSfeed

Disclaimer: The above comments do not represent the thoughts, intentions, plans or strategies of my employer. They are solely my opinion.