[danmaz74]

A very nice property of open source software is that you can fork it, "show that it can be done" without having to start from scratch, and if the results are provably better, get your approach adopted.

The trickiest part is the proving that the different approach technology is enough better to warrant a switch. Very often, new approaches don't live up to expectations (not saying this is the case for the tech you're talking about).

[pcwalton]

1. This is actually discouraged for many projects (e.g. LLVM), because of the possibility that someone does a lot of work and then their results are not accepted.

2. The issues here don't have to do with whether the technology "works" (it does), but rather "developer velocity" and other more social/political concerns.

[danmaz74]

I understand your points, but I would suggest to consider a different point of view:

1. When you're experimenting with a seriously new technology or approach, the most likely outcome is that you'll fail, especially at the market adoption level. Being able to conduct your experiment at a lower cost is still a net positive, except for one point: having invested less, you are more likely to abandon the experiment early, because of the sunken costs fallacy. That doesn't necessarily need to be the case.

2. Developer velocity/productivity is something that you can demonstrate - as long as the difference is consistent, like, not 10% faster, but 80% faster. Other social/political concerns are a different thing, but really, gaining market adoption based only on those is VERY difficult - if that wasn't the case, I don't think we would be having this discussion at all, because Firefox would have a much higher penetration.

So, the point is, how is having a completely separate codebase going to help with having success? It could attract a higher number of idealistic developers, but the additional work required is very likely to negate that advantage.