Open Source is Hell
“Why hasn’t Cyan released the Plasma source code by now?”
Because, as RAWA explained, it’s a long, painful process. As RAWA somewhat implied, there are very few people at Cyan who even know anything about the engine code anymore. Most – if not all – of the Headspin team they bought the engine from have since left the company or been laid off. The number of “Don’t use this, we don’t know what it does” comments in the ResEng documentation I was given when I started there speaks volumes about how much work needs to go into the engine to get it ready for release.
Further, open-sourcing the engine as it stands now faces a number of additional issues. First, I’m under the impression that Cyan wants to separate the engine code from any game content that might be tied up in it, in order to retain legal rights to their D’ni universe intellectual property and released content. Given how often purpose-built engines have game content references hard-coded into them for the sake of convenience, this may be more likely than it seems. Second, I’m fairly certain that Cyan intends to continue using Plasma after they open-source it, so it must be done in a way that doesn’t prevent Cyan from using the engine commercially in the future. Third, there’s a number of proprietary components in the Plasma engine that are the property of third parties (PhysX is a good example), which Cyan can’t release the code for. However, stripping the references to that code out of the engine would make it essentially useless.
A good parallel to draw, I think, is to Relic’s decision about 5 years ago to open-source the engine they used to create the original Homeworld title in 1999. As with Plasma, everyone at the time was mind-boggled at the fact that a AAA game engine for a best-selling title was just going to be given away by its creators. However, to this day there still isn’t an openly available version of the engine that can be used for anything besides running an extremely buggy and feature-deprived build of Homeworld, because so much of the engine got crippled when Relic ripped out stuff like the Bink decoder used for the animatic cutscenes (which weren’t released along with the engine, so until the hard-coded references to them were removed from the engine, the game would just crash because of the missing assets), and there’s a pile of assembly code that just doesn’t work very well on modern hardware, including a lot of homebrewed custom OpenGL assembly code (dubbed “RelicGL”) that was written to get bare-metal access to the anemic or even non-existent graphics hardware available in 1999. Check out the Homesource forums for a taste of what fresh Hells Relic’s engine hath wrought.
So, if Relic’s approach can shed any light on this subject (and I think it can), throwing the code out now now now isn’t going to accomplish Cyan’s goals any faster than releasing the code at a later date, and is in all likelihood actually going to slow things down even further. I know there’s a lot of code monkey geniuses in the Myst community, but Plasma is a 15-year-old monster of an application, and more eyeballs on the problem doesn’t always mean faster results.
Which leads me to…
“Why won’t Cyan let trusted community members help get the code ready for release?”
As RAWA’s noted, and as many others have mentioned, there are a whole swarm of thorny legal issues involved with granting non-employees access to a proprietary code base full of more licensed proprietary third-party software, on top of the very probable situation that Cyan doesn’t have a system in place for allowing outside access to their Plasma code repository, it’s probably in a rather outdated source control system (perhaps even Visual Source Safe *shudder*), and compiling it may also require licenses for software that volunteers would need to be given (just as an example, anyone who’s tried to recompile a C++ VS6 or VS.NET project in VS08 should know it’s not likely to go smooth). Getting all of this set up, settling the hazy legal issues surrounding unpaid labor in the US, and drafting and issuing contracts and access permissions that are locked-down to only the relevant material is probably more trouble than it’s worth, honestly. Again, remember, this is a spare-time effort that Cyan can’t afford to expend valuable resources on when they’re needed elsewhere for other projects.
I also wouldn’t be surprised if Cyan is holding onto the code to try and hammer out some additional security issues, which they don’t want out in the open for discovery when they’re also running the only (legal *ahem*) active shard of the game on the planet. Given the (admittedly long-ago) history of outsider abuse of the Myst community (such as hacking the Riven Lyst), I would understand it if Cyan wasn’t willing to expose the Uru community to another outage resulting from someone exploiting the code’s most evident weaknesses. Considering the Vault always struck me as being held together with duct tape and bailing twine, I’d be willing to bet that there’s a lot that can go wrong very easily, and again, right or not, Cyan may just want to avoid that situation if at all possible by keeping the code internal for now (and please spare me the “security through obscurity” arguments, because they never seem to convince anyone in either direction).
And now, for my own petty comment: I also wouldn’t be surprised if the Uru hacking community’s tendency to do whatever they want with or without Cyan’s permission is putting Cyan off from being willing to accept their assistance. I applaud Paradox for actually working with Mark on the Pidgin KI plugin, and that sort of approach – independent development of tools and extensions with Cyan’s permission since it’s their property – if repeated elsewhere, could go a long way towards improving the apparent lack of interest on Cyan’s part towards the hacker community, and community involvement in general (assuming the aforementioned hurdles aren’t going to get in the way).