Hacker News Reader

I realize that the idea of “Commoditizing Your Complements” has gained new life lately on HN, but let’s give credit where it’s due - Joel Spolsky in 2002.

https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/

The first four words of the linked Gwern article are "Joel Spolsky in 2002". In fact he gives him credit 3 times!

Yes but why not link to the original (which is also more readable)

Sure, but Spolsky didn’t invent the concept. The idea is probably hundreds of years old.

Well this is like an inverse for that strategy. If your core product is OSS you aren’t commoditizing its complements, but rather trying to build and charge for those complements (such as hosting or management services, consulting, etc) because you can’t charge for the product itself.

For a profit seeking corporation, your core product is the product that makes you money.

Roku sells hardware, but the CEO has said in no uncertain terms that their core product is aggregating user data to sell to advertisers. That they don’t consider themselves a hardware company.

IBM was also big into open source to sell mainframes and services.

Credit for what?

For “commoditize your complements” strategy, which was probably popularized by Stratechery but GP found earlier piece by Joel Spolsky about the same idea.

So credit for a phrase? Neither invented the actual strategy.

There is a lot of value in distilling some amorphous concept or unclear practice into a simple rule that makes sense and frames it in a template, making it easy to both recognize and implement.

Well, Einstein didn't invent Relativity but he gets credit for describing it.....

He did invent it. Our scientific models are just that: models that can make accurate predictions.

So every discussion involving relativity has to mention Einstein even when it's not germane?

Everyone keeps linking to the Gwem.net website instead of using the primary source.

If Albert Einstein had a blog post about relativity, I would rather read that than someone’s interpretation....

The Gwern post is better: it starts by linking, quoting, and summarizing the Spolsky post, but then goes on to give many more examples.

He wrote books about it, have you read them?

Well actually....

Used to the physical embodiment of recordings rather than the de-materialized reality of digital music, they spent years working on mandated inconvenience through DRM and other legal actions.

Isn't GPL and AGPL Copyleft another form of mandated inconvenience for companies? Come to think of it, many laws are mandated inconvenience with the stated purpose of correcting for some masked externality.

So what is an "open source VC funded" company doing? Creating complements and selling those. It's just that there's no intrinsic reason that the same company that gives away labour as OSS should also make the best complements to that OSS. It's not a law of nature that e.g. Redhat should be the best people to provide consultancy on RHEL.

The historical record indicates that there are indeed network effects at play with communities of experts. However, the historical record also indicates that such effects on pools of expertise aren't powerful enough to create monopolistic single factions which can lock out all competitors.

every company operating as an "OSS startup" has to know from the start that their software can't be charged for directly.

All money made from open source really comes down to the application of expertise to do things with software. The ultimate question is whether software expertise itself can be commoditized.

