So I went to Chichester to pass the 5 days certification on behalf of Open Remote. You will all be proud to know I passed. I blogged about the experience on my generic blog here. Here I would like to talk about what I believe we can bring to the field.

First off it is clear that KNX is high end technology. Turning on a light in KNX cost $1000. Not kidding. They kind of look down on Crestron, as old hat, unreliable. Plus with the Olympics under the KNX belt, the Chinese are also certified members providing everything and more importantly hardware.

I believe we can offer software, a lot of it. Take the iPhone manager that CB just announced. From an KNX installer's point of view it means to create a remote for your customer, or better yet let the customer create his own on the web without ever having to touch your commissioning. With an actual commissioned KNX install, you can have an ORC as a controller that maps the buttons on the iPhone to actual group addresses sent via Calimero. Voila! you have offered a programmable UI environment to the customer. We are of course not the first ones to offer controller environments on KNX but we would be one of the first Open Source ones (after all that is KNX@Home was :)

KNX is not a programming model environment however, which is what I was really looking for. It is a firmware specification that gets actuators and sensors to exchange message signed as 1 bit, 2 bit, a nibble, a byte, 2 bytes. That's it. That's a lot already but that is it. The Programming abstraction is very low level, although flexible and robust. Really ETS, the programming tool is a firmware programming tool that turns bits on in hardware through configuration menus and links those bits to listen to messages on group addresses. Through ORC we could offer more intuitive and powerful programming models, The publish subscribe mechanism is a well known one and instead of bits and bytes we actually exchange messages instead of bit. So scene programming while a trivial mental construct is a convoluted, device dependent mess at the time.

Looking forward to helping.

Here is what OR does, first A/V automation, then HA automation, these are the products and they are broken down in various projects:

1. A/V automation. Beehive/Manager/Controller/iPhone combo. This first product is really where I personally started. Having an iPhone control my TV. The idea of Beehive is to enable collection, packaging and distribution of IR and RS codes. CB is working on it as we speak, claims he already has 100k codes in it (from LIRC) and says he will release next weekend. For those of you that want to contribute, details on Beehive can be found here and is probably the first step. On top of Beehive sits manager. Manager allows one to declare an A/V setup and collect a package of codes that run on the Controller. Details on Manager and how to contribute can be found here. Finally rendering the remote, with all pages is the job of the iPhone Console. The idea is to have a programmable interface (via web) and anyone can assembled simplified UIs. Details on the console can be found here. This package of application is a hefty chunk, each project a worthwhile OSS project (and in fact has been implemented in many places) but will provide a useful iteration of IR code management and iPhone UI remote creation.
2. HA automation. Controler/Protocol support. This is a more ambitious project that aims to be an integration point for existing proprietary and open HA protocols. Once we have modular support for on the wire specifications across medias and vendors, offering a unified install, maintenance and programming interface really serves the needs of the installer crowd and the DIY crowd. Protocol research, such as INSTEON, KNX, xPL, fall in this category. Applications are lights, HVAC, Security etc. Standardizing on a standard message format is a pre-requisite. Programming models research, in the vein of KNX@Home (web) or ETS, or indeed proprietary Crestron, INSTEON environments, is what we are looking at. Manager for example now takes into account a hierarchical plans of a house, not just a local A/V setup. Notions of scenes, logical names, conditional events etc appear in here. The iPhone interface is still very much a part of this second step.

As you read through the site, we tend to discuss all of these issues in parallel and it seems some newcomers may find it hard to grasp at once what it is that we are pursuing from a product standpoint.

Dana apparently has a personal interest in Home Automation and pitches in. Basically he welcomes an open approach to what he thinks is a proprietary world. He thinks we don't think big enough, wants us to think about elderly care and pacemakers that BT over to base etc and writes The company which can deliver a truly open platform to these nascent industries won’t be the Apple of home automation. It will be the Microsoft of the new century.

He picked up on the software focus of our effort and the standards push, these are good messages, they ring true. I think we should draft on standards like KNX and establish run-time standards. All good.

This is great coverage. Thanks for the support and feedback Dana.

I know MJ Asay personally. He is a good guy and a prolific writer. He is also mr Open Road over at CNET and was quick to point out what he believes is the fatal flaw in our approach, Control4.

I used to be involved with Control4 during my time as an Entrepreneur-in-Residence with Thomas Weisel Venture Partners, an investor in Control4. The company was doing fantastically well back then (2003/2004), and I'm betting it has easily cleared $100 million in sales by now, and has signed up every major distributor and OEM one can imagine. This is a very, very well-run company. Is there room for an open-source competitor? Perhaps. Remember, however, that Control4 is also based on open source. The company understands and leverages the cost and development advantages inherent in Linux. What, then, would OpenRemote bring to the table?

A slight difference from C4 is that we intend to be hardware agnostic. We are squarely focusing on the software, hence the current fascination with KNX as a protocol to draft on. I keep hearing things from the professionals about C4, some positive like their business model approach, some negative like their buggy reputation and slowness to fix said bugs, Maybe an Open Community approach can help? They don't care they have embraced the hardware model of HA which is tried and true. And they are successful at it. I believe we could even help on the software front. Who knows :)

