- Joined
- Apr 7, 2025
He knows, but busy and he's too close with the publishers (though his opinion on the matter is sympathetic to the cause). Romero knows but is wary of the drama from sloptubers, and also busy with his new studio.
For the record, both of them especially Carmack are heavily involved at the publisher level of the industry. If they released anything on the #SKG initiative it would be a LinkdIn post filtered through PR so as not to upset the apple cart. They're stuck between a rock and a hard place, same reason Gabe hasn't made a statement either despite his support for the initiative.
Carmack has commented on this before however:
Quote (emphasis added):
I reached out to Boz as soon as I heard about the end-of-life announcement for Echo. We have been over similar discussions in the past — I thought it was a mistake to not keep Oculus Rooms running and port to Quest, and I thought it was a mistake to abandon all the GearVR/Go content when my emulation layer worked for at least a good chunk of things. I believe in saving everything.
Even if there are only ten thousand active users, destroying that user value should be avoided if possible. Your company suffers more harm when you take away something dear to a user than you gain in benefit by providing something equally valuable to them or others. User value is my number one talking point by far, but “focus” is pretty high up there as well, and opportunity cost is a real thing.
I think there is likely a degree of motivated reasoning internally that tilts the table towards “just kill it”, but it is challenging to argue for alternatives, and I thought Boz’s statement was honest and true. Boz gave the greenlight for releasing the Oculus Go root build that I had long agitated for, but after seeing how much internal effort was involved to make it happen, I almost felt bad about it. The constraints are just different in a company the size of Meta.
I can make a case for several possible options:
Drop to absolutely minimal support. Put a single developer in charge of maintaining it and doing what they can with the community. At Id Software, we had one guy managing Quake Live for a long time, and I think that was the right thing to do. This would almost certainly not “earn out” on a cost benefit analysis for Echo, but a lot of people are spent on worse things, and despite me always harping about efficiency, I would consider it justified for the intangibles.
Spin off the project. I suggested that they should see if anyone on the team wanted to leave Meta and take over the project. The team members can see the dashboards and make an evaluation on if there is any viable path for the game to support even one developer. There may be people internally that think the game development has been mismanaged, and there is a chance for a renaissance if different decisions are made. I suggested that they offer to sell the rights for $10k. Meta paid many millions of dollars to acquire Ready at Dawn, so that would be a bitter pill to swallow, but it would still be a net good for VR. Unfortunately, the process to spin something off is far from simple at Meta, and involves a lot of government oversight at this point.
A problem with both of those options is that there may be nobody with the skills interested in doing that. Shepherding a product through its twilight years is not the playbook for big tech career advancement. Game dev does have a different crowd, but there are a lot of incentives once you are inside Meta that start changing people’s thinking.
They could slap an “unsupported” banner on it, and just let it keep going until something dies, rather than explicitly killing it. As things rot, there would be more and more petitions and agitation to have just one engineer go in to make a simple little fix for whatever breaks, and it could wind up being more net animosity than just cleanly killing it.
Open source the project. This would double as a good developer example, although the Echo codebase is very different than Unity where most VR developers work. I never looked at the Echo codebase, but most large commercial codebases have various things in them that are licensed, rather than owned, so working around them can be a significant engineering task, and missing something can risk legal repercussions, so even putting out a non-functional partial dump is hazardous.
A small developer can, in theory, just stick a license comment header on all the files and throw the project on GitHub, but this rarely happens (to my sorrow!). The effort to do it at Meta, with all the legal and technical reviews, is much greater, and the hazards are much worse.
While this is foremost a business problem, there are still technical plays that can help in the future, and I encourage everyone, in and out of Meta, to think about them:
“Keeping things alive takes work” is true at some level, but it is possible to build systems that run untouched for years, and come up fine after a reboot. The default today may be a distributed mess of spaghetti, but that is a choice. A system that has been operating for years can take the path of evolving to greater robustness each time an issue manifests.
Every game should make sure they still work at some level without central server support. Even when not looking at end of life concerns, being able to work when the internet is down is valuable. If you can support some level of LAN play for a multiplayer game, the door is at least open for people to write proxies in the future. Supporting user-run servers as an option can actually save on hosting costs, and also opens up various community creative avenues.
Be disciplined about your build processes and what you put in your source tree, so there is at least the possibility of making the project open source. Think twice before adding dependencies that you can’t redistribute, and consider testing with stubbed out versions of the things you do use. Don’t do things in your code that wouldn’t be acceptable for the whole world to see. Most of game development is a panicky rush to make things stop falling apart long enough to ship, so it can be hard to dedicated time to fundamental software engineering, but there is a satisfaction to it, and it can pay off with less problematic late stage development.
Last edited:
