Why We Support Open Source (but not everything we do is)

Open source hardware and software has become a huge industry and movement. The idea that we can all make better widgets by sharing flies in the face of conventional industrial secrecy, patents, NDAs, and lawsuits. While there is still a place for “trade secrets” – about 70-80% of what any company, engineer, or product does is just the underpinnings of the magic and there’s nothing secret about it. As a company, we embrace and support many open source efforts, even working to open-source as much of our generalizable knowledge as possible. In this article I want to talk about why we take this approach and what the role of open source can be in a world of trade secrets.

What is Open Source?

Most simply put, open source is making the information used to create something freely available. Now we can get into arguments about licenses, permissions, if something can be used commercially, or only with attribution, but that’s another debate for another blog post. Fundamentally, what’s important is that open source makes things about the design and creation of something transparent. This started with software before anyone really thinks – sure *nix is the classic open source project, but in the early days of computers scientists passed code around via tapes in the mail without worrying about a license or signing an NDA. You can hear Paul Wessell of Generic Mapping Tools (GMT) fame talk about it on the Don’t Panic Geocast Episode 166.

Now I’m not saying that licenses are bad – in fact, they are now a necessity. Without a license your content is not publicly usable by anyone in any way. Putting your code up on GitHub or a schematic up in a forum means nothing unless you give permission for people to use it. The easiest way to do this, since most of us are not lawyers, is to use a license that is already prepared. There are a ton of them out there to choose from and even tools to help you choose. Generally, we stick with simple and short. The MIT license. The ultimate in “do whatever you want with this, but it must remain MIT licensed and if it doesn’t work, don’t call”. We occasionally use some other licenses, but many of our projects are MIT.

How We All Benefit

Open source is lovely in so many ways – it means that we all are not spending our short and valuable time here on the planet writing basically identical drivers for chips or reimplementing a numerical method to take an integral for the 500th time in our career. Overall, that’s a good enough reason to me right there – everyone gets to spend more time with their family, hiking, or doing whatever else they want to do.

That seems too abstract? Then imagine you’re working on your next project and you need a bit of code to calculate something as outlined in a paper you found. You think it might work for your application, but aren’t sure. You know that someone(s) must have written the code already because there is a paper after all. Opening your browser you go to GitHub and boom – there it is. A documented (if you’re lucky) library that lets you test it out. Ten minutes later you’re either on to the next step of the project or you discovered that the algorithm isn’t really suited for your application and you’re on to find the next one. It’s a great feeling. Especially when compared to spending all of your Saturday morning writing the same code and then discovering it doesn’t really work for what you want to do. Then you probably delete it, dooming some other poor soul to repeat your experience in the future. (This isn’t a rant on publishing negative results, but it is close at times!)

Now in the hardware arena, open source is still a newer idea, but again, I’ll argue that basically everything used to be open source. You bought a battery charger, heater, or other widget in the 50’s-70’s and guess what was in the box? A real owners manual (now they would be digital which is fine) that contained not only how to use your device, but how it works and even schematics! I don’t know how many pieces of hardware I’ve worked on from years gone by, or that were built by folks around in that era, that right under the panel cover had a schematic. One even had a flow chart of the PLC logic! You were armed with everything you needed to work on, fix, modify, or improve that design. I can’t recall anything I’ve bought as a commercial product recently that even had a block diagram, much less a schematic. In fact, several things I’ve recently bought even had part numbers laser etched off the components on the circuit board so you couldn’t even tell what part it was that needed to be replaced! Adding cost to the product, while simultaneously rendering it unrepairable.

Won’t Somebody Steal your Idea?

This is the most common cry against open source. I’ve got a few simple responses:

1. Ideas are cheap – execution is everything.
2. Most designs are a logical flow that most engineers would follow when tasked with creating a certain thing.
3. If a competitor, off-shore manufacturer, or kid in a garage wants to take your design, they’re going to anyway.
4. The magic is a small part of the product and not the most important part.

