 |
With a variation on The Chain of Trust and The single mole theory, an open source project can halt and slow other projects, allowing a commercial project to dominate a problem-domain.
See also:
-
The moving target that is Open Source
- An earlier and more naive perspective.
Most open source software projects begin as an “itch” that its (usually single) developer has. They have a problem they need solved, so they write software to do that, and they share it. There are cases where a company has staff who collaborate and then that is released to the public, but the source doesn’t matter for me here.
A piece of software which is out “in the wild” also acts to solve the same “itch” which others have. Instead of those others programming their own solution, they use or adapt that existing one. What the initial project has done is to block the creation of peer-programs working toward addressing similar problems.
When a solution to a problem exists, there’s no need to reach for other solutions, right? This is somewhat true in the short run, but it is not true in the long run. Scope creep usually make a project reach for related problems to solve, or it doesn’t “fully solve” the problem that other users have. It may have been good enough, but the more attention it gets is the more likely that other developers will want to extend it.
There is a breaking point for the use of a single problem-solver project. Being pulled in multiple directions, fundamental philosophy differences, library differences, license differences, personality clashing and who knows what else will have another project spun off that, in a sense, “duplicates effort”.
However, this doesn’t always happen. Perhaps the problem is not popular enough to attract the attention of people who would be willing to create a whole new project. In a sense, a half-solution ends up being the only one anyone has reasonable access to, and its existence has blocked the creation of some other solution which might have been better.
Or perhaps a project is very difficult and its problem domain is very large, and so a single developer or small team could not tackle it well enough for it to compete with that existing, albeit imperfect, other project.
A project can therefore be created or manipulated specifically to disrupt the creation of other competent projects. That project can even be supported to make it simultaneously out-compete other projects. Mozilla’s projects (especially Firefox) are a perfect example of this. Huge, slow, philosophically-corrupt yet so good as to be responsible for years of delay on other projects which would have come out.
Even when a faltering project exists, the time it has existed has allowed it to scope-creep and otherwise “improve” enough to become a large and intimidating project for another project to rise to compete with it.
An open source project could be intentionally created and/or corrupted so that the ideas can be given a hamster wheel to run on. Projects can be quietly killed as time progresses and when interest wanes, or they can be maintained indefinitely with some insiders dragging their feet, bloating it, etc. Imagine founding a company that makes a web browser, making it big and popular, making it huge and featureful and bloated and very slow to develop. Give it security flaws that get updated quickly, but mis-features that aren’t. All the while create commercial software that sweeps in and utterly dominates in comparison. That corrupted project has allowed for private parallel-development for that problem-domain. That development can take advantage of the manipulation of the corrupted project to out-compete it. The corrupted project’s existence has intimidated peers, and it has become a single point of focus to manipulate to essentially hold back all competitors.
Hi, Chrome.
