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.

We’re in, and we have you to thank for it!  For those of you new to Bug Labs, last month we entered Peter Semmelhack as a speaking candidate for 2008 South by Southwest (SXSW for short), and we found out yesterday that he made the cut! Peter’s proposed session on "Hardware Mashups: The Long-Tail of Gadgets" has been placed in the preliminary program.

If you recall (and you probably don’t, but we sure do!), we submitted our idea to the SXSW PanelPicker just four days before voting was scheduled to end. But thanks to the efforts of the BUG community, we amassed enough votes in such short time to be selected as one of 42 preliminary finalists, out of over 730 submissions!

If you’re planning on attending SXSW 2008 (March 7-16 in Austin, TX) drop us a line! We’d love to see you at Peter’s session, and share in the excitement of all the music, film and interactive sessions that will be taking place. And watch this blog for more on our BUG+SXSW plans.

See you in Texas!

On our trip to Bug+ Boston the team wanted to
contribute a bit of our elbow grease to help out in the community.  We came across a great organization, called Pine Street Inn , who was willing to let us park our rented RV in their lot and teach us what goes into feeding the hungry.

I think ‘volunteering’ doesn’t generally come across as a fun word – especially after a long night of Bug+ing.  But we had a blast.  We cracked hundreds of eggs, mixed hundreds of pounds of ground beef with our hands (in sanitary gloves, of course), delicately arranged hundreds of lasagna noodles, and wrapped hundreds of sandwiches.  All told, I would guess our small team prepared a big 1,700 meals or so. Where we generally spend our mental efforts on issues like configuration compatibility and making sure a service tracker doesn’t interfere with application code, we suddenly found ourselves focused on the very different, bigger, but simpler task of feeding and distributing thousands of meals.

We knew Pine Street Inn had a great cafeteria service for all who came in, and that they had a night outreach program to bring food to the hungry.  We didn’t know Pine Street was a big, efficient, and caring powerhouse firing on all cylinders (unlike the motorhome), allowing homeless people to secure permanent housing and get on the path to self-sufficiency.   We saw a clean and welcoming emergency shelter where 700 individuals sleep every night – which includes the largest shelter and resource for women in New England.   There was medical and psychiatric services, job training, literacy programs, work programs, elder programs, and outreach teams bringing food, clothing, blankets, medical assistance, and compassion to streets every night.

I don’t know how all this gets done.   Obviously, it takes tons of activity, energy, resources, passion, and compassion.  What would happen if places like Pine Street Inn didn’t exist?  How can we be more
involved in our communities?   I think I can speak for us all when I say that spending a few hours at Pine Street allowed a glimpse at the bigger (more real) world that we tend to forget about when we are
living our lives.

Tuesday, after I spoke at the Mass Customization and Personalization conference in the Stata Building at MIT, we hosted our BUG+Boston event and had a great time.   It’s no surprise that when you throw a party in a town with so many great schools you get a lot of really smart people.  I had some terrific conversations.   Also got a lot of great input and feedback on BUG and what we’re up to.  Thanks to everyone for coming.  We’ve posted a bunch of pictures here.  And thanks to all the bloggers who covered it!  Here are a few links:

http://danbricklin.com/log/

http://www.xconomy.com/2007/10/10/bug-labs-the-open-source-hardware-store/

http://weblog.masukomi.org/2007/10/10/a-night-with-bug-labs

http://www.nonstationary.com/2007/10/10/bug-labs-boston-meetup/

http://sabet.typepad.com/bijanblog/2007/10/bug-labs-meet-1.html [Full disclosure: Bijan/Spark Capital are investors]

We also put up on our website the latest renderings of what the BUG will actually look like.  We’ve gotten interesting feedback!  Some like the design, some aren’t so sure, which I think is great.  To be clear, it’s not an iPhone nor a Curve.  It has it’s own personality.  It’s more "Jack Bauer" than "Giorgio Armani"

Peter and I are already here in Boston at the MCPC 2007 conference, and tomorrow we’re looking forward to seeing some of the rest of the team RV their way up from NY to Boston.  And not just them, but hopefully you!  Details:

• WHAT: free booze, good discussion
• WHEN: Tuesday, Oct 9th, 6-9pm
• WHERE: Middlesex Lounge, Cambridge (google map)
• WHY: because we want to
• WHO: team Bug Labs + you
• HOW: hmm.. not really sure what to say here…

See you tomorrow night!

Here is a scenario that may be familiar to some Eclipse developers:

1. Write lolcats manager plugin using Eclipse x.y.
1.2 Build scripts for lolcats is written.  Takes 2x time of writing lolcats.
2. Release lolcats for Ecilpse x.y.
3. Eclipse releases x.z to general public.
4. Lolcats is tested on x.z and it is compatible. (yay!)
4.2 Lolcats build scripts are modified to build against x.z. 
5. You are now supporting Lolcats on x.y.* -> x.z.*
6. Users start sweating for bug fixes and new features only in x.z.
7. Brain starts hurting.

When do you stop supporting older Eclipse releases?  There are some great things in 3.3 that simply are not available in 3.2, and the overhead in forking product that goes through building, testing, and documentation can be very expensive.  Any advice on when to say when?