Monthly Archives: October 2010

Playing App Developer – Where to start

The mobile space just doesn’t seem to stop being more interesting by the day. It’s got me hooked, and I’m not sure why other than it’s fun to be a part of, even if it is in my hobby time. I keep trying to integrate it into my day job but it’s not clicking :). Instead, I am trying to become an amateur game developer in the few hours a week I get time for it at home. If nothing, it helps me feel a part of all the excitement.

As I march along my journey, it becomes quickly clear the first choice app developers face when getting in the game. Which mobile platform do I start with and what do I do about the others? From where I sit, the choice is obvious. I have an Android phone (actually I have two but my first one is a Roger’s HTC Dream that’s stuck on Android 1.5 which isn’t very useful), and since the SDK is freely available I am starting with that.

But I can’t ignore Apple’s iOS. It still is the mobile industry’s darling and likely will be for a long time. The problem there is that I don’t have a Mac which is a pretty high barrier to entry IMHO. But that’s OK. There seem to be a few people in the blogosphere who know how to get Mac OS X running in VirtualBox. But when it comes time to actually deliver something (assuming I ever get that far), you’ll need the real thing.

It’s pretty sad to see what’s happening to Symbian. I have friends with skin in that game so I’m not going to say much, other than I agree with the prognosticators. Throwing your product over the wall into the open doesn’t make it an instant success. At the end of the day, open source doesn’t win mindshare. Having low barrier to entry and a good chance of getting good volumes do. Symbian is a technically complicated app dev environment. Qt will make that better. But if you’re programming to Qt, then Symbian doesn’t matter much since MeeGo also runs Qt. Which makes MeeGo something to watch out for.

RIM is an interesting choice. But people don’t think of RIM phones as gaming devices. The new tablet might change that, but it’s not clear you can write native code for it, which, of course for me being CDT Doug, is a must.

And the same is true for Windows Phone 7. It appears you need to use C#, or at least managed code. I’ll need to dig into whether managed C++, if it even still exists, would work. But Microsoft is the king of walled gardens as much as we look at Apple today. But Microsoft also loves game developers, so we’ll see how that platform evolves.

So it’s an interesting array of choices and the pieces are all in motion and it’s a bit hard to guess how it’ll all turn out, which is why it’s fun to watch. Of course, I do need to mention that I’d prefer to use the Eclipse CDT and tools from the Eclipse ecosystem to build my game for all these platforms. But that is only slightly less disjoint than platforms are. As I’ve often said, I’d love to have a single Eclipse project with build configurations and debug integrations for all of these. That’s the vision, anyway. And playing in the mobile space has me convinced how important that really is.

Users versus Vendors, or is it Users and Vendors

One thing I’ve been noticing lately on the CDT project that’s probably happening with other projects at Eclipse is that more and more contributions, contributors, and even committers are coming from companies that are users of Eclipse technology. When we started the CDT and for many years we were driven almost exclusively by vendors that had commercial products that used the CDT. But now we have this very interesting mix and that is really changing the dynamics of how we work.

But you could see it coming and Eclipse is setup up to promote such growth. It started as bug reports, then slowly patches started getting attached to those bug reports, then those guys writing patches started contributing more patches and participated in the mailing lists until we finally voted them in as committers so they could apply their own patches. And that’s how it’s supposed to work. That’s how you grow your community. And that’s how we’ve reached the rich diversity enjoyed by the CDT project.

But as I mention, there’s an interesting dynamic that’s happening. The vendors are still trying to make money selling CDT-based products. Those users used to be potential customers of those products. However the economics of open source makes it actually cheaper and gives them more control if they get their tools and platforms from open source and staff a few developers to maintain and grow that software. When you have a user base that numbers in the thousands, I can see it. And there are quite a few of those companies, especially in the embedded space.

So what used to seen as differentiating features for vendors is still functionality that is desired by these user contributors. And of course, they would rather see that functionality implemented in the open where they can share it amongst themselves and anyone else who could potentially contribute. So as they organize, the tools vendors are looking on with dread. We have always fought to stay above the open source line with our value add, but it’s becoming more and more difficult. And that line is growing exponentially. It’s certainly a wake up call for us who get paid out of product revenue.

Has the industry changed making us dinosaurs or is there still value that we can provide that users will pay for. I think we still can make money, but we definitely have to change they way we think. It’s no longer about who has the best features. It’s what it should have always been about, who makes their customers the most successful. Our user contributors know that as that’s exactly what they are paid to do. We vendors need to find our place there too.