|
|
|
|
|
|
by Wowfunhappy
704 days ago
|
|
|
> 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. |
|
|
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.