OUYA is open… And we’re not just saying that. Since the beginning, we’ve wanted OUYA to be the most open game platform available. Don’t get me wrong, we love console games, but we believe they are suffering from the pandemic of the “closed” platform. Though there’s been a major democratization of computing power, development tools and engineering and design talent, publishing to the console has remained closed to most. As a result, gamers have fewer choices.

But what does it really mean to be “open”? For starters, we told you about some of our choices in our Kickstarter. Today, we’re taking another step.

After hashing out a business-as-usual proprietary license for our software development kit (the OUYA Development Kit — or “ODK”), we realized that there’s really no pressing business reason to protect the ODK. So we thought, “what the heck?” and decided to release it under a well-established free software license: Apache 2.0 (which also happens to be the same license that governs the Android operating system). Though the Apache 2.0 license limits how developers can use, for example, OUYA’s trademarks, it pretty much lets developers take the software and tools and make them their own.

We think we’ve got a great team of developers here at OUYA, but there’s strength in numbers and a wealth of passionate, talented people out there. We want you, the developers of the world, to work alongside us to continually improve our platform. It’s our hope that releasing a more open ODK will help foster such innovation.

Please note that we’re still working on releasing the source code for various elements of the ODK — and since some of it is compiled object code, you won’t have access (at least not today) to every single line we’ve written. We want to be sure things are in really great shape before we release code. Also, we will be holding back some sections of the code to preserve the security of OUYA, especially when it comes to payments for developers and gamers.

Still, we’ve already started to see the community building extensions to the OUYA platform itself. Of course, we will be maintaining and releasing the “official” ODK of record — but we’re excited to see great ideas flourish, making the console experience better in ways we never anticipated. Over time, the plan is to incorporate the best of these inventions into the core ODK. Stay tuned for details on that!

One more thing: It’s worth mentioning that “open” does not mean “anarchy” — and as we continue to build out OUYA’s core services, please know that not every facet of OUYA will be totally open. In order to ensure the best possible experience for our gamers and developers, for example, we will be screening games for copyrighted content and offensive material (which we’ll define under our developer guidelines), and we’ll make sure that OUYA is a secure place to discover great games and conduct business.

It seems like a lot — but it’s simple, really. We are open because we believe it’s the best way to create the console platform we always wanted: one where gamemakers have the freedom to publish great games, developers can create wonderful recombinations of the platform itself, and gamers can enjoy the most creative, immersive and fun gaming experiences anywhere.

Here’s to you in 2013!

Cheers,

Raf
@raffibag

Stan

Similar Posts

extend

“I normally don’t do interviews or write b...
DuxBanner

OUYA DevLog: Duxter
ftgDefault