Let’s quickly go over those.

First, ideas are cheap. Everyone uses several things on a daily basis and says “gee, it’d be better if it worked like X” (or at least most of the people I hang out with). So why don’t we all run off to save others from that plight and retire to our islands? Well, because as it turns out, everything is difficult if you go into it enough. You might find that a certain button on a remote needs moved, but then learn about the subtleties of injection molded plastic and why the case would deform if it were moved. Oh, and the circuit board would double in cost because it would require a more complex routing, and on and on. Everyone has good ideas, but time and resources are limited. Many of us work in markets where we simply do not have the demand to make it worthwhile to copy a design. For example, how many paper plate companies are there (high demand) vs. companies that produce servo hydraulic control valves (low demand)?

Second, most ideas are a logical flow. I love telling about the time I was at a company’s booth at a trade show and the engineer and I were talking up a storm about our favorite analog to digital converters and some new connectors coming on the market. We were openly sharing and discussing our experiences with these parts and knowingly helping one another. Later I came back and a salesman was at the booth. I asked to see an instrument. They had the case open to wow their customers with the wonders of technology (really just a PCBA stack). I saw this and said “oh cool, you guys decided to make a separate DSP layer in the stack so you can change it. Clever!”. The salesman quickly shoved the instrument back together and wanted to know what company I worked for. The point is that for a lot of problems, engineers will come to either similar or equivalent solutions. They may not be identical, but as engineers we all share the passion for elegant, simple, yet clever designs. So did I learn anything there at that booth I didn’t know? Sure. Did it put them out of business and make us the industry leader in X? Nope. Did I share some of our findings with them that are likely in a current production model? Sure did! Guess what? We both still have food on the table. Collaboration raises the tide for everyone – it also forces us all to keep innovating and improving. Otherwise somebody in their garage will come in and put us all out of business. If we ever become that obsolete or blind, then that’s Darwinian selection in the cooperate world.

Third, if someone wants to rip you off, they will. Don’t want to share how your product works? That’s fine, but be prepared for someone to reverse engineer it anyway. Will they? Depends on the product. With software it is a bit easier to secure (though decompiling is a thing), but with hardware people will X-Ray, probe, delaminate, trace, and scrutinize your design if they want it badly enough. In an effort to make those things hard, you end up making it hard to use for your customer and everyone just has a worse day. Dominate the field with your design, offset yourself with your support, and you’ll be a force to be reckoned with. Am I saying that you need to write a blog post on how the secret sauce works? No! But trying to make your design copy proof is a fool’s errand.

Finally, the magic. It’s likely that most of the product is “support” material. In hardware that means it is the power supply, or the buttons for the user to push. In software it is the driver code or the test matrix. Things that the user never really should know or think about. The user wants to use your thing because it solves a problem. Solving any problem is mostly legwork and a small percent magic most likely. Generally the details of the support material are irrelevant – any engineer can design a power supply for a simple digital circuit or write an I2C driver for an ADC chip. Theirs may be different than yours, better or worse, but it probably does the same thing at the end of the day. Again, let me state, your user doesn’t care. Spending so much effort to hide the details of non-crucial things again seems like a waste of precious time. It also costs you money!

How We Can Support Open Source

As a developer and as a company we support open source projects a couple of ways and you can too! The most obvious way is to donate. We donate to projects that we use to make money because honestly, it seems right. We are taking the sweat from folks weekend and night labors of love and turning it into cash. While they are willingly giving that time, or in some cases being paid partially by a funding organization, they are choosing to help us and we choose to help them. Our contributions aren’t huge, but I hope one day they can be. Either way, a few hundred dollars here and there can buy some developers a round, pay for a weekend of chasing a bug down, or help fund a hackathon. If there weren’t an open source option, we may be using a commercial package that costs orders of magnitude more, so it is a good deal for everyone.

