4 ms·

They should still file bugs and ping the maintainers, at least.

by sayrer 15y ago

pbiggar 15y ago
I agree that would be the right way to do it, and I'm sure that we [1] would have done it that way. There is a certain shoot-first-ask-questions-later approach to forking that, while unpleasant, is certainly effective. There are two ways Google could have gone: 1) Talk to Apple, file bugs, wait around for a year to see if anything is being done. Then threaten to fork, but wait when Apple says they're doing it, but they're really not, they're just trying to avoid a fork. Or worse, Apple would simply refuse, saying that it wasn't a good direction for the SunSpider benchmarks to go, which would be legitimate. Then Google is stuck with worse V8 scores forever. 2) Just fork it. They didn't cite a reason, but when asked they no doubt have a few up their sleeves. Now Apple is on the back foot, doesn't have a plan, and perhaps has lost maintainership of SunSpider forever. From a public perception point of view, this is a real winner for Google. They have better open source cred than Apple [2], and they keep V8 up-to-date pretty well. I would be unsurprised if people started reporting the forked scores from now on. That will probably depend on how they steward the project, for example by doing some trivial maintenance like the bugs we've reported on SunSpider. While I don't agree with this approach, I can see how it achieves their aims better. It's reminiscent of the launch of V8 or Google code, where the surprise is used to spur competition from the incumbents. With luck, Apple will update SunSpider like they suggested they would in 2009, there'll be a merge, everything will be forgiven, and JS benchmarking will be better. [1] for those watching at home, sayrer and I both work on the JS team at Mozilla [3] (he's actually my boss). [2] Google may have a closed development model for the V8 engine, but that's par for the course with Apple. [3] Nothing I say represents Mozilla, etc, etc.

They should still file bugs and ping the maintainers, at least.

by sayrer 15y ago

They should still file bugs and ping the maintainers, at least.

I agree that would be the right way to do it, and I'm sure that we [1] would have done it that way. There is a certain shoot-first-ask-questions-later approach to forking that, while unpleasant, is certainly effective. There are two ways Google could have gone: 1) Talk to Apple, file bugs, wait around for a year to see if anything is being done. Then threaten to fork, but wait when Apple says they're doing it, but they're really not, they're just trying to avoid a fork. Or worse, Apple would simply refuse, saying that it wasn't a good direction for the SunSpider benchmarks to go, which would be legitimate. Then Google is stuck with worse V8 scores forever. 2) Just fork it. They didn't cite a reason, but when asked they no doubt have a few up their sleeves. Now Apple is on the back foot, doesn't have a plan, and perhaps has lost maintainership of SunSpider forever. From a public perception point of view, this is a real winner for Google. They have better open source cred than Apple [2], and they keep V8 up-to-date pretty well. I would be unsurprised if people started reporting the forked scores from now on. That will probably depend on how they steward the project, for example by doing some trivial maintenance like the bugs we've reported on SunSpider. While I don't agree with this approach, I can see how it achieves their aims better. It's reminiscent of the launch of V8 or Google code, where the surprise is used to spur competition from the incumbents. With luck, Apple will update SunSpider like they suggested they would in 2009, there'll be a merge, everything will be forgiven, and JS benchmarking will be better. [1] for those watching at home, sayrer and I both work on the JS team at Mozilla [3] (he's actually my boss). [2] Google may have a closed development model for the V8 engine, but that's par for the course with Apple. [3] Nothing I say represents Mozilla, etc, etc.