Oct 16

Out of all the many things I detest, the worst is paying for items and still not owning them. With the world the way it is, I have no option but to disobey the laws of economics and open my wallet for gadgets that curb my freedom to use them to their full potential, and then pay for a dressed-up upgrade every six months. Which is why it gives me immense pleasure to report that the last bastion of exclusive hardware ownership has been breached. Open-source hardware has reached its tipping point.

If the time wasn’t ripe for this revolution, news of an open-source camera from a university wouldn’t have made it past the campus science journal. But Stanford’s Frankencamera project is popping up all over the radar. The idea is simple – take the principles of open-source software and apply them to a low-cost assimilation of off-the-shelf camera parts tied together with a Linux-based OS that’s available to everyone for modification. Forget proprietary APIs and SDKs, this is the holy grail for people that spent their school breaks soldering radios.

When (not if) this union of open hardware and software specifications trickles down to consumer-grade cameras, you’ll be able to super-size your point-and-shoot to take RAW shots, or use more pre-configured modes for shooting at night, or make use of the ability to adjust the auto-timer settings and more. Just like with open-source software, you don’t need to meddle with the innards of the camera: pick it off the shelf, connect to the internet, and fetch the wisdom of the community in a firmware upgrade. Or just order a supercharged modded version that’ll shoot under water and has a hot shoe for attaching a custom flash.

Frankencamera isn’t a lone example. The Arduino computer project started as an inexpensive prototyping system and is now accessible to electronic students worldwide thanks to dozens of clones that spawned because of Arduino’s open specs. Then there’s the RepRap self-replicating open spec 3D printer that’s 50 times cheaper than commercial alternatives. Hardware maker VIA has released a reference design for a netbook, MIT plans to do the same with its solar-powered car and there’s even an open-source graphics card under development.

So open-source hardware definitely makes sense to the garage mechanic and the independent researcher. Using non-proprietary standard hardware helps them keep their costs down. But why would traditional hardware companies want to spend money developing a new piece of hardware and then just release the specs? It’s a complete reversal of their current modus operandi.

They’d do it because open-source hardware actually presents a business opportunity for the hardware vendors. Take the example of Cisco. When a licence violation forced the company to release the specs for one of its routers, sales picked up. A dozen or so third-party firmware projects mushroomed around the router and made it do things way beyond Cisco’s wildest imagination.

In a similar vein, backup company BackBlaze has just taken open source hardware to another level. The company sells unlimited online storage for about £3. Since existing commercial storage solutions wouldn’t allow it to keep its expenses in check, it decided to assemble its own 67TB 4U storage pods. Its hard work cost it $117,000 for one petabyte (that’s 1,048,576GB) storage rack. Dell retails the same amount of storage for $826,000, Sun for $1million, and EMC for over $2.8million. You do the maths.

These are the kind of savings you need to beat the charts in the current cost-conscious market. So what does the company that has seemingly cracked the code do? Just like you’d expect, they show off with fancy cost comparison charts and stacks of storage units on their blog. Then they take a leap into the future and explain in great detail how you can copy their design! They have it all – videos, specs and wiring diagrams. They even tell you how to dampen the vibration from all the disks.

From a traditional business model point of view, BackBlaze has just committed commercial suicide. But the pointy-haired nay-sayers fail to see that by letting people work from its design, BackBlaze is offloading the R&D burden on to more people than it could ever pay for on its own. That’s something you can take to the management, and not have it thrown back in your face.

For these reasons, open-source hardware is finally on the verge of breaking through into a store near you. Depending on how they play it, far-sighted hardware vendors will receive either a pat on their back, or a slap in their face. What is certain, however, is that they can’t afford the opportunities any longer.

Oct 08

Microsoft rarely manages to elicit a positive reaction from me, and I don’t know why. Is this a learned behaviour? Do I cringe at the sight of every expensive new Redmond operating system simply because I sit in the company of Linux devotees and computing idealists all day? Do I express such bile for the utterly contemptuous form of the Zune merely because Microsoft doesn’t deem the UK as a worthy market for its release? Are these actually great inventions that I have simply been conditioned to reject by my environment? I’m beginning to think otherwise.

This is not because I suddenly think Microsoft is great. No. Take the frankly lazy recent release of Windows Phone; it’s an example of something brown and sticky that the  juggernaut has simply coughed out of its right lung and deemed good enough for user consumption, despite the public moving on to better things many moons ago.

No, the odd thing is that I find myself actually coveting a forthcoming Microsoft product. I must be ill.

