Hacker News Reader

Comment by Wowfunhappy | Hacker News Reader

> OTOH, the harder (but better in the long run) way to create value with FOSS and Free Software particular to have stellar support and reliability. i.e.: Your code can be deployed, compiled, or built upon, but you're the best source to get the software in the first place.

...It's not obvious to me that the person who originally wrote the software is necessarily better positioned to support the software. Everyone has the current source code, so from that standpoint it's a level playing field. Another party could come in and build a business as the premier support consultants without most of the original developer's startup costs.

Now, I'm not sure if this has ever actually happened. If it hasn't, maybe I'm wrong. I would like to be wrong.

View on HN

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

> 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.

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.

> but they'd be quite capable.

That's the thing. They won't have the same shared vision and abstract model and roadmap of SQLite to begin with.

Let's take more examples: Audacious, GIMP, Darktable, DigiKam, Inkscape, KiCAD, Blender... Why these programs are not forked, or forked successfully? These are not niche programs. They are standard tools for some people. The thing is, all of these tools require very deep knowledge about some obscure and hard subjects. Some groups may take them over, but they can't just continue them as is. They will break things, or need to relearn tons of theory and their numerical versions which can be applied in programming languages.

I did my Ph.D. in SWE, writing a material forming simulator. Boundary Element Method more specifically. You can't expect a group of people just to say "Meh, let's fork something like this and just be better". You can't. You need to know deep numerical math, theory of BEM, need to build the formulae, and know enough CS + numerical linear algebra to transform that math to computer code.

I spent 7 years to build one from scratch. Not all applications can be transferred to a new team in two weeks flat. KiCAD is in development for 30+ years, for example.

> Now, I'm not sure if this has ever actually happened. If it hasn't, maybe I'm wrong. I would like to be wrong.

It has. As a popular example, Percona are among the best consultants on MySQL/MariaDB/MongoDB/databases in general, and they are not related to any of those projects (one of the founders of Percona used to work at MySQL decades ago).

> and build a business as the premier support consultants without most of the original developer's startup costs

I think a real world example for this would be https://www.collaboraoffice.com/about-us/. And looking at it from the outside a positive example as well. At least I could not find any public beef between collabora and the document foundation (as the organisation behind libreoffice).

Collabora guys push tons of code back to LibreOffice, too, as far as I can remember.

It's not necessarily about being better. Sometimes a competitor can beat you just by being cheaper, or by being better connected.

One example is that the Matrix project recently took a budget hit when the core team apparently lost a big bid to a "large system integrator" who seems to have used their own open source code to bid against them.

Sadly this wasn't a one off - Element has repeatedly lost deals to larger SIs who take our own FOSS software and compete with us with it, and win because they are better connected and don't have any of the costs of actually maintaining the software and so can charge a lower price. Hence shifting to AGPL to make it less desirable for SIs to commercialise us without first agreeing an AGPL exception.

A better approach would be if the purchaser mandated that the upstream project has to participate in the deal rather than being disintermediated by the SI, but we've seen very few instances of that happening.

Reply on news.ycombinator.com