Opinion: Never build upon closed-source frameworks

[In this reprinted #altdevblogaday opinion piece, CCP's lead technical artist Rob Galanakis offers an argument for why you should never build upon closed-source frameworks.] A poster on tech-artists.org who is using Autodesk's CAT asks:

He already hinted at the answer in the same post:

So there's your answer.

It's true of CAT, it's true of everything. And in fact, it is one reason I'll never go back to developing with .NET on Windows. If you don't have the source for something, you 1) will never fully understand it, and 2) never be able to sustain your use of it. When I was at BioWare Austin, and the Edmonton guys decided to switch to CAT, I was up in arms for exactly this reason. We had an aging framework, PuppetShop, but it worked well enough, we had the source, and acceptable levels of support (Kees, the author, is/was readily available). Instead, they switched to a closed-source product (CAT) from a vendor that has repeatedly showcased its awful support (Autodesk), and headache ensued. Fortunately I never had to deal with it and left some months after that. Without the source, you're dependent upon someone whose job it is to provide support just good enough so you don't leave their product (which is difficult since they own everything), and bad enough that you have to hire them to fix problems (they pride themselves on this level of support, which I call extortion). As for the ubiquitous and proven part: unless this closed source solution is incredibly widespread (think Max/Maya, some engines or middleware, etc.), and has a lot of involved power users (i.e., Biped is widespread but difficult to get good community support for because it attracts so many novices), it means you have to figure out every single workaround because you can't actually fix the problem because you don't have source. Imagine working with no Google -- that's what you give up when you use a closed-source framework that isn't an industry standard. So don't do it. Don't let others do it. If you're currently doing it, think about getting the source, and if you can't do that, start making a backup plan. Addendum: I should clarify, there is a difference between "using" and "building upon." Using a physics or sound library is usually not "building upon." Using Unreal 3 would be. How much work are you doing that directly deals with and extends the framework (build upon it), and how much of it is just calling library functions and putting your own interface around it ("using" the framework). I have no problem "using" closed-source frameworks, even if they're a bit unproven but novel, if you can replace it relatively easily. However if you'd basically have to redo all the work done so far to change it (as you would in this example), then my advice holds. [This piece was reprinted from #AltDevBlogADay, a shared blog initiative started by @mike_acton devoted to giving game developers of all disciplines a place to motivate each other to write regularly about their personal game development passions.]