It’s called the Courier. It’s a dual-screened tablet, with a nifty interface combining capacitive multitouch and pin-point stylus input. It has one button, no keyboard and a super-clean design to match. Its cute little notepad OS seems both fashionable and highly suitable for pen-based interaction and casual web browsing. And this is from Microsoft? Wait a minute.

At this point the Courier is at a very early stage. Perhaps it doesn’t actually exist beyond one promo video and a whole lot of hype. There’s definitely something fishy about it, namely that it is almost exactly what I would imagine an Apple tablet to be. In functionality, in appearance, in philosophy: Apple.

Now, I’m no Apple zealot, I promise you. I own an iPod Touch, which I barely use thanks to its infuriating insistence on communicating only with iTunes. Instead, I use a more sensible MP3 player which appears to my PC as a hard drive. I refused to buy an iPhone in favour of the cheapest, most basic mobile handset I could muster. I have an iMac at home, but half of the time it’s booted into Windows 7 doing decidedly non-Apple things. Similarly I have no great affinity towards tablet PCs; I’ve owned several, and grown tired of their gimmicky tablet interfaces within hours.

But this is something else. The Courier is the tablet PC that the public has been begging Apple to make. It is truly a genre definer.

One short video – the preview I’m so enamoured with weighs in at under a minute and a half – is all it has taken for Microsoft to insert its future hardware firmly into the Universal Lifestyle Computing bracket pioneered by Apple’s handheld devices. I don’t care if Universal Lifestyle Computing isn’t a recognised bracket. It is now. I recognise it. And I recognise that companies like Nokia and Sony are desperately trying to weasel their way into that bracket with shamelessly Apple-aping products.

Essentially this boils down, once again, to me making myself progressively more angry with myself. I can’t stand the prospect of becoming a computing hipster. I have so far managed to resist the ULC onslaught, but if I start buying balsamic vinegar and in-season olive oil, wearing drainpipe jeans and aviators and strutting around Bath with all the latest gadgets shining out from within my brown leather satchel, it’ll be Microsoft’s fault. Luckily the grumpy part of me is positive the Courier won’t be nearly as cool as it looks.

Apr 11

Big news this week, the rumor finally became true: Google App Engine supports Java, next to Python. So Google AppEngine is now a big Servlet Engine in the cloud.

Along with the Java on Google App Engine announcement, I noticed another component: the Secure Data Connector. This SDC allows applications running in the Google cloud to inter operate with Intranet applications. Through the Secure Data Connector, Intranet applications can be accessed.

Scenario:

  • The Secure Data Connector is installed on a Linux server within the Enterprise.
  • An administrator configures the SDC to access certain resources within the Intranet.
  • The SDC is started and runs continuously as a background process.
  • The SDC connects to Google (https://apps-secure-data-connector.google.com) on port 443 (HTTPS). The connection is made from the enterprise to Google, so no need to configure the firewall at Entrprise side to allow inbound connections (from Google into the Enterprise).
  • The SDC authenticates itself using username and password.
  • Once the SSL connection is established, the connection remains open.
  • An application running in the Google cloud (AppEninge, Google Spreadsheet, …) needs to access data from the Intranet or send data to the Intranet.
  • In AppEngine, this is done using the URLFetchService. To specify that an Intranet resource, HTTP header use_intranet=true is set.
  • From the Google AppEngine, a call is made to the SDC deployed in the Enterprise. Remember, TCP connections are bidirectional.
  • The SDC verifies if the access the local resources, e.g. using the local DNS from within the Enterprise.
  • The SDC accesses the local resource or web service and returns the data back to the applicaton running in te Google cloud. The size of request and response messages is limited to 1 MB.

The access to protected data within the enterprise is somewhat of a challenge. The only mechanism the SDC can provide credentials to Intranet application/service/resource is OpenSocial and OAuth signatures. And

One of the evolutions that I envision is that ESB’s or B2B services will embed the SDC logic as an adapter. The ESB is able to transform the requests coming from Google into other protocols or formats and add the necessary credentials.

Some more thoughts and remarks I made while going through the Secure Data Connector docs:

  • How is the configuration file of the SDC protected? In particular the username and password contained therein.
  • Support is limited to Linux. What prevents this open source code to be ported to other platforms?
  • How about load balancing or failover?
  • How about interoperability between clouds: anyone already tried to deploy the SDC on EC2?
  • Where is the SOAP support? How to invoke SOAP web services using the URLFetchService?
  • How about identity services and mapping the identity of a Google user to an internal Enterprise user account?
  • The SDC is not comparable to the .Net Services Bus of Windows Azure.
  • Can the SDC access the Internet through a proxy?
  • To deploy the Secure Data Connector in a large enterprise, you might have a hard time convincing the security department.