I've wondered about the possibilities of closed ecosystems paradoxically making it easier to open source your software and still make a profit.
There's still risk to your bottom line by open-sourcing: a competitor could use your code/ideas to create products that outsell yours. But what you don't have to worry about is piracy: the number of users with jailbroken devices or a dev certificate are a small subset of your user base.
On the positive side, you get the benefit of customer engagement: people helping you bug-fix, creating level editors, community content, etc. Companies can also sometimes find and hire top-tier talent this way.
At any rate, major kudos to Insurgent for doing this. I'm actually a little disappointed that all their games are free; I think at the very least, they should pick their best game and charge 99c, or do split Lite/Full versions.
None of those things just automatically happen once a project is open sourced. The project has to be respected, known about, and generally desired. And if you've got those things, then you will probably be successful with your project, whether it's open source or not.
Has anyone proven that open-sourcing leads to profit loss from competition? I was on one of the dozen Stack-Exchange competitors today and it made me wonder. Stack-Exchange isn't open source, yet plenty copied.
Opensource is very much welcome. But I have a doubt here. Can some one take their lets a simple "Alphabet Block game" ..do some minor modifications for UI or add simple features and submit to Apple for free/99cents?? If this is the case it will clearly affect insurgents sales right? Is it a service they are doing or they are expecting developers to fix issues or enhance the games ...what could be their main motive.
You should read the post before commenting. They're not selling any games anymore, they're open sourcing everything. So how would it affect sales? And yes, you can, but if you take their code, fix it or whatever and then sell it you will still have to provide the modified code under GPL since the original was licensed to you under GPL. But as long as you do that you _can_ charge for the distributable of course.
perhaps the alternative you are looking for is making parts of the software easy to access allowing huge mods to be made through modification of the mechanics. Its probably why skyrim will be playable for the next 5+ years due to the thousands of mods that are already available bringing even more content in..
This allows aspiring game developers to learn and build their own games from the code.
All the repositories are GPL'd, so I'm assuming they meant build in a purely educational setting.
It's a nice move, but why not go all the way and let developers leverage your code in their proprietary code? Insurgent Games only open sourced once they gave up, so they clearly know that open sourcing all your code is not a good idea when you're selling games.
Perhaps they don't want others to hide their improvements and simply released the code to foster learning and collaboration. Id software uses GPL for their game engine releases as well. So I'm sure they both have their reasons.
License
-------
This game is licensed under the GNU General Public License (see gpl.txt). As the copyright owner, I hereby give anyone permission to re-license my GPL code under a non-GPL license for the purpose of distributing it in the iOS App Store or the Android Market.
This is not what you think it is. This is necessary because GPL is incompatible with App Store. (It doesn't seem to be rigorously enforced, but search for "GNU Go App Store".)
> Insurgent Games only open sourced once they gave up, so they clearly know that open sourcing all your code is not a good idea when you're selling games.
To be a bit pedantic, all you can really say is that they didn't know whether open sourcing your code is a good idea when you're selling games. I could imagine myself being convinced that having open sourced a game makes you no more or less likely to lose market share to copycats than keeping it closed. I don't know that anyone's tried it, nor that there's a particularly good experiment one could do to test that.
"All the repositories are GPL'd, so I'm assuming they meant build in a purely educational setting."
Um, how about in a hobbyist setting?
Only a small subset of the people who write games are going to make money doing so. Many of them know this and do it just because they enjoy it. (See: Almost any mod community.)
Actually games are almost completely unaffected by open sourcing the code. The value in 99% of games is in the level design/art/music assets which can be kept proprietary. It even maintains the spirit of the Four Freedoms.
Does anyone believe being selective about what you open source is a bad idea? If so could you share your perspective? (I'm asking as I'm guessing that may be why I got voted down)
I think the answer, as usual, is "it depends". It can be bad when the open-source portion relies heavily on the closed-source components to function properly. One example: when Linksys was required to release their Linux-based router firmware, the wireless driver stayed closed-source. This effectively forced the use of 2.4 kernels for years, until a suitable substitute was developed. This exact situation is happening with Android: building a functional version for real hardware requires a large number of closed-source components, and they are a pain.
I think it'd be interesting if everyone did this with their failed side projects, at that point when they realize there's no value in continuing down their path. Bravo guys.
It is this type of attitude that stops other people from doing what they have done.
Sometimes bad code is fine when you are prototyping something or getting something to just work. Sometimes people have knowledge gaps. Put your code up or shut up.
Obviously I can't speak for the original poster's intentions, but I figured it was just meant as a helpful reminder that parts of the code shouldn't be considered "best practise".
It's great that they post code - it's just that newcomers might look at it, think "oh hey this might look like an OK way to do XYZ" - and then be surprised later when new iOS versions or whatever break because of shortcuts taken earlier.
A gentle reminder that "this is not necessarily the proper way to do it" is appropriate in this context, I think.
(I'm sure issues like these are common for many studios' games)
My comment was not meant to be insulting or anything like that. I just tried to be direct - thats all. The linked website says:
"This allows aspiring game developers to learn and build their own games from the code."
I had a look at the source code and what I found were mistakes that are made by absolute beginners of Objective-C. I am not talking about things like spaghetti code or bad variable names. I am talking about real WTFs here.
Everyone can put up code on Github but then you have to live with the fact that people are pointing out flaws - especially if you encourage other people to learn from the code you put up.
It would be much more positive and educational (and therefor more useful) if you pointed out some specific errors and their fixes, so people could learn something. What you're doing here is fair warning to people working off this code, but w/o adding some useful info it comes of as mere trash talking.
Weren't there some issues with GPL'd code being on the App Store? If I remember correctly, one developer complaining about the license was all it took for Apple to pull VLC.
Still, it hopefully won't be an issue here, and this is still a really awesome thing to do.
The issue with GPL code and the App Store is that the way the App Store works, Apple makes and distributes copies of your executable code when you make an app available through the store. If you own all the code in your app, that is no problem. When you submit the app to Apple, you are giving them permission to make and distribute copies.
This works even if your code is GPL. Even though the terms Apple imposes on those who obtain software from the App Store are against the GPL, that doesn't matter in this case, because Apple isn't relying on GPL for permission to distribute. They are relying on the license you give them as part of submitting the app.
In other words, when you put GPL code THAT YOU OWN on the App Store, you are actually dual licensing it--GPL for the world, and a special license for Apple.
The problem arises when you do NOT own all the code in your app. Then you need to make sure that the owners of the code that isn't yours give Apple permission to make and distribute copies of their code.
This is what brought down VLC. The people that made the app owned some of the code, but not all of it. They were only able to dual license the code that they owned. One of the owners of some of that other code was not willing to dual license it. He was only willing to distribute under GPL.
As far as I know, Apple presumes that the submitter of an app has all the licensing details worked out. They only pull an app if someone with standing complains.
Putting that all together for the Insurgent Games code:
1. Their repositories include library code that they do not own. I looked at a few of these, and they seemed to be under permissive licenses, so they should be no problem if you wish to use them in a game.
2. The Insurgent Games code that they own is under GPL. Like any other code that you don't own, if you use it in your app and try to put it on the App Store, you need to arrange for a license that allows Apple to distribute.
Presumably Insurgent Games does not have a philosophical objection to the App Store, so if you just went ahead and used their code in your game there's probably a decent chance they would not object. However, it would be best to clarify this with them.
If they do intend to allow people to use their code in apps on the App Store it would have been better for them to use GPL with an exception for this rather than straight GPL. If they do NOT want to allow this they should add a note in the README saying so.
3. Keep the above in mind if you build a game using some of the Insurgent Games code, but bring in outside GPL code. You'll need to make sure the owner of that outside code is OK with App Store distribution if you are going to distribute your app that way.
I'm the developer from Insurgent Games. Thanks for explaining the licensing details so well. I've just updated the readme in all git repos at https://github.com/insurgentgames to include a licensing block that says:
This game is licensed under the GNU General Public License (see gpl.txt). As the copyright owner, I hereby give anyone permission to re-license my GPL code under a non-GPL license for the purpose of distributing it in the iOS App Store or the Android Market.
So people are welcome to fork my project and still publish in the App Store without even having to contact me.
I think one of the difficulties is just getting people to notice one's apps; I hadn't heard of you guys before, but am downloading now :)
Would you be willing to write up a retrospective? You guys have made quite a few games, so hearing your experiences in development and what worked/didn't from the business side would be interesting.
I want the games to be under the GPL so that derivate work has to remain open source. But to have GPL apps in the App Store you need permission from all copyright owners. If someone forms Skeleton Key and releases their own version in the App Store, they need my permission since I'm one of the copyright owners.
So I just me giving my permission before anyone has to ask, but only for the purpose of App Store distribution. They're not allowed to re-license my code as proprietary for any other purpose.
I've only tinkered with objective-C and I'm not even comfortable saying I "know" the language, but does anyone else think some of this code is surprisingly concise?
I tried Alphabet Blocks and Cryptose just now. Cryptose is rather fun, but the visual design could stand improvement.
It would be interesting to repackage these games with better eye-candy and compare sales figures to Insurgent's, if:
- Insurgent's sales figures were public
- one could account for the effects of more devices sold since 2009/much greater competition since 2009.
In all seriousness, I wish more defunct software companies would do this. Or better yet, I wish thriving companies would do this with their old programs, like ID Software and how they've released the source to Doom and Quake.
So did I and I also thought they would be funded by Sequoia Capital, because a user sequoia posted this. Oh well, now that I think about it, it was kind of unlikely.
At 99c though, do you expect the software that you're purchasing to be bug free? For apps that I've done I've skipped a lot of formal testing. I know the user base will be small enough to not mind the occasional bug, and if the apps do become popular then I'll invest the time to add some.
For iOS, since the release of Xcode 4.0, the built in unit testing capabilities of SenTestKit have proven to be adequate for me. Before Xcode 4.0, the configuration required to get unit tests up and running and debuggable was quite painful, but it is now as simple as choosing to add a unit test target to your project...
Im a primarily a web developer and unit testing is much easier in modern web frameworks than it is in Objective C or Android's VM for that matter, but Im a firm believer that if you have no test coverage whatsoever in your code it shows how important code quality is to you as a developer.
Again, unit testing on mobile platforms is not as easy as doing it in ROR or Javascript nowadays, but there are still frameworks that simplify it tremendously, particularly those from Pivotal Labs.
I'm not so sure that a comprehensive test coverage is beneficial for a product like a game which is not really maintained over a long time period. Imo the biggest benefit of unit tests is for catching regressions, but a game you get working once and then you're done. Especially for smaller casual games I don't think that it's necessarily worth the effort to write comprehensive tests. Also, as Dijkstra already said, testing is inadequate. It can only show the presence of bugs, never their absence, so even if you have 100% test coverage it really says nothing about the quality of your code or how much you care about it.
Real automated testing in games is rare and never even close to comprehensive. Honestly, I'm amazed when I see game codebases that do have substantial tests.
There's still risk to your bottom line by open-sourcing: a competitor could use your code/ideas to create products that outsell yours. But what you don't have to worry about is piracy: the number of users with jailbroken devices or a dev certificate are a small subset of your user base.
On the positive side, you get the benefit of customer engagement: people helping you bug-fix, creating level editors, community content, etc. Companies can also sometimes find and hire top-tier talent this way.
At any rate, major kudos to Insurgent for doing this. I'm actually a little disappointed that all their games are free; I think at the very least, they should pick their best game and charge 99c, or do split Lite/Full versions.