As you may have read (we appreciate the coverage guys!), thanks to our stellar Web and QA team, I’m excited to share that the Bug Labs web site (yup, it’s a .net) is now live.  We’ve updated the site to include more details and information, so please browse away.  We’ve put a priority on getting out BUG product and platform details, and you can expect to see more added in a few weeks. 

Next up, the beta program.  Big thanks to all the beta program applicants so far.  We’re going to keep the application live online until next Wednesday, September 5th.  At that point we’ll close the sign-up form, then take a couple of weeks to sort the list out into the multiple waves of testers.  Just to keep the process optimized, we’ll notify individuals as they are selected for each wave.  This means even if you aren’t in the first round of testing, please don’t assume we aren’t interested, we just have a limited number of slots to fill at a time. 

We’re planning the next few BUG+(blank)s now, upcoming cities include San Francisco and Boston.  Our goal is to increase the frequency of the events, and I’ll use the blog to announce each one as we finalize plans and dates. 

Lastly, if you look on the Bug Labs web site, you may notice we’re hiring!  All positions right now are in the New York office.  If you are a software engineer (esp w Java, Ruby on Rails, SQL, and design skills), embedded Linux developer, or a product or manufacturing process manager, get in touch!

Thanks, talk to you again soon!

</update>

Ah, nothing like a terrible pun to start a blog post.  But, since we’re chock full o’ good news, I figured I’d get a pass on that.

As the subject line implies, Bug Labs is ready to start beta testing the platform.  We need to test out the SDK, the environment, the interfaces, the APIs, and, yup, you guessed it, the hardware too.  Now to set expectations right off the bat: we don’t have nearly enough units to go around (yet), so there’ll be quite a bit of testing in a software-only environment (which is a-okay, as we have a full emulator that gives you a Virtual BUG!).  Also, we’re going to use a bit of a "staged" approach, so we will start small, then slowly expand the pool of testers as time goes on.

We’ve also decided that we’re going to "open up" the beta to the community as much as we can.  Testers will be welcome to blog about the process, or even consult with their peers regarding technical challenges they face.  Our objective here is to engage with developers so that we can launch with not just a polished platform, but one that has had real hands-on use from the very people who would be interested in using it!

Also, in case you are thinking "well, why don’t they just let everybody in if they really want the best feedback" please let me explain.  Bug Labs is still a small team, and we need to have the ability to really learn and grow from this process.  While we’d love to include "everyone" in the program, we simply don’t have the resources to effectively manage the feedback we’d get.  Whereas, with a smaller group we can have a lot more "hands-on" and interactive time with the testers.

If you don’t get picked, we’re sorry we couldn’t get you involved yet, but remember we’ll constantly be increasing the beta pool over time.  Also, we are launching the products this Fall, so it’s not really that far away!  Finally – huge thanks in advance to anyone/everyone who is interested, we sincerely appreciate it!

UPDATE: We stopped taking new entries on Wednesday, Sept 5th as we begin the
process of culling the list. Fret not, however, as we’ll have numerous
open-invites and ways to get involved in the coming months. Keep an eye
on the blog or website for more updates.

Our Bug+Bar+NYC event was last night and I wanted to give a big thanks to everyone who came.  I tried to work the room and say hello to all the attendees but if I missed you I apologize.  It was a big crowd – 50?, 80? – and everyone there had great things to say.  I really appreciated all the encouragement and cool ideas that came out of the discussions.  And while the free beer was definitely a draw I think I can safely say that wasn’t the reason everyone came   I’ve uploaded a bunch of the pictures we took last night here.

As Jeremy mentioned in his earlier post, this was our kick off event for a series of Bug+(BLANK) get- togethers we will be holding around the country in the coming months.  Stay tuned to this blog to see where our next ones are.  Hopefully we’ll be coming to a city/campus near you.

Thanks again everyone for attending.  It’s a great start!

  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.

One of the big themes here at Bug Labs is inclusion. 
With get-togethers, this can be a bit of a tricky thing to do, since it’s not
really practical to have a hundred people at a dinner discussion, and we’d have
a tough time convincing the landlords to install all-plexiglass walls in the
building.  But, we DO want to get out and in front of everyone/anyone interested
in chatting.  So we’ll be setting up events around the country that we’re
calling "Bug + (BLANK)".  Each one is a public, everyone’s-invited activity of some sort.

BLANK will include words like “campus” – when we show up at a school and meet
with students and teachers who are interested in learning more.  BLANK
could be “Austin” – for finding an interesting venue in that fine town to have
hands-on demonstrations and coding workshops with the Bug platform.  BLANK
could even be “the mall”, but we’re having a tough time seeing how that would
fit.

BLANK right now is going to be “bar+NYC” (I almost said "booze" – which I’ve always found an
attention-grabbing word), and by that it means we are going to have a night at
a bar in New York City, where a few people from the company will be on hand to chat
about whatever topics come up, whether related to Bug, open source hardware, cool gadgets, or Call of Duty 2 strategies.  In fact, I’m of the opinion
that all of those topics will come up and might even make a small bet on it.

So please join us on August 14th at Punch Restaurant (upstairs) in Manhattan for an open bar from 6-8pm.  As soon as we can logistically set up more BLANKs, you’ll hear
about them here.  Got a BLANKing good suggestion?  Comment on the
blog or shoot me an email, we’d be happy to BLANK with you anytime!