Bug Blogger

Who cares if the future of mobile Java is open or closed?

Well, I do. :) There is a whole lot of activity these days in the mobile Java/open source world. Harmony, Android, PhoneME, OSGi, and MIDP 3.0 are all causing waves, in one form or another. The latest MIDP JCP, initialized about 3 years ago, has been rumbling towards an initial release as of late. Back then open source mobile Java did not exist in any meaningful way. Well, things have changed. I think the PhoneME MIDP implementation needs to be opened up. If you agree you may want to let the PhoneME engineers know. I'm sure they would appreciate the feedback.

GPL + Sun + Java = Try Before You Buy?

From early on (pre-GPL Java) in the development of the BUG we realized that Java-like language features would be a great help to us in providing a consumer electronics platform that is easy to use and modify. In general, we wish to openly enable more people with different skill-sets the ability to create custom consumer electronics devices and applications. Here are some reasons why Java makes sense:

1. There exists a large base of people that can write Java programs.
2. The "Write Once, Run Anywhere" design of Java side-steps many of the pitfalls of traditional embedded development. By simplifying how applications are written, built, and deployed to BUGs, a larger group of of people can participate.
3. A large pool of existing applications and libraries are available, both open source and commercial, that could possibly be combined with BUG to provide rich functionality.
4. Java has a wide variety of rich tools to develop and debug applications, making the process of building software easier.
5. Sun and other companies and institutions have spent a great deal of time and effort on making Java run well in small systems.
6. Unlike many older languages, rich networking support was built in from the beginning.

We experimented with various other languages that had some of these features, but in the end nothing else really stacked up. So we created some early proof of concept systems involving JamVM and GNU Classpath and were pleased to see that open source Java worked and looked to be stable enough for production use. And then, of course, came the Sun announcement that Java ME was to be released under the GPL. We watched with great interest as the phoneME project emerged as open source Java for small machines. We began working with it and found it to be extremely mature and well documented. The development team at Sun have been extremely helpful and diligent in supporting FOSS folks.

So we plowed ahead, building our application layer on top of phoneME. A little JNI here, a little OSGi over there. Everything was coming together and the product matured to the point that we were ready to begin the process of validating our system via TCKs. TCKs are test suites used by Sun and other companies to pass or fail a given implementation of a specification. The are necessary to ensure that different products have consistent behavior. In essence they enforce the "write once run anywhere" design goal. We had a conversation with Sun that went something like this:

Bug: "We use your open source Java product and want to validate it. We want to be able to say it's Java. What are time and cost constraints?"
Sun: "Great! We love the open source community. Please step into our commercial license so we can proceed."
Bug: "Umm...we can't have a commercial license. Our product is completely open source."
Sun: "We're working on our open source validation process. Let us get back to you when we have something in place. Are you sure you don't want a commercial license?"
Bug: "Well, can we pay you for the validation and stick with GPL PhoneME?"
Sun: "Nope, TCKs are only available with a commercial license."

So here we are, a pure open source software stack using GPL'ed Java from Sun without the ability to validate it or even call it Java. What are our options? The same options we've always had with other OSS Java implementations: don't call it Java. We could also utilize another implementation such as JamVM with GNU Classpath, Harmony, or one of several others. As it stands the quality of the Sun implementation and the engineers behind it make it a very good choice, but once you remove the feature of "Java from Sun", other implementations begin to look more attractive. Given the simplest solution, don't call it Java, it seems that Sun is almost ensuring that fragmentation will occur. We have to call it something..perhaps "anything but Java" (abJ)? And without tests how can we ensure compatibility? Of course we can't. Without validation from Sun, we'll need some kind of validation from someone like Apache Harmony or GNU Classpath. Validation is important because it gives us the ability to isolate our bugs from class library and JVM bugs. Sun of course is the gold standard but both GNU and Harmony have validation strategies that look to be effective.

In open sourcing Java, Sun wishes to increase it's usage and popularity, get help from the FOSS community in expanding and enhancing it, and be a successful commercial company by doing so. As it stands now there is a road block in that no community-driven phoneME implementation can be called Java, nor can it be validated against Sun TCKs. Is GPL short for "Try before you buy" at Sun? If Sun truly maintains the Java trademark to ensure that the product does not become fragmented it MUST provide TCK and branding options for GPL PhoneME, otherwise further fragmentation is inevitable.

