I like transparency (but not in clothing. Leave something to the imagination, people!). If you’re a merchant and don’t accept returns after a certain period, tell the buyer and make the sign BIG. If you advertise that a plane ticket costs $100, make sure that includes all charges and fees — don’t throw them in at the end of the transaction process. Cell phones are now buyable by the month, with vastly differing prices depending on the term of the deal. So how much does the phone cost, in total? Not transparent.

In the world of software, things get even more complicated. Software providers are under no obligation to show the buyer what happens under the hood, in the kernel or solver or other proprietary algorithm. A question goes in, an answer comes out. If you’re using a solver, you may validate those inputs and outputs against a physical test to make sure the result is as expected. For a geometric kernel, does your surface look like it should? Do downstream operations work? Then it’s probably OK.

While we might not get transparency we, as software consumers, should get openness — the notion that information flows to and from the developer’s proprietary components in a way that enables discovery and usage, and that builds that proprietary part into a larger whole, a platform.

One thing to clear up right away: open is NOT open source. Open source software is fully transparent, with lots of people and entities collaborating on its core and ancillary features. OpenFOAM, for example, is an open source CFD code that has hundreds of developers across academia and industry. They discuss, prioritize, fix/break as they wish and, in return, get free access to the product they helped create. “Free” here means at no cost, and with the ability to use as much as they wish, alter it to suit their own customization needs and distribute it to others.

Openness is very different. A software vendor can be open (in this sense) and not make proprietary software available to others, except via APIs, application interfaces that are programmatic goesintas and goesoutas. Partners can use the APIs to add their own content on top of the core proprietary product.The way the licenses for these APIs are crafted can help or hurt how open a vendor is (that’s the subject of the next post in this occasional series) but their basic goal is to allow others to add value to the market without having to reinvent the core. Prime examples in our world include PDM systems that rely on CAD data but are not sold by the CAD vendor; pre- and post-processors for simulation; visualization tools that make CAD models look amazing and more — it’s a huge list.

I was recently introduced to the term “fauxpenness”, which I think started here (if you know differently, please leave a comment. But click on the link if this interests you — OSS Watch has a lot of great content.) As it was described to me, fauxpenness is when a product or platform is advertised as open when, upon closer scrutiny, it turns out to be under the tight control of a provider who restricts access or does things to lock in a partner developer. One example is Apple’s iOS: don’t know if this is still true, but for a long time, Apple didn’t let anyone but its developers do things with the health data collected by iPhones. That’s 100% Apple’s right, but it means that (at least while this is true) iOS isn’t open. Another example is telling a development partner that a product developed on one overarching platform for PLM or web services or cloud computing or anything else can’t be modified to suit another platform — again, the platform owner’s right but would lead to fauxpenness. Enabling partners, but restricting them at the same time isn’t true openness.

OSS Watch says that “Openness in technology impacts the sustainability, applicability, interoperability and trustworthiness in the system” and that you’ll know how open a software product is by how well it complies with standards. how well product and process information is communicated to partner companies, as well as the market-building business practices the core vendor uses to grow the overall platform’s presence.

Why does this matter? For me, it’s that first one: sustainability. We know that many of the objects built in our engineering-centric world have very long lives, and that we may be called upon to dig up the CAD model of a 30-year old ship, airplane, refinery, train or car at a moment’s notice. We might need to work backwards from a broken rotor blade to the engineering calculations that said it could withstand that fatal load. If the platform used for the design or simulation wasn’t sustainable, we’re in trouble now and need to do some quick stepping to figure it out.

But for many others, it’s interoperability. No one vendor can create every product needed be every buyer in every industry — they need to build a structure that enables partners to create what they can’t or won’t, for the ultimate benefit of the buyer. And if the partner creates a great solution to a customer problem, why can’t it be available on more than one CAD or PLM or cloud or or or … platform?

Openness can be incredibly difficult to see from the outside; that’s the “fauxpenness” OSS Watch sees obscuring reality. You can read more about research I did on platform openness here. If a platform vendor creates a solid, open and extensible platform, it should check all of the boxes identified by the people I interviewed.  As I’ve written before, you can’t know what your business will need in 5 years or in 10 years so you need to carefully select an ecosystem that can evolve with you.

@abausk tweeted that “fauxpenness” was introduced by Tristan Louis: https://t.co/e4lcAHlseQ . Now we know. Thanks!