We also contribute code. If we find a bug, we fix it. Not only do we do that, we contribute it back upstream so everyone can get the benefit. While we don’t yet have a policy allowing our team to devote some percentage of their time to open source, I hope we do one day. In the meantime we encourage our clients to make certain aspects of their project open source, especially if it is a generalizable and non-trade secret thing (like taking an integral) that many could benefit from. The coolest thing that’s happened is a gravitational tide program we wrote to help chase down a timing issue in some data, ended up integrated in a commercial gravimeter! People are out there flying surveys every day and somewhere underneath all of that data is a snippet of code I wrote while supervising a study hall in Pennsylvania one evening. It’s a great feeling and we love giving back to the community that we glean so much from.

It’s not all roses

Okay, so open source is the dream and we all hold hands, singing traditional songs together at the conferences right? Absolutely not. Sometimes someone does maliciously take something and try to turn it back onto its creator. Sometimes a bit of code gets used in a wildly successful commercial product and the creator never sees even a $20 tip for a drink. It happens. We move on. I’ve seen a product taken right out from under us, but then the burden of execution is passed on and we move to the next creative product on our large list of things we want to accomplish.

Does the customer care? No. I know of very few customers who would know much about open source or care if their product is or not. They DO care about if it can be fixed, if they can make it do what they want, but they likely don’t care if you picked the GPL or BSD license. They also likely do not care if your CAD files are available or what format they are in. They likely don’t plan on cutting their own circuit board and don’t need or want your GERBER files. Should you have them available? If you’d like. You can always send them if you want when someone asks.

Finally, there are some who believe if everything isn’t open, then the product isn’t. I’m sorry, but we can’t give you the details of each and every chip on the board – most of it isn’t available to us. Nor is it useful to anyone other than a silicon fabrication facility. Also, no I can’t get the same results from a free 3D modeling program and our manufacturing process is tied into the AutoDesk workflow. We can’t provide those files in a way that is useful without a great effort – and why would anyone want our toolpaths the mill used to make the enclosure anyway? (Unless it is for a zero effort direct copy.)

What About OSHWA?

The Open Source Hardware Association (OSHWA) does a lot of great things including hosting a great conference. They launched an open hardware certification back in 2016. We don’t participate. I don’t think it’s a bad thing, in fact, I applaud those that do it. For us it simply isn’t worth it. Most of our CAD/CAM is so tied into our internal ERP inventory system that it is nearly indecipherable without access to our inventory. Sometimes a product is 20% hardware and 80% firmware cost to develop and we have to be sure we can get a return on that developer time. We generally release as much as is useful or as we can. Some products are legally protected either by an NDA from a component manufacturer or by a national defense restriction (if it can fly a missile, we can’t tell you exactly how it works).

To be honest, we’re still struggling with the best way to do this. Making the GitHub repo public is an easy solution, but also releases everything, which as mentioned, may not be an option. Making a public version is an upkeep and maintenance nightmare. We still want to be able to take patches and bug reports though. Currently we’re releasing schematics and other documents in the product documentation. That has a nice sanity to it. So while we don’t want to deny access to useful materials, we also do not want to hand off a ready-to-manufacture product with all of the associated files to a competitor on-shore or off-shore. That being said, I can’t remember a time a customer has requested information that we had to deny that request and I hope that time never comes!

Finally, there are liability issues for us. We’re not a random hacker in a garage, we’re a business that has real legal obligations if our products, code, or files hurt anyone. Suppose a customer took some firmware and made a poorly executed code modification that resulted in a fire, accident, or other catastrophe. We could easily find our selves in court defending that it wasn’t our code or product that caused loss of life and property, but the modifications made to it. We may or may not win, but either way it would be costly and certainly negate the value of that product.

A couple of final thoughts: be sure you pick a license to release your work under, release as much as you can, and help out other projects with time or funds when possible. We love working with the open source community and being an active part of it. Help others, do what makes you happy, and remember that at the end of the day we’re all in it to make things better than they were when we got up this morning!