After all WebMethods was one of the first companies to reach out to JBoss for technology adoption back in the days and their specialty was IT protocol mapping. The plethora of proprietary protocols begs for a standard implementation in the run time to map it all. The protocol is interesting in that it creates a common platform for everyone to map to and integrate at. On that platform you have panel vendors, security vendors, software vendors. I think you will see us in the business of Controller implementations (ideally with the likes of C4) and tooling, potentially via subscription for a token amount.

The fact that they use OSS is relevant to the extent they lower the cost of development and gain an open reputation as they do so. But they are just another proprietary protocol at the end of the day as far as we are concerned, one we can integrate to and will if someone steps up with I need this.

We are a small community and there aren't too many serious projects one can undertake as hobbies. So we choose our battles. KNX, is an abstraction of a telegram over UDP/IP/RF. By integrating to it, we immediately connect to a live ecosystem of suppliers that populate the platform.

Back to C4. We should view them as a potential partner. If they have a stack of hardware and software and if there is any way we can do to help on the software side, we would love to, I don't know, controller maintenance. At a minimum we could offer a translator from C4 to KNX. That would open up the panel selection. That being said, I liked the C4 touch panel. I like the presentation. They are definitely a company to emulate. Feedback from knowledgeable people is definitely always appreciated.

I have invented Professional Open Source, have you heard of it?. It is really a business model for Free and Open Source Software. Is there a business model here at OpenRemote.org? Well, I have created a little shell company called OpenRemote inc. Its business model right now is to serve as a conduit for debt funding from me. The company is registered in Delaware and sits on a whole bunch of shares in its treasury (I took debt not equity). These shares are meant to be, well... shared.

I believe there may be a business model here, around an open platform for HA. It is different than JBoss, different than Digium, but it is in a big market. The HA market is exploding, partially due to the maturity of the high-end solutions out there, but also to the democratization of HA. That market is big and fragmented. That makes it tough to penetrate, we do not have the luxury of a EE standard to draft on in the HA space. There are emerging standards, one can think of KNX as a good industry attempt at standardization. OpenRemote could position itself on the Controller implementation field. In other words there may be a software play here. For that to happen we need to friendly to everyone. If there is a pure software play, we are thinking about the licenses. GPL licensed C libraries and CC licensed ORC (written in Java based on embedding JBoss in a mid-range Linux embedded environment). This will allow us to play nicely with standards controlled by a consortium of enterprises as it opens the door to Dual Licensing as well as allowing hobbyists to use it for free as the CC makes the distinction between commercial and non-commercial usage.

A simple model could be the hardware assembly. Mark Spencer made a killing with this model over at Digium/Asterisk. Mark is maintaining and publishing the BOM for the ORC (OpenRemote Controller). Neil went right ahead and ordered all the parts from a website and is going through the growing pains of helping Mark getting the Z-image in place for this Linux RI. However Wade, being a java guy, said no way he would buy all the parts and put it together himself but that he wouldn't mind paying someone to do it. Which got me re-thinking about the assembly and testing business for the RI. So maybe I can put some of that funding to work and have Mark research the issue in detail around a run of production. Do we do 10? 20? 20 units dedicated to development would represent a cost of 5000k and if there demand for the dev-kits. A unit at $500 (300eu) I am sure we could extract a 20% margin on hardware once you take out shipping and handling? Mark said he was going to look into this in Huntsville, I will follow up with him (he is still busy with Digium).

Then there is a no-brainer business model around professional services in the form of training and certification. This model is tried and true both in the Open Source world and the HA industry. The birth of JBoss's professional OSS model was in that services model and it grew to encompass a software model. However pre-VC money, we ran a multi-million dollar training and certification program for years out of our living rooms. We travelled the world giving tutorials and trainings. It was a blast.

The the existing HA programs are designed around the business model of integrators. The integrators today make great margins on hardware and implementation and maintenance. Training and certifying installers and basically listening to the needs of the integrators, seems to be a very viable business model. We did at JBoss and we can certainly do it here. Contrary to popular belief it scales, just on longer timelines than software, but it scales. Crestron and AMX today are $250m a year certification/hardware shops. I would be curious to know the breakdown. Meaning there is some room here to grow a $10m/year business.

But really we are going to keep an open mind. This is first and foremost a community effort and what will come of it will come of it. Planning to far ahead would be counterproductive and futile. In my previous life I failed at a OSS venture because I tried to invent too many things in a vacuum. I was missing the feedback from the field, how was our stuff being used. All I really needed to do was to listen to the needs of our users, that is one of the big benefits of an open community. The business model was born the day someone asked for me to do training for JBoss. Training I could do every other month and still bring in $20k for a training, perhaps there is a similar business model here? Before we knew it we were 20-30 guys, we already had a history, and we were received like rock-stars in Australia, which for both my wife and me is one of those fond memories of early JBoss.

Figuring out the business model, this is one thing I can help with. But for right now, let's focus on a community. Without a community, there is no OSS model. The community is what you do with it. Feedback welcomed!