Closed Proprietary Software (CPS) vs. Open Proprietary Software (OPS)

Next Post
Previous Post

Linkedin vs[Editor’s Note: This is a guest post from Ryan Johnston, a polyglot BPM specialist and Solution Engineer who has worked with a number of BPMS software tools over the years.  He shares our view that proprietary software has a lot to learn from open source and vice versa… In this post, he focuses on what proprietary software can learn about being Open… ]

With all the attention paid to open source software and “proprietary” software, there’s been a lot of confusion about what open means, and an assumption that all proprietary software is created equal.  I would propose that we should start drawing a distinction between Closed, Proprietary Software (CPS) and Open, Proprietary Software (OPS) systems.

If that sounds like I’m borrowing some concepts from the Free & Open Source Software (FOSS) world, you’re right… There’s no question that open source is right for some, but isn’t right for everyone, and yet the concepts of openness and accessibility that open source has forced to the forefront of the software world should absolutely be a part of any discussion about the viability and usefulness of any proprietary software package. Why should we have to assume in 2014 that all closed-source, proprietary systems are going to be closed and difficult to extend?

The answer, simply, is that we shouldn’t. OPS packages have flexible API’s for integration with other packages and leverage open standards. These flexible API’s and open standards allow those investments to be extended through the development of supporting custom and purpose-built packages, and the connection to and from other software systems. The ability to extend those investments can be a significant differentiator for a business and could allow that business to have a leg up on its competition.

On the other hand, CPS package vendors often intentionally limit or obfuscate their use of open standards to “lock in” their customers to the use of only their package or packages. And it’s not difficult to think of how that could wind up costing those customers millions in additional software acquisition or development costs.

So let’s wander back over to our bread and butter, BPM, and let’s talk about a few examples of where existing packages are open, thus allowing their customers to leverage other software packages easily:

  • IBM BPM leverages open standards in many ways, including by allowing developers to easily utilize industry-standard JavaScript for the manipulation of process data and APIs. No matter what industry your organization is in, you’ll have JavaScript developers, and those developers have a leg up on learning how to build advanced functionality in the IBM BPM tool.
  • Appian allows their customers to extend the functionality of the platform through the development of custom plug-ins, which are written in Java and can be deployed either on the cloud or on-premise.
  • Pegasystems leverages standard HTML5/JavaScript/Cascading Style Sheets for the construction of their user interfaces, enabling authoring of complex and feature-rich UI’s.

The above is not in any way intended as a feature comparison of the tools, nor am I certifying whether the tools are OPS or CPS tools.  I’m just offering some concrete examples and a way of thinking about Open versus Closed in the proprietary software world.  It isn’t black and white, it is shades of grey, and you have to dig into how these tools open up to the outside world to figure out how well they’ll grow with you over time.  I think openness (even with proprietary software) allows their customers to easily maximize their investments in these platforms. And that should be a goal for every software vendor in 2014.