On "Open" Proprietary Software

There’s been a lot of buzz from various proprietary LMS and SIS vendors lately about how “open” their respective platforms are. I think it’s important that we have a sophisticated notion of openness that is more nuanced than all or nothing. At the same time, I also think it’s important that the word be grounded in reality and not reduced to meaningless marketing-speak. I don’t claim to have any definitive answers as to what should be labeled “open” under what circumstances, but I would like to explore the concept a bit further by reflecting on the ways and degrees to which Oracle’s PeopleSoft Campus Solutions (CS), the SIS platform that I happen to work on, may be “open”. Note that, to my knowledge, Oracle hasn’t run any big marketing campaigns touting CS as “open” and I’m not making any grand claims about it either. It happens to be an example that I know relatively well and as good a place to start as any.

So here’s a non-exhaustive list of ways in which proprietary software could be called “open”:

  • Open Data: Starting at the bottom, can you get to your own data in ways that suit your needs? Note that there are several ways in which this goal might be realized. You might be given the database schemas and be allowed to write SQL queries against them, or you might just be given some sort of API or export format. CS provides the database schemas. As far as I’m concerned, providing this level of openness is pretty bedrock and not especially noteworthy or praiseworthy. If you can’t get access to your own data, then your vendor has you by the short hairs.
  • Open APIs: There are several different ways that APIs can be “open”. They can be published, meaning that anybody can read them. But just because you can read them doesn’t mean you can use them. They can also come with a license that says you can write to those APIs without needing to get special permission (or make a licensing payment) to a vendor. As far as I know, CS provides the latter. That said, it’s hard to actually test any code you write against those APIs if you can’t run a copy of the software itself. As with all proprietary software, you have to pay a license fee to use CS if you want to do that. If you’re a customer, you’ve already done that. If you’re a third-party developer, it gets more complicated.
  • Open Standards Support: Of course, publishing your own APIs is not the same as agreeing to use the same APIs that your competitors use. That would be open standards support. Of all the kinds of openness listed here, open standards support and open data are the two most important to minimize vendor lock-in. Of course, there are quite a few potentially relevant standards out there; no platform that I know of supports all of them. But CS supports (and in some cases leads) in the relevant education-specific IMS and PESC standards and also supports a wide range of broader industry standards (like LDAP, SOAP, and the like) with more (like SAML) in the works.
  • Open Code: Sometimes, database and API-level access isn’t enough. Sometimes you need to get at the source code to make the customizations that you need.  PeopleSoft has its own object-oriented programming paradigm using PeopleTools and PeopleCode. In CS, customers have full access to all of these objects. Now, PeopleTools and PeopleCode are, in turn, written in C++. Customers do not have access to that level of the code, as far as I know. That said, you have to be a paying customer (or partner) to access CS code. This is the defining difference between open source software and proprietary software.
  • Open Support: This one is a little fuzzy, but the basic idea is how much of a right do you, as a customer, have to share access to your system with a third-party support vendor. This can get legally complicated. For example, I know of one school that is in the process of migrating LMSs but has hit a bit of a wall because they don’t know whether the non-disclosure clause in their license agreement with their current vendor prevents them from hiring a third party to access the system and migrate their courses for them. CS contracts allow for third-party vendors to provide a wide range of support services, including services that let them host the software, log into it on the customer’s behalf, and see any documentation the customer is allowed to see.
  • Open Use: It is possible for proprietary software to be free to use. Sometimes it is free to use under all circumstances, in which case it’s usually called “freeware”. In other cases, a limited use free license is available; for example, you might be able to use the software free for development purposes and only have to pay if you put it into production. I’m not aware of any such free access to CS.
  • Association with open source software: This is a bit of a strange one. Some vendors are touting their openness because they integrate with open source software (though not necessarily through open APIs or open standards). Let’s call this one the “character witness” play. I don’t put a lot of stock in this one, but for what it’s worth, CS integrates with both Sakai and Moodle—using the IMS LIS open standard.

I’m probably missing other ways in which proprietary software can be more or less open. And again, I am not trying to make any special claims about the “openness” of CS. Rather, I want to lay out the spectrum of possibilities using CS as one example. When vendors tout their “openness”, it’s important to ask what that means.

Share Button

Google+ Comments

About Michael Feldstein

Michael Feldstein is co-Publisher of e-Literate, co-Producer of e-Literate TV, and Partner in MindWires Consulting. For more information, see his profile page.
This entry was posted in Ed Tech. Bookmark the permalink.

2 Responses to On "Open" Proprietary Software

  1. Hi Michael,

    Indeed, open is the most overused buzzword of the moment. That’s a nice checklist you came up with here, I hope decision-makers in higher ed are all aware of this and will learn to ask the right questions to their vendors.

  2. Patrick Masson says:

    I might add open development/governance? This would include practices that decentralize authority, distributing decision-making outside of the organization to the user community. Essentially the direction for product development would be determined by those that use the products, and the features in those products, rather than by marketing, trends, commercial goals, etc. I would say an example could be Google which using customer interactions with the product to drive further feature/product development rather than traditional research, development and marketing approaches.

Comments are closed.