The Customization Curve
blog.ycombinator.com
blog.ycombinator.com
And IDK why the middle is lower than the left side.
Not disputing his point, but I agree, the graph is confusing.
Their last license sold was about 5 years ago.
But probably making more money than they ever planned to make with the product (the product was planned as a lifestyle business, not a startup - say they never tried to look for any funding).
There is a bit of manufacturing philosophy that I find relevant here.
You can build an efficient factory that makes a large number of identical widgets at a price competitors can't beat, or you can make a factory that makes small batches of custom order widgets at prices competitors can't beat.
However, when you try to build a factory that does both well, you'll end up with a price point that is no longer competitive.
In software, it is very similar. You can stick to a model, or you can spend your time customizing, but if you try to do both you'll end up with an unmanageable code base. This will eventually lead to rising costs and a lost competitive edge.
Is chromium too customized for example? There's lots of toggles, options, command lines switches and a whole web extension subsystem.
Low happiness --> low customization
Medium happiness --> minimal customization
Infinite happiness --> infinite customization
High happiness --> moderate customization
With the interesting bit being the balancing act around "moderate customization", "high happiness", and "sustainable amount of work".
I am not sure this is true at all for any scale of organization. It's certainly much easier to prototype a service and provide it to a customer than modify and release code for just one customer.
Then you have a base product you market to new customers and a developing marketplace of plugins which you can likely sell for a lot if your product is focused well enough.
Before deciding to build a plugin system, you need to decide in which dimensions it will allow extensibility. The answer to that should not be 'all of them', because then you've just badly reinvented a general purpose programming language without the tooling and with more awkwardness (c.f. Spring).
Plugin systems also increase code complexity. Extensible software is usually slower and less reliable than software which doesn't, even before you actually add any extensions.
Lastly, software has to have a big enough market of developers to create and maintain the plugins. So this works well for e.g. Emacs, but for each success story they are more specialized or less popular tools with a failed plugin ecosystem.
Consider Mediawiki as a cautionary tale. It's a big, popular piece of software with a lot of extensions. Most of them are unfinished, unmaintained, untested, insecure.
Take men's suits. It's saying fully bespoke isn't a sustainable business model. Made-to-measure might or might not be (depending on which side of the line) but it isn't going to make your customers ecstatic, just a little happier than off the shelf.
One odd thing, is it seems to start by trending downwards. Not sure if that was intentional.