feature article
Subscribe Now

Does “Open” Foster Innovation?

TSMC held their Open Innovation Platform (OIP) event not long ago. One of the keynote speakers was ARM’s Simon Segars, and he spoke about the benefits of openness, starting with the contrast between how closed the PC market is and how open the phone market has been.

<sound of needle ripping across vinyl>

Whoa, whoa, whoa… let’s play that one back, more slowly.

He showed a picture of a standard desktop PC box as an example of an extremely closed system and then a slide with all of the different phones on it as an example of openness.

My first reaction was the irony of this, if you’re old enough to remember the early days of the Mac. The Mac had fierce adherents, but there were also equally fierce haters that would complain about the GUI “Nazis” (yes, I heard that word used; Godwin’s law in fine form) forcing all programs to look the same. So, at that time, the PC was the “open” system, since anyone could build peripherals for it and write software to look any way they wanted.

Obviously the PC look became more uniform as time went on, but I still had a hard time seeing the PC as the bastion of closedness.

Another moment of thought brought yet one more incongruity. What is universally credited with revolutionizing the cellular phone industry with innovative new capabilities?

The iPhone, of course. And the iPhone has to represent the most closed environment to exist since the days of IBM Big Iron. Back then, you could buy only IBM software for your IBM mainframe (that is, until “tying” became illegal). Now, granted, anyone can write applications for the iPhone, but they must be vetted by Apple, and they can be sold only through Apple’s channels, and Apple gets 30% (or whatever) of the revenues. This gets to the “gatekeeper” or “tolltaker” issue (and a tolltaker in this context is often not much more than a bridge troll).

So here we have an ultra-closed environment being credited with innovation as contrasted with a relatively open platform. What gives?

I’m not sure if Mr. Segars intended for this particular topic to be over-analyzed, but if I’m “good” (goodness being debatable in this context) at anything, it’s over-analyzing. So seatbelts on; here we go.

The first real question is, what does “open” even mean? And you don’t have to take more than a couple of steps down that gedanken-path before you run headlong into another question: “Open for whom?”

Let’s start with, “Open for developers.” And developers often like openness, since it can often be interpreted as, “No constraints.” You can be as innovative as you want to be, and no one is forcing you down some path.

Then there’s open for “customers.” In this case, a customer could be an end user, like a consumer purchasing a phone, or it could be a downstream developer buying something from further up the food chain, like a system integrator pulling in IP.

These latter folks also want no constraints, but that means something entirely different. It means that they can plug and play and swap all different kinds of options in any combination. It means that they can pick all kinds of software to run on the system they choose. It means they’re not limited to a particular vendor or hardware style.

And that typically means that we need standards of some sort so that, if you swap two peripherals or memories or whatever, they’ll still work. And here’s where it backfires: the standards that yield openness for these folks represent constraints for the upstream developers.

If you’re designing memories and you think you have a fabulous idea on how to do something innovative that your customers (and their customers) will love, it may require, for example, an interface unlike the one that conventional memories use. This is doubly good for you because, not only does your technology work better, but, since you’re the only one doing it that way, you lock your customers in and they can’t go elsewhere.

In other words, your openness, or freedom to do what you want, closes off that same freedom for your customers.

And this is more or less how the phone market works. Yes, there are many different brands and technologies vying for your favor. But they are mostly incompatible with each other. In fact, they’re so closed that you can’t even be guaranteed that a given phone will work with your service provider: if you change service providers, you may have to buy an entirely new phone. That’s hardly open.

That has been alleviated to some extent by Android. It, like Java, inserts a software layer between the hardware and the applications. Now an application written for an HTC phone might not work on an iPhone, but it can work on a Samsung phone. So a group of phones now appears more open in that applications can be used across a number of otherwise completely incompatible phones. Of course, while that makes it easier for a software developer to attack a larger market with a single project, it still imposes the constraint that the software adhere to the Android API.

And this offers up an opportunity to look at openness from yet another angle: “At what level is something open?” Let’s start at the bottom of the food chain with some examples. Individual components tend to be more closed. MEMS devices, for example, tend to follow the rule laid out by Yole, which states that each MEMS device gets its own process and package (and which was later augmented to add “test”). Everything is done from scratch, and development takes years. This is slowly changing as MEMS starts to explode as an industry, but it’s got a long way to go.

ICs fare a bit better. IP is more interchangeable than it used to be, and, in theory, one has a choice of foundries to go to. But, once you’ve committed to one foundry, you’re more or less locked in – especially on aggressive nodes – since the design is closely tied in with the foundry capabilities. Switching foundries means tweaking the design and spinning a whole new mask set that will work only at the new foundry.

One manifestation of this is the use of “open” to refer to the PDK files and other technology interchange elements that TSMC has worked on over the last few years. Prior to that, each EDA tool had its own way of taking in various types of process information, and each foundry had a different way of serving that information up – lots of wasted work just futzing with formats.

