I suspect actually security is the issue here. Since the launcher is a WIP, it might not be as nicely decoupled from the underlying security stuff as would be necessary for people to start building their own launchers on top of it (or to safely open source it)
Let's wait till the official launcher is actually completed (and the various internal API's finalised / not subject to change) before thinking about mods and open sourcing.
I think open sourcing the launcher should be a goal. Not necessarily this instant but they should work towards it. There should be no reason not to open source it. From a overall design point of view. Assuming they do not have the store integrated into the launcher and things like that. Which I would think is not ideal anyway, and should be separated so this can be done.
In fact now that I think of it there is really no reason for the store not to be open sourced either. There is no security issues with downloading or paying for games. That is all handled in another api. But at the very least I want the base launcher.
I would like to hear from someone on ouya though if they will eventually do this.
The biggest problem with open sourcing things too early is forking. When some code is under heavy internal development and there's an open source repository for the project, there's a danger that peoples patches to the open source code will become out of sync with internal development and end up being discarded.
It's in everyones interest to ensure that code is open sourced at the right time; That's a time when the code has reached a state where it's largely stable and people taking a week or more to create patches is not as big an issue as if the code is changing daily.
You may not see every part of every change a release, but sometimes you'll see functionality take what appears to be a big leap which may, in fact, be just the visual components being implemented of a larger, longer running, set of changes.
Afaik it's still the plan to open source the launcher, the issue is when it makes sense.
The biggest problem with companies hesitated to open-source some kind of technology is that they think a fork is an issue. Actually it is not. That's just how open source works. No worries, just do it. If there will be a better fork, you still have the possibility to merge the good parts into the mainline. These companies need to change minds. It's like in The Matrix movie - the skyscaper jump scene.
We, at Red Hat, made the jump long long time ago... ;-)
The biggest problem with open sourcing things too early is forking. When some code is under heavy internal development and there's an open source repository for the project, there's a danger that peoples patches to the open source code will become out of sync with internal development and end up being discarded.
I suspect actually security is the issue here. Since the launcher is a WIP, it might not be as nicely decoupled from the underlying security stuff as would be necessary for people to start building their own launchers on top of it (or to safely open source it)
That's actually the exact opposite of the right way to think about it. It may seem counterintuitive, but the best possible thing the team could do for security is to open up the code for the security APIs. The concept behind this idea is known as Kerckhoffs's principle, and it's an important, well-known principle in computer security: if you can't trust a system to be secure when everything about it is publicly known except the key, you can't trust a system to be secure, period.
greeniekin
Posts: 92Member
Comments
Let's wait till the official launcher is actually completed (and the various internal API's finalised / not subject to change) before thinking about mods and open sourcing.
Website
I would like to hear from someone on ouya though if they will eventually do this.
Android Specialist
OUYA
Therefore, making the security API open-source cannot make the system less secure; all it can do is expose existing security holes. And with developers and end-users who care about the security of the system able to watch and examine the code for security holes, bugs will be found faster (and reported, rather than exploited while the team is kept in the dark,) and fixed faster.