OUYA Frees Two Games!
  • DrSulfurious

    This is amazing, I’m a huge fan of the OUYA since the launch of the Kickstarter, and this just keeps getting better and better. I think that with your shipping of the Developer Consoles and the Apache 2.0 licensed ODK you will get a lot of good attention, and will hopefully make the Ouya a bigger success. Can’t wait to see what the future holds.

    Keep it up, and best of luck!

  • DrSulfurious

    (P.s. send a devkit my way =D)

  • drunkpunk

    Very happy to read this. Having a console that I don’t have to violate the TOS on to have it do what I want is one of the main reasons I backed this project, and now you guys are ready to knock it out of the park! Keep on updating us on the progress!

  • Um, no

    You should have waited to post this until the sources are actually released.

    Right now, it’s as closed as any other proprietary platform and you’ve got nothing but a promise.

  • Dan

    Big, big fan of this post.

    “Open does not mean anarchy.” I’m glad to see you’re going to protect the core UX for those that simply want to enjoy great games.

    I was not a backer (silly of me, I know) but you can be sure I’ll be buying one of these devices in march. Kudos to all your hard work!!

  • Potential Developer

    So, where do I download the ODK? When will it be available? I don’t mind if the ODK includes proprietary binaries, so long as it is functional. Even though I don’t have a dev kit, I could be porting before March’13. Especially if the ODK includes an emulator (hint, hint).

  • Disappointed European

    Now I understand why you don’t want to release 100% of the code, that’s normal, ok. But screening software for offensive content? Oh this is so Apple. Or Google, they do the same thing. American is probably the right word. Enforce your morals on the rest of the world and decide for them what is acceptable and what isn’t. So we end up with another platform that bans and censors games that show a breast somewhere or mention the evil S word Americans think they’ll go to hell for hearing.

    So much for “open”.

    • Djungelurban

      I can’t say for certain of course, but I guessing (hoping) that by “offensive” material they mean like “white power” games and such… Like things that are just clearly evil… Not boobies… But we’ll see…

    • Farias

      I’m also against this “offensive content” talk. You can create something like partental control, but not close the doors to the software just because it can be offensive for some peoples. This way it will limit the developer’s creativity, and it’s all we don’t want, right?

    • Dallin

      I happen to agree with screening for offensive content. Every environment that allows offensive content finds it seeping into places it doesn’t belong. Even youtube is a little scary to visit now with the offensive comments and questionable and crass videos that you never know are coming before you watch them. It can become very hard to 1.) find out whether a game has offensive content beforehand and so you are surprised after buying it, 2) avoid the offensive content altogether in ads for the games, game descriptions, pictures, comments, etc., and 3.) keep your children from stumbling upon or getting tempted by the inappropriate content. I like the idea that it’s a family environment. If you want your porn, go to the internet, or at the very least, have it very, very, very blocked off for the normal person.

    • Martin

      Interesting blog and interesting to see so little respons came out here. My primairy reaction is in line with ‘Disappointed European’. I do have the trust though that the Ouya team will not be that conservative…

      I would like to see a second blogpost from the Ouya team in what is open and what is not. In the post there are some vague references to what is closed. I don’t mind if it is for good reason (like ‘Emmanuel Deloget’ is referring to), but I think being “open” also means clear communication about it. Especially since Ouya is mentioning this usp a lot. Waiting for part 2 ;)

  • http://blog.emmanueldeloget.com Emmanuel Deloget

    Hello,

    I’m pretty sure there must be some way to make IAP and any sensitive processing both secure and open. There are a few main issues :

    1) as a user, I don’t want my credential to be stolen by a malicious program/person.

    2) as a game developper, I don’t want any user to misuse the IAP in order to maliciously get credentials they are not allowed to get.

    3) as a user, I don’t want to have any (malicious) app/game buying something without my knowledge.

    Usual cryptography stuff can be used to mitigate risk (1) (SSL/TSL comes to mind, but be careful in implementing those as a bad implementation is as risky as no implementation at all).

    Point (2) can be mitigated by a serious, secure server-side system. DRM systems can help here. The real challenge is to make the process unbreakable by a malicious user (since you open both the hardware AND the software, this will be really tricky).

    Point (3) can be implemented by forcing the appearance of a screen or popup (something that cannot be disabled or hidden) with a clear meaning (“you are about to pay $X for some kind of content proposed by Company Y. Is it OK?”). This must be really robust – otherwise it could be quite easy to fool the user into thinking he pressed “no”.

    I would add point 3.5 (do not allow the installation of malicious apps) but that’s notoriously hard and malicious apps can assume multiple forms – including the form of genuine, safe apps or games that are approved by the app owner (Ouya).

    Point 1 is already covered by open source libraries (OpenSSL, GnuTLS…) so there is no need to protect that. You can find many implementation in the existing web browsers so hiding this won’t help much. Point 2 requires a protocol that can be easily checked and difficult (better : impossible) to subvert. Anything that runs on the user system must be considered as potentially harmfull (even if “a change of this value is not a security hasard”. It is – in unexpected ways). Since this is mostly a server-related issue, there is no need to protect the code (the protocol is important, but ingeniosity and a good packet sniffer will help to figure it out anyway).

    Point 3 requires the SDK / the OS to take precedence whenever something sensitive takes place. My preference would go to the system as it’s going to be more difficult to subvert that a userspace program that runs in the same process space (worse: in the same sandbox). Anything that must take procedence over the app code shall run outside the sandbox. If it does, then giving the source code won’t help the malicious app maker. If it does not then it’s going to be broken some day (remember that java code can be decompiled quite easily and that ARM ASM is not that difficult to understand ; sure, it may take time before someone finds a way to subvert the system – but when he will his “perfomance” may cost you far more than the money he’ll steal from your users).

    Best regards,

    — Emmanuel Deloget

  • Brandon

    cant wait for Ouya buying one day one cant wait for june!