So the TSMC “open” approach provided a uniform way for all EDA tools to access the information. But that’s only half open: it completely disregards the existence of other foundries. If it were truly open, then it would be a standard (or a constraint) allowing full mix-and-match between EDA tools and foundries. Of course, as far as TSMC was concerned, they simply had an EDA problem; they have no motivation for making life easier for their competitors. And, given their position, they don’t have to. But the fact remains that the formats are only partially open.

Moving up another level, we get to the platform. For example, your typical PC will use an Intel processor (or one that is designed to work like an Intel chip), but everything else in the system could be sourced from any number of vendors. The CPU tends to define the functionality, and that’s very simply because software has to be compiled to that CPU. All other differences can be handled through drivers. (Yes, drivers require work to write, to be sure. But the very reason they exist is to eliminate software dependency on hardware.)

Then we move up to the level of the OS. And this is really where things can open up dramatically. So, for example, phones that use Android may use different CPUs. It requires that Android itself be ported to the platform, but once that job is done (“once” being the operative word), then all Android applications should work. Java provides similar capability – at the expense of performance, of course, overlaid on an OS like Windows.

Before we conclude, there’s one other meaning of “open” that we should consider: the one that we find in the phrase, “open source.” This means something totally different; it means that one person’s innovations are made available to others for proliferation and improvement. It is this meaning that probably represents the most useful interpretation of the word “open,” because it offers technology up for reuse without applying constraints at the same time (ignoring for convenience the issue of licensing).

So what does all of this mean? Well, realistically, it means that the word “open” is easy to throw around for any purpose that suits your immediate need. One person’s freedom is another person’s constraint, just like in real life (your freedom to smoke anywhere constrains my freedom to breathe clean air anywhere – and vice versa).

If we roll this back to where we started, there was a suggestion that openness has fostered innovation. That is probably true with open source, but if we set that aside, we have seen innovation in the PC world in the past – declining as it matured as a technology, and we have seen innovation in the extraordinarily closed Apple environment. And Wild-West openness for developers can slow market growth as users get confused as to what works with what or balk at being tied into proprietary technologies (which may be very innovative). To customers, that means “closed.”

So open may be good in some cases. And constraints may be good in some cases. You have to pick and choose where to apply them. In some situations, openness can foster innovation, no doubt. In others, it can get in the way. And even whether something should be considered “open” or not is subject to interpretation.

I think the only real conclusion I’ve come to with this mental exercise is that there is little solid correlation that can be drawn between “open” (whatever that means) and “innovation.” If you simply limit the meaning of “open” to whether or not a sales channel is open (e.g., non-Apple peripherals) or closed (e.g., anything Apple), then the “open=innovation” proposal falls immediately on its face.

One thought on “Does “Open” Foster Innovation?”

  1. We’ve deconstructed “open” and “closed” here. What do you think? Do you find a correlation between openness and innovation? And if so, what is your definition of “open”?

Leave a Reply

featured blogs
Jan 26, 2023
By Slava Zhuchenya Software migration can be a dreaded endeavor, especially for electronic design automation (EDA) tools that design companies… ...
Jan 26, 2023
Are you experienced in using SVA? It's been around for a long time, and it's tempting to think there's nothing new to learn. Have you ever come across situations where SVA can't solve what appears to be a simple problem? What if you wanted to code an assertion that a signal r...
Jan 24, 2023
We explain embedded magnetoresistive random access memory (eMRAM) and its low-power SoC design applications as a non-volatile memory alternative to SRAM & Flash. The post Why Embedded MRAMs Are the Future for Advanced-Node SoCs appeared first on From Silicon To Software...
Jan 19, 2023
Are you having problems adjusting your watch strap or swapping out your watch battery? If so, I am the bearer of glad tidings....

featured video

Synopsys 224G & 112G Ethernet PHY IP OIF Interop at ECOC 2022

Sponsored by Synopsys

This Featured Video shows four demonstrations of the Synopsys 224G and 112G Ethernet PHY IP long and medium reach performance, interoperating with third-party channels and SerDes.

Learn More

featured chalk talk

Solving Design Challenges Using TI's Code Free Sensorless BLDC Motor Drivers

Sponsored by Mouser Electronics and Texas Instruments

Designing systems with Brushless DC motors can present us with a variety of difficult design challenges including motor deceleration, reliable motor startup and hardware complexity. In this episode of Chalk Talk, Vishnu Balaraj from Texas Instruments and Amelia Dalton investigate two new solutions for BLDC motor design that are code free, sensorless and easy to use. They review the features of the MCF8316A and MCT8316A motor drivers and examine how each of these solutions can make your next BLDC design easier than ever before.

Click here for more information about Texas Instruments MCF8361A Sensorless FOC 3-Phase BLDC Driver