The Errant Idea

Seth Godin is a brainstorm in a teakettle, a one-man tornado of ideas and insight which I have a feeling would pick me up and fling me to Singapore if I got within three meters. That said, I’d like to know what site he’s referring to whose pages-per-visitor distribution has a mean of 2.1 and a median of 9. Unless it has a hell of a lot visitors viewing negative pages, which sounds kinda scary and more than a little sinister. Perhaps he meant mode rather than median? Or maybe he was exaggerating (to a mathematical impossibility) to make a point? Either way, it’s a little disturbing because his entire point is that people fail to understand what these measures indicate.

(Or am I completely deluded and it’s possible to have a mean which is less than half the median when one has a distribution composed entirely of positive numbers?)

Marc Andreessen, in his incredibly insightful little gem factory, has tackled the concept of “internet platforms”, a term which has been bandied about far too loosely of late. Marc brings some much-needed rigor to the discussion, and in so doing provides a framework to look at what the future might hold for the web as a confederation of platforms. I encourage you to go read it — good stuff.

But it seems to me that Marc has missed a subtlety in the definition of what makes a platform. You might call this semantic quibbling, but I think it embodies an insight that took the technology industry a decent while to figure out — and which, if this new ‘platform’ stuff takes off, will be coming back full-strength in this new context. Anybody who ignores it does so at their own peril, because it is almost undoubtedly The Way Things Should Be, and quite likely The Way Things Will Be.

CliffsNotes for those that didn’t read the article. Marc defines platforms thusly:

• Level 1 - a service which can be accessed by arbitrary applications. Google Maps, flickr, etc. Lots of these, and they’ll probably continue to form the basis of 90% of interesting developments in the ‘net space over the long term (my opinion there, not necessarily Marc’s).
• Level 2 - a bulletin board in which you can come along and pin random applications; that is, a meta-application which provides a means for plugins to be visually integrated. Think Facebook.
• Level 3 - a virtual machine which allows third-party code to be directly executed directly on the primary applications’ servers. Marc quotes Second Life, Salesforce.com, and his Ning, but decries Amazon’s EC2, saying it doesn’t count because — my summary — it’s too hard to use and/or doesn’t provide unique vertical capabilities. I’m not sure I buy the difference, and I’d like to see a definition where your commodity datacenter doesn’t qualify as a Level 3 platform — ’cause I happen to think it probably does, under these definitions, just not one particularly streamlined to the kind of uses Marc’s interested in.

So to my quibble. A platform is not a pile of capabilities that makes it easier to develop applications (although that’s usually — hopefully — an important side benefit). At its core, the one thing you can’t take away from a platform without completely losing the point is that a platform is an abstraction which buys freedom.

It abstracts the application from the machine, sure, so that you can run arbitrary applications on a machine, and the machine’s creator doesn’t need to anticipate every application beforehand. That part is parallel to Marc’s discussions of internet platforms. But just as significantly, it abstracts the machine from the application — so that the application doesn’t need to know that the hardware is running with an AMD or Intel CPU with a particular cache size, or this video card and that network card, or a particular OS version, or this chipset, or a particular amount of RAM, and so on. On modern platforms like JVMs, .NET, Flash, etc, the virtual machine lets the application developer even ignore things like what type of CPU is being used, or even what operating system. HTML+Javascript provides an abstraction (albeit an imperfect one — platforms are rarely perfect) from the browser itself.

That freedom is very important, because it means that (A) the stuff supporting the platform can be changed quite a bit without affecting the applications, and (B) a given application will run on a whole hell of a lot of different implementations of a platform, and won’t become useless once, say, the latest Nokia phone is supplanted by something with a touch screen (yes, I realize there’s not a good platform for phones that supplies such freedoms; that pain is significant, and expensive, and exactly my point). So is the platform? Simple a set of policies, interfaces, mechanisms and whatnot that define that abstraction.

So what does this mean for internet platforms? What freedoms are we forgetting? Well, how about the freedom to run an application on lots of different sites? It’d be painful to write and rewrite my little app to run on dozens of different proprietary “internet platforms” — and so I probably wouldn’t, and that’s a shame as it limits the richness of the ecosystem. I’d also not in practice be able to rely on Cool New Site Q being around forever (as mentioned by A VC), so I’d rather my application wasn’t locked into that company and their continued goodwill. More significantly, perhaps, if I’m a business trying to introduce a new “platform” type site, wouldn’t it behoove me to use as many existing abstractions as possible to make it painless for developers to port their existing applications? The pressure for a good abstraction isn’t just from the user side, it’s from both sides.

So, where would these abstractions come from? There are two possibilities. One, they could be consciously defined. Some particularly visionary company (no, Jectiv isn’t in this business, alas) could think about the problem and define the abstractions, then write the premier platform implementation. Think, well, Windows. An open source group could do the same thing, as could a confederation.

