Open Source System Reference Designs

[swatts]

I know I said way back when that ideas are cheap until someone puts the work in. here

My gift to you (mostly NI, Alliance Partners, Entrepreneurs and customers), is an idea I've put some work and risk into. It is an also an idea I'm enthusiastic about.

The Problem

The image above came from my NIWeek 2016 presentation on Shock Testing and was intended to describe the standard way organizations purchase large expensive distributed systems. Essentially you have 2 choices.

1. Purchase a turnkey system

2. Do it yourself (DIY)

Over a certain price range and system complexity the risk of DIY becomes potentially career limiting. From what I have observed it becomes harder for DIY vendors (like a certain Texas based company) to sell these systems over a certain price point. So if for example the system consists of some PXI racks full of cards and the alternative supplier offers software or even just screens and a USB slot, the "full" system will always win. I've stuck "full" in quotes because the purchaser will always settle for 80% of their required functionality. As an example for the system I have developed I've had over 5 enquiries and each time they want it exactly the same (but with a few changes).

To add insult to injury from what I have seen, the hardware purchased is inferior and lots of compromises are made on the software.

Looking at the image again you can see that the turnkey system is controlled by the vendor and in my experience they are not that responsive to change requests and are quite prescriptive when making changes and removing support. Also they are prone to takeover and business refocusing.

In short the DIY vendor finds themselves at a considerable disadvantage, but actually the turnkey vendor is not providing a good solution either.

The Opportunity

The ideal situation is that the hardware comes with software that is easily adaptable using an industry standard language, this software could be loaded from the language vendors app store. I'm talking LabVIEW and the tools network here for anyone still struggling to keep up.

I can't believe that my system is the only example here (Singleshot High Channel Count Oscilloscope). So what else? I dunno, RF, Spectral Analysis, we're looking at any large distributed system, synchronized readings, high value hardware, replacing existing bespoke distributed electronics. Thinking caps on people.

I thought long and hard about the licensing because in the traditional world there is a value to this code, my conclusion is that I'm not a salesman and my assumption is that customers will want changes and who better to do the these changes than the designers (talking high value business here in customer accounts that you would normally struggle to get access to). When you are in these large accounts you will find extra work, we always have. Also I would never get into the companies I'm talking to without this, I probably wouldn't even get into the carpark!

So a standard BSD license, with liability restrictions.

Freeing up this bottleneck will also help your relationship with the hardware supplier, essentially your software is the enabler for selling their hardware. This improved relationship is mutually very beneficial.

The Challenge

This is a matter of trust, you are throwing your code to the world and trusting everyone to do the right thing. In the real world there should be little incentive for any of the parties to do anything but help each other. Obviously small mindedness, short term thinking and profiteering could cause issues. For me the worst bit is feeling disconnected from the code.

So far the experience has been really excellent. Our method has transferred to remote working.

In truth tho' it's actually not that much of a problem if you can get over the initial hurdle of being paid for development. In my case a long term relationship with an existing customer mitigated the risk of tackling the project.

What can NI (or another hardware vendor for that matter) do to mitigate the risk? They can have decent amounts of high value equipment available and maybe there is even a business case to provide a grant to pay for or contribute to the development. They will then need to resist the temptation to OWN the code, open-sourcing it will be better for everyone believe me.

A Different Type of Sales

You might be thinking that because I espouse ideas in writing and with some force that they are well thought through. This particular idea is pretty much me trying to make sense of it by writing about it (I'd say a fair few of the things I write about fall into this category!). So here goes.

I think some of the sales and marketing that alliance members/consultants and integrators do is misplaced (mostly this is aimed at SSDC). The last two large opportunities that we have successfully pursued have been where we have had something to sell, rather than where we have tried selling ourselves. In someways I think this is also more useful/profitable than selling toolkits etc into the LabVIEW community. So we are changing our model to one where we sell ourselves to solve any problem, to where we have a solution and can adapt it quickly and efficiently.

Why Open Source?

Most systems integrators are more problem solver than entrepreneur. We negotiate a price to design some code and then we design it, for us we nearly always offer up the source code to the customer. Our experience so far is that the customer is keen to engage with us at the "Trusted Advisor"* level and it's a nice start to a relationship. Also they are freaked out by someone giving something away! This fits the Open Source model much closer than other models I've looked into.

I think this is an enormous opportunity for NI and system integrators. We just need to identify the gaps in the market.

Lots of Love

Steve

* for more on "Trusted Advisor" see my comedy skit at CERN, where all is explained.