(EDIT: Another way to phrase it: Is software an ouroboros? It's a snake eating its own long tail. Software keeps eating itself, but it continues the process by creating sufficient change to allow itself to grow as an industry. As time goes on, there are more experts needed. This then begs the question, "What could possibly cause that to change?")

I think the use of revenue is a little disingenuous.

Producing, packing, and shipping a physical copy and marketing on broadcast television were major expenses of the pre-2000 world that they no longer have to the same extent (maybe they still buy TV ads but I haven't seen one in a decade at least, used to be all over the place). If you keep smaller part of $12 or a larger part of $0.99 your revenue could fall with profits staying the same.

Maybe the overall picture stays the same but this was very distracting for me from the argument made in the article. It made me wonder what else isn't quite right.

The peak on the graph is 1999.

At the start of the decline, there wasn't really a good way to buy music in digital format at all. iTunes launched in its current form in 2003.

The decline between those years was essentially the industry losing $12 sales to $0 sales: either directly to piracy, or to competition for time and attention on the Internet.

Youtube blew even more of a hole in the industry in 2005, replacing purchases with streaming. This plays $0.0006 per stream.

(The corresponding profits graph is really hard to find, which suggests that the data may not be so publicly available?)

> there's no intrinsic reason that the same company that gives away labour as OSS should also make the best complements to that OSS

There are no guarantees that they will provide the best complements to their own product, but the common sense is that they will. From a marketing perspective, I think it makes complete sense, especially when selling to enterprise customers.

But they don’t.

The best complement for server side software is often being able to do it reliably, globally, redundantly, managed, on demand, and cheaply. The only three companies that can do that reliably as far as most customers are concerned are Amazon, Microsoft, and Google.

I agree, I think Docker is an example on how to almost completely fail to take advantage of being first to market. Redhat, AWS, Google and others were quicker to monetize on docker (the runtime) than Docker the company.

Docker are actually an example of a pattern, one that also impacts MongoDB and many other companies. That pattern is that they intentionally branded the product and the project with the same name (in this case Docker) to help with slipstreaming on the community mindshare they were building.

The flip side of that which eventually comes home to roost though is that it means the two are easily confused . If I'm a customer and I can download X or buy X from you, and the two are virtually identical, you better have a damn good story as to what your value proposition over and above the project is.

Red Hat actually arguably only just got themselves out of this. Originally there was just Red Hat Linux, regardless of whether you paid them a cent. The split into Fedora (Core) - the free distribution - and RHEL - the enterprise distribution with paid support subscriptions - is a not insignificant part of why the company still exists today. This transition was not without controversy, and arguably created the space into which Canonical and Ubuntu emerged, but it was a necessary step to disambiguate the project and the thing people actually pay for with its own value prop and messaging around it.

It's somewhat surprising that so many of these companies proclaim they want to be the next Red Hat, but ignore the prior art for how that came to be.

I don't see anything Mongo could have done differently. Even if Mongo were completely proprietary software, it wouldn't have affected AWS. They didn't use Mongo's code just emulated their API. That's basically the same thing that kicked off the entire PC industry -- clean room cloning BIOS.

Emulating a propietary API would open up the door to litigation with uncertain outcome, generating distrust and bad press for Amazon. So not the same.

This has already been settled in the courts: APIs are not subject to copyright and may be freely reverse engineered, provided the usual cleanroom methods are followed.

After the Google vs Oracle case i thought the courts decided the opposite of what you are saying: APIs are copyrightable and Google will have to pay aot of money for using them in Android.

> After the Google vs Oracle case i thought the courts decided the opposite of what you are saying

Are you posting from the future? Because it isn't after that case yet; Google plans to appeal (given that they filed for an extension to the 25th of this month) the latest Federal Circuit decision to the US Supreme Court and, if that doesn't succeed and end the case in Google’s favor, the next step would be a third trial in the District Court, followed—however that turns out—by another appeal by one side or the other to the Court of Appeals for the Federal Circuit, possibly another petition for en banc rehearing after that appeal, and potentially another appeal to the Supreme Court.

The original PC BIOS was also proprietary.

Google did the same thing with Java. It’s up in the air how that will turn out.

Actually the courts already decided in Oracles favor, the only remaining thing to establish is how much money Google will have to pay.

Actuallt the courts already decided in Oracles favor, the only remaining thing to establish is how much money Google will have to pay.

> as far as most customers are concerned

Probably true for the average punter, but we shouldn’t overlook the other players, like Alibaba, DigitalOcean, IBM, Vultr, Oracle, Linode and more.

A serious enterprise is not going to bet their cloud infrastructure on Linode. AWS offers a lot more than just a bunch of hosted VMs.

A serious CTO whose neck is on the line is not going to go with a small player.

To paraphrase an old saying.

“No one ever got fired for buying AWS”

For an MS shop, the same could be said for Azure.

If you go with AWS because they have the best SLA, or GCE because they have better managed K8 offerings, then fine.

But going with AWS because ‘no-one ever got fired’ for it, or picking Azure because you play squash with a guy from Microsoft’s sales team is just lazy. Not that I’m saying it doesn’t happen.

Forbes and Gartner might ignore the other players, doesn’t mean we can’t be better informed.

Well, let’s look at where the phrase originated and how that turned out.

If someone had bought a mainframe IBM system in 1980 to run their COBOL system over their competitor, 40 years later, they could still buy a compatible system from IBM. It’s competitors - not so much.

On the other hand, idealism has its place, but when things hit the fan because of your choice of vendors, it’s a lot easier to justify a buying decision by saying the vendor was in the second quadrant of Gartner’s Magic Square.

more than VMs. yes, and that's the vendor lock in part.

sometimes it's okay though.

but AWS monoculture is not a bright future.

All of the services with no lock in

Elastic Cache - hosted Redis and Memcached

Aurora - compatible with MySQL and Postgres

RDS - hosted versions of Mysql, MariaDB, Sql Server, and Oracle.

Redshift - yes it uses a proprietary/columnar store engine but it is compatible with Postgres.

Etc.

But the bigger point is that you’re always locked into your infrastructure, do you think your CTO is going to move from their million dollar Oracle infrastructure because you used the Repository Pattern?

AWS has quite a few other solutions that you haven't mentioned that are not so portable.

I'm not advocating simply ignoring AWS's strengths because let's say Lambda/EBS/ELB/etc. is proprietary, but this is a very real, very simple risk. As AWS can, it will raise prices.

And sure, maybe it doesn't matter because you can always just fall back to using whatever you use on simple VMs, and AWS will always have some competition in the simple VM hosting space and VM prices will therefore will be low.

However, I'm on the opinion that institutional inertia will "kick in" (to use a rather bad figure of speech for something that is about as agile as a drum of molasses) and will simply let AWS rent-seek.

So you’re going to “move to the cloud” and just host a bunch of VMs.

Congratulations, you now have the worse of all worlds. You’re spending more than baremetal, you’re spending just as much on maintenance and management instead of letting someone else do the “undifferentiated heavy lifting” and your developers are moving slower than they would have if they took advantage of your cloud vendors offerings.

Win????

You can't just "move to the cloud" by firing Ops people and giving an AWS account to your Devs.

Or, well, you can, but then don't forget to set your billing limit to infinity as well. Because AWS wants to make money.

Anyway, I'm not saying RDS/Aurora/etc. is bad, but eventually the heavy lifting will be available for anyone ( https://github.com/beekhof/rss-operator and similar projects ), and it's not like AWS likes to pay when they don't perform according to their SLA.

There is more to the cloud than “managed Kubernetes”.

While you can’t fire all of your ops you can reduce the headcount by a combination of managed services/servers, automation, outsourcing to managed service providers, and an auto healing fault tolerant infrastructure

> It's just that there's no intrinsic reason that the same company that gives away labour as OSS should also make the best complements to that OSS.

AWS's version will likely always lag on features, whether it's their Elasticsearch service or this new DocumentDB thing. So to continue the music industry analogy from the original article, sure Taylor Swift may or may not be able run the most reliable streaming service but she'll still get business if Spotify/Pandora only has covers of her songs.

A closer analogy would be “Spotify/Pandora cannot stream new albums for a period of X months” since AWS has the option to develop the missing features, and will if they’re requested by enough customers (AWS is extremely pragmatic when it comes to product roadmap). So, to strain the music analogy further: if you’re happy with the back catalog and you can wait a little bit to listen to the latest songs (say, while others test if they’re any good) then you don’t have to put up with the unreliable streaming service.

IIRC this strategy was tested by Jay-Z with little success. Taylor Swift also came back to Spotify...

> Open source software is by definition commoditized.

I thought commodity means something that can be produced by many different companies without substantial differences in cost, quality, functionality etc.

Open source software usually is siganificant in their complexity and utility. Also they have strong gluing effect to customers' own code.

To say they are commodity in the sense that they are free of charge, seems not the right way of thinking them as commodity.

You can't treat open source software as a commodity but you can treat any version of open source software as a commodity.

i.e. debian and ubuntu may not be interchangable commodities but ubuntu 16.04 from a torrent vs given from a friend vs downloaded from a mirror are interchangeable.

The services around opensource software such as troubleshooting or being able to spin up a server without having to supply anything but a password (and cash) are what makes a specific version differentiable, not who supplied the bits of that version. Since opensource is free and anyone can distribute it any 1 version is a commodity.