The other possibility is that the platform(s) will evolve and become a standard via network effects. Say a couple platform-ish sites start supporting running user JVM code on their site/servers, and provide libraries tailored for JRuby, with a display environment built around portions of Ruby on Rails (this is just an example, people). It’d snowball pretty quickly — network effects are like that. Before you know it, Ning had better be supporting JVM and RoR code or they’ll get steamrolled by somebody who will.

Google “Bootstrapping a startup”. Go ahead, do it, we’ll wait.

Yes, we could’ve provided a link, but this is mostly just a literary device, so that’d defeat the point. And besides, you learn by doing.

Back? Good. So you see, it’s a pretty common process — many have tried it, many have failed, some have succeeded, many have gone quietly mad, others quite vocally so. Staring a business with little — or no — money. And in many cases, no time. Which brings us to our point: doing a startup while holding down a day job.

It’s about the rules. One must not mix and match; doing startup work on company time is a hanging offense. Thinking too hard about it during work is grounds for a decent lashing (unless it’s one’s lunch hour).

One must structure one’s time militantly. And if that means that the evening hours of 8-12 (or, more likely, 8-2) are allocated to the startup each Tuesday, Thursday, and Sunday, and… well… Monday… and Wednesday and Friday, and usually Saturday… well, that’s how it has to be. (And if there’s a new season of television starting — well, time to invest in some more hard drive space for Myth!) Having a supportive and understanding spouse — assuming one has a spouse — is, hence, absolutely vital, since chances are you won’t be seeing quite as much of them for a while. We make a point of not working — much — during the day on weekends, so as not to lose the plot completely.

But time’s not the only thing that needs to be divided. Computers are an obvious one, and email accounts. Misappropriation of company resources: stoneable offense (no, the other kind of stoned). Story time. We had a (curiously unproductive) coworker some years ago who, it turned out, had been spending most of each day creating a web-based business right from his office. His startup’s official phone number was his office phone. I believe he may have been the first and only person ever fired from that company. No, we didn’t stone him. C’mon, obviously he was a complete loon — there are laws against stoning loons. But I do notice that areaflorist.com no longer exists.

This all leaves the stickiest subject, though: you. You see, your current employer owns you. Varies by state, of course. First, one must look long and hard and to see if there are any conflicts of interest. If so, you’ve gotta tell your superiors, now; the alternative could be nasty, and could easily sink your dreams. (We’m assuming you’re going to be careful not to actually misappropriate any of your current employer’s technology; otherwise, please stop reading this and go read, I don’t know, Slashdot or something until you grow up). But worse, your company probably has rights to what you do in your free time, and even some rights to restrict what you’re allowed to do after you stop working for them. Those non-compete and employment agreements you signed, remember? Yeah, nasty. The best thing to do is to write a (reasonable but thorough) amendment to those agreements providing exceptions for what you’re working on (or better, get your lawyer to do so, if you have a lawyer yet; they’re good at this legal stuff). And get it signed. I know, doesn’t sound like fun — but if you’re not up for that, you’re really not up for creating a successful company from scratch, are you?

At some point amidst all these rules and details, note that one must also find time to actually concentrate on starting a company.

(Alternate title: “Crooks and Nannies: how to bootstrap a startup without stealing your employer’s code or failing to raise your children yourself”)

The internet doesn’t have enough startups, so we (and note that this is the editorial “we”, not the royal “we”) at Jectiv have decided to step up and remedy this situation. So starting today, –

Actually, that’s not right at all. Jectiv isn’t starting today, it began in the summer of 2007 (6 p.b.*) and has been labouring furiously in the meantime to develop — wait, that’s misleading as well. Jectiv was born two years ago. It had bit of a misspent youth, wasting the many angstful months of its adolescence spinning its wheels, knowing it could never amount to anything, while it heard terms like Web 2.0 and social media whispered from the shadows, teasing, mocking.

In the summer of ‘07, though, an epiphany struck which reframed its entire life. In this new light, suddenly its ideas made sense — suddenly, its existence had value. It began in earnest to make the preparations to show the world what it had known, deep in its heart, since its conception two years before. But to prove this, it needed things. Use cases. Monetization plans. Algorithm evaluations. Competitive analyses. Interface definitions. Mockups. Scalability plans. A pitch. A schedule — a, mocking, ambitious schedule. And — oh, merciful Turing — a Prototype.

Herein we will watch the young Jectiv as it sets out on its own, with dreams and ambitions bigger than its pocketbook. It will be an epic journey, fraught with the usual things with which epic journeys are traditionally fraught, not to mention the somewhat less customary elements of late-night coding sessions, stinging rebukes from investors, server headaches and alpha tests, and — most wondrous of all — a henceforth non-anthropomorphized protagonist. That’s right: the author shall hereby revert to the only slightly less pretentious and annoying affectation of referring to ourselves in the plural. If you’re a good audience, we might even start dropping that.

* p.b., post bubble