Steve Yegge post about platform vs product

Question

I am reading this and I came across:

The Golden Rule of Platforms, "Eat Your Own Dogfood", can be rephrased as "Start with a Platform, and Then Use it for Everything." You can't just bolt it on later. Certainly not easily at any rate -- ask anyone who worked on platformizing MS Office. Or anyone who worked on platformizing Amazon. If you delay it, it'll be ten times as much work as just doing it correctly up front. You can't cheat. You can't have secret back doors for internal apps to get special priority access, not for ANY reason. You need to solve the hard problems up front.

What does that exactly mean? Can someone please explain?

Answer 1

One point he's making is that, especially for anything web-oriented, but for others as well, you benefit greatly by providing an open, programmable interface. That doesn't mean a UI with a macro language, but a UI that's mostly separate from the "engine" that does the real work -- and full, open documentation of how the UI talks to the engine, so anybody can write a whole new UI that uses the engine, add-ons to the engine that can hook seamlessly into your UI, etc.

In short, instead of building (or even thinking in terms of) complete products, you should think and work primarily in terms of producing useful components. Those components need to work with each other cleanly, but that's not enough by itself. The interfaces between those components need to be clearly documented and defined so they're suitable for essentially anybody to replace (for example) your UI with something of their own, plug it into your engine, and be able to use your engine to its full capabilities, because they have just as much access to its capabilities as anybody else does.

Ultimately, this isn't a dramatic change from what's been pushed for some time (e.g., 3-tier applications). The big difference is that even though they're written as components, most typical 3-tier applications still basically assume that all the components in use will be produced together, so all the interfaces between them are "private". In quite a few cases there are implicit assumptions that one component need not check inputs from another, because it "knows" what inputs the other can produce.

Especially for web-facing servers and such, that's just not tenable. Instead, every interface has to be "hardened" -- specified and implemented to work under any circumstances, specifically including the possibility that whatever's on the other side of the interface may be sloppy and crappy, or even a carefully engineered attacker.

Looked at from a slightly different perspective, a product should provide for entry at any of a number of different levels. For beginning users, it should have a polished UI. For more advanced users, it should have some sort of built-in programmability to tweak things they don't like, automate things they do too often, etc. Finally, and most importantly, it should provide a low-level interface that gives full control of every aspect of the "engine" of that product. This needs to be exactly what you use to develop your own code to work with the product's engine, so anybody else has just as complete of access to that engine as your own UI does.

Answer 2

Thanks for the link -- Steve Yegge must be the best ranter on the Internet these days. And since ranting is pretty much the killer app of the Internet, that's saying something. On to your question:

What does that exactly mean? Can someone please explain?

Uh, you did read the piece, right? I did, and I recall that Steve spends most (okay, some) of his column-inches explaining what that paragraph means. See Eating your own dogfood for an explanation of the dogfood metaphor, if you need that explained.

Beyond that, the Big Idea he's talking about through the whole piece is that there are a lot of advantages in building a platform for products instead of a single do-it-all product that tries to be everything to everybody. With a platform, you can build many different products, and you can let other people build products on your platform too, and in that way you can better serve your customers and even let them use your stuff to serve themselves. But, it doesn't work if you don't commit to the platform; it doesn't work if you don't use the platform yourself, or if you use it but also have some extra for-internal-use-only tools.

Adding my own 2 cents, what he's talking about is very much like the difference between top-down and bottom-up design. Top-down: you dream up a product, and then set about specifying all the things that product will be able to do, and then you build that product. Bottom-up: you dream up a product, but instead of trying to determine every little feature up front, you instead build a number of parts that you can combine in all sorts of ways to arrive at something kinda-sorta like the product you imagined in the first place, but along the way you might also use those same tools to build a bunch of other things you never even thought about.

Answer 3

Use your own software - it is the best way to test it and perfect it.

A "platform" is this article refers to a piece of software that other people can use to make their own programs work. For example, Facebook is the "platform" that Zynga used to make "Farmville" work.

Windows is a platform too - because other programs (Word, Chrome, World of Warcraft) use it to work.

The article makes the distinction between a "platform" and a "product". A product is also a piece of software, but is "stand alone" - it is something people will use, but isn't something that software creators can "extend" by writing software that uses it. Most programs that run on Windows are products in this sense rather than platforms.

The biggest criticism in this article is against Google+, which is a (to me) brilliant product (as in I love to use it) but not a good platform because it doesn't expose an API or service that other programmers can use. For example: Google Reader can't easily see and post to Google+; Flipboard (ipad app) can't see or post to Google+.

Answer 4

I believe it's saying, "Use the same interface you're giving to the outside world." The interface you give your own programmers is going to be good (hopefully because a programmer will create an interface that s/he would like to use). If you have a different interface internally than you have externally, then the external interface will be lacking since the people who use it are not able to change it for the better.

In that way, nobody will use your platform because it will be impossible to use. They won't be able to get the information from the platform they need. They're relegated to second-class citizens and third-parties will go somewhere they are treated well.