Navigating the Waters of Commercial Open Source

  Just like it's a baby's job to cry, it's a company's job to make money.  There is no need to rehash old cliche question "how can you make money if you give away the product for free."  I think the software world, as it exists in 2007, is proof that we've evolved beyond this initial fundamental question, even if others are having a harder time.  Yet the story has become more complex, more subtle.  One question that I deal with every day is, how do commercial open source companies work together to produce a product?

  In the old days, building a product with technologies provided by other companies meant buying licenses typically, or maybe support contracts.  A financial transaction insures that the companies you depend on will help you make sure their aspect of your product works as it should.  In the real world it's never true that this always works, but it provides a basis for the relationship.  What then becomes the basis when there is no explicit transaction between companies?  Or even when when one company knows absolutely nothing about the other.  In working for a commercial open source company, I've had some interesting experiences finding out.

  First let me say that I'm an engineer and I solve technical problems.  In the old days, after securing a license from a vendor, you get a support contact, and then you're off building your product.  In dealing with open source, after first doing your license compatibility checks, community "vibrancy" checks, you just dig into making your product with various open source bits.  If you're lucky, things work as they should.   Again, the real world is  a little different.  Here's where the interesting stuff starts.  When something doesn't work as expected, I post to forums, send emails to developers, and do a lot of googling.  Openly, brazenly, technical details about my project leak out into public forums.  I ask questions to Sun, to Freescale, and surprisingly they respond.  Solutions that are found to problems are also public.  My competitors could have a head start simply by reading forum posts.  There is no commercial relationship between me and any of these open source software providers.  Should there be?  They have no idea what my product is, who the customer is intended to be (a potential competitor?), or when I intent (if ever) to release my product.  Yet they respond, and they put a lot of effort into their responses.  These are very smart people being payed well (I hope!) to help me fix problems.  Why are they doing this?

  Some companies present the lure of open source, and then attempt to reel you in with a commercial license after the complexities of integration become apparent.  I don't really think this strategy works, because the true values of open source products outweigh any short-term gains you get for paid support to a commercial product.  What about other companies that release pure open source products with no commercial "safety net" license?  What is their motivation?

  This question I don't have a solid answer to, but here are my suspicions.  Software companies that have released products as OSS have a belief (faith) that by this act, the hordes of new users and products that incorporate said product will generate them more revenue  than if they'd kept it closed.  How can they prove this?  I don't think they can.  But in the end the market will shine some light on the effects of these decisions.  Is Java being used more now that it's been GPL'ed?  Is mobile Java on more phones now that it's open source?  More importantly, is Sun making more money on Java based on it's decision to GPL it? 

  I don't think the market has decided on this either way just yet.  I wish it would, I'm dying to find out.

 

Microsoft blinks

Lots being said about this Fortune article regarding Microsoft taking the gloves off in its battle with FOSS.  But who exactly is the enemy?  It looks like it's their own customers. 

I'm no history expert, but to draw a gross analogy, it would seem that when governments start to treat their citizens as the enemy it doesn't take too long before a revolution erupts.

And revolutions are funny things.  They bring out the best in people with the most to gain and the absolute worst in those with everything to lose.  I truly hope the battle is never seriously joined.  It's not hard to imagine a Patent Dark Ages, which would be a disaster for everyone, especially customers. 

"Revolutionary Spirit"

In the February 19, 1996 issue of Newsweek Steve Wozniak is quoted as saying:

" Our first computers were born not out of greed or ego but in the revolutionary spirit of helping common people rise above the most powerful institutions"

Great stuff.  And who were those "most powerful institutions"?  They were the mainframe and mini-computers vendors of the day - IBM, HP, Digital, Prime, Wang, Data General, Control Data, etc.  Most people don't remember those days too well because the micro-computer (or PC as it came to be known) has insinuated itself into just about every part of our lives.  And in the same way, it's hard to imagine a world bereft of all the innovation the PC-revolution sparked.  For example, can you really remember a world without spreadsheet applications or the browser?  All of which points to something I think about all the time.  Ten years from now, what will we look back on and say "how on Earth could we have lived without...[fill in appropriate invention here]"?  Revolutionary possibilities are all around us.  There are many "powerful institutions" that are holding up innovation.  The key is finding those most vulnerable and then doing something about it.  I think the spirit Wozniak describes is alive and well and there are plenty more revolutions to be had.