| The biggest example is SQLite. It's public domain [0], yet its secret sauce is how the developers know, develop and test the software. They do not accept outside patches, which is not against Free Software, it's more like a cathedral, but it's not "not open source". > ...It's not obvious to me that the person who originally wrote the software is necessarily better positioned to support the software. Let's take an example. Scientific software. Something like OpenFOAM, or some simulation code. Open it with GPL, everybody has the source code, but only the developers know the intricacies of material simulation, the fragile math of it, how to optimize it, how to test it. You can fork it to infinity, but unless somebody has the expertise to understand the science of it, nobody can do anything with it, maybe besides breaking it in subtle ways making things worse. > Another party could build a business as the premier support consultants without most of the original developer's startup costs. When you have good enough product with tons of implicit knowledge buried in its source code (see above), it's not easy as it sounds. Many people write CRUD software, and CRUD software has no effective moat. It's just DB dressing and some automation. Start to blend in domain specific knowledge into it, and now we're talking. [0]: https://www.sqlite.org/copyright.html |
I don't doubt that it's hard. But I'm not convinced that it's harder than writing the software in the first place, so that is still a major savings for the competitor (which they could then use to undercut in terms of rates, etc).
As a point of comparison, let's say that SQLite's development team all died in a plane crash. Would a new team throw out SQLite's codebase and start from scratch, because they could never hope to understand the old code as well as something they wrote themselves? No—they'd review the code and documentation and bring themselves up to speed. Maybe they're never 100% as good as the first team, but they'd be quite capable.