Keeping the platform open
Written by mufasa
In the past, software platforms have often been used to lock developers in. This led to a drive for open standards so that no one company could control the platform and to give all the implementers input into the standard. However, the standards process is largely a relic of hardware standards and doesn’t really work for application software. Standards are best suited to network protocols that are programmed into routers, routers for which the software then stays the same without being updated for years. The modern PC is updated very often, at least 2-3 times a year, so the standards process is a straight-jacket on desktop software. It takes years for the standards bodies to reach consensus on a standard, which once ratified shows the dents of design by committee and then cannot be modified easily. The inadequacy of HTML/HTTP shows the results of this process. I will now suggest a way to keep platforms open, open to developers and competition, without the standardization that chokes off innovation. I believe these concepts should be used for a new thin client but they can be applied to almost any new software platform, such as rich clients, widget toolkits, or other software libraries.
First, let’s look at each of the ways that companies can potentially lock up a thin client platform: APIs, copyright, and patents.
- APIs – Although it appears that there is no protection for APIs, software copyrights are murky legal territory so it’s always better to be safe. The people behind an open thin client platform should not assert any intellectual property rights over the public APIs. Also, any API that is disclosed to one licensee should be disclosed to all licensees so that some developers don’t have access to exclusive APIs. These protections will allow a competitor to reimplement any APIs, just as the Wine guys have reimplemented the win32 APIs (though they better watch out as Microsoft might use this API issue to come after them some day). Of course, just because a competitor is free to reimplement the APIs doesn’t mean that is all there is to it. Open standards have a full specification that lays out much of the design. However, I see no reason to require an open platform to have an open specification, this decision should be left up to the creators. Outside developers can often figure out how the original implementation works and reimplement it, provided the original license does not prohibit doing so. Often this is the best way to reimplement software, as almost no specification is so precise that it lays out every detail of the implementation accurately. If there is an external API, a developer should be able to figure out how it works from the software, so there should be no licensing prohibition against using the original implementation to gather knowledge necessary for reimplementation. A thin client will have a compact set of documented public APIs so it should be easy to reimplement.
- Copyright – This is the main way in which software is currently protected and copyright is necessary to both closed and most open source software and business models. While open APIs allow developers to build on top of a software platform with the assurance that they’re not locked in, they do not allow the developer to modify the thin client binary itself. I see no reason to add any requirements about this however, as it should be up to the people who develop the platform as to how much control of the software binary itself that they want to give to third-party developers. Some will allow plugins and other modifications, others won’t. This is often a security issue and there are a range of possibilities: it should not be necessary to restrict the developer of the platform in this regard. I suspect that most software in the future will be a mixture of open and closed source- rather than exclusively one or the other as most of it is now- so I don’t think exclusive, monolithic control of a software platform through copyright will be much of an issue in the future.
- Patents – Let me start off by saying that most software patents are a joke and are only possible because the current patent system is a complete debacle. However, as people use software patents anyway and a few have some justification, I’d like to account for them. What’s important for a software patent is that all patents on an open platform must be disclosed. Also, no disclosed patent can restrict someone from reimplementing a feature of the platform because it is the only way to implement it. So for example, if someone were to patent quicksort, you could always use bubble sort so that’d be okay. However, if someone were to patent something ridiculous like Akamai’s distributed hosting patent, there would be no way to implement something similar so it wouldn’t be kosher.
Taken together, these restrictions can make up an Open Platform Promise, or OPP, consisting of the following:
- No intellectual property rights will be asserted on any publicly disclosed APIs.
- Any APIs that are disclosed to one developer will be disclosed to all developers.
- No restrictions will be made on usage of the software to help reimplementation.
- All patents will be disclosed.
- No patent can preclude reimplementation of a feature of the platform.
Some may wonder why all this discussion of intellectual property is even necessary. My argument is that software platforms can be extremely widely deployed- a thin client platform in particular- so it is important to consider issues of lock-in and monopoly. Most current software platforms are either at one extreme of closed-source, patented software, exemplified by Microsoft and their win32 APIs, or the other extreme of open standards often implemented by open-source toolkits, exemplified by HTTP/HTML. The goal of the preceding is to fashion a melding of the two extremes that works better than either one does individually. I do not address the issue of open- or closed-source as I believe that most software will end up being a mix of the two. Instead, I address the other API and IP issues that go with keeping a platform open. The goal of the OPP is to allow developers of a platform to create something they can own and improve upon while allowing third-party developers the freedom to choose their platform and its implementation.
Questions:
- I’m no intellectual property lawyer so I’m going to need more info from those who’ve dealt with this stuff in more detail. What other provisions do software companies use to lock developers into a software platform?
A few key problems with that:
—When you have a dominant implementation and no requirement that new APIs work through a standards body, whoever owns the dominant implementation sets the de facto standard. I believe this is actually what you want. But it means that the bugs in that implementation also become part of the de facto standard and must be reverse-engineered by all other parties. That creates a non-level playing field, because the dominant vendor has less work to do than the non-dominant vendors, further entrenching their lock-in.
—Also, only new features proposed by the dominant vendor are relevant. Other vendors may create new features, but the dominant vendor can either ignore those features, or more likely, implement them with a different API so that the other vendors now have to implement two APIs for the same feature. This further disadvantages the non-dominant vendors.
—With “de facto” standards, the dominant vendor by definition is always more standards-compliant than anyone else, and offers the new features before anyone else. That’s another tilt against the non-dominant vendors.
The strategy of creating work for your competitors was/is so popular at Microsoft that they had a phrase for it in common use
-“putting the competition on a treadmill”.There may be a way to cut out the standards process and retain a level playing field. That is if the dominant vendor’s code was bound by a strong copyleft license, such as LGPL, or GPL with some limited exceptions. That would help other vendors by allowing them to build their products as variants of the dominant code and “slipstream” off all the improvements and compatibility guarantees of the dominant vendor. It doesn’t solve the “new features” problem, however; the other vendors will still lag behind. There may also be clever ways to subvert the system. So I can’t be sure this is a good way to go.
Just a few short notes:
Overall, I don’t think there’s a sure way to reach a good design, but a good rule of thumb is that the best (simplest) initial designs seem to be reached by individuals with a good overall grasp of the problem. Perhaps, after the approach has been tried and tested, it is then time for a committee to step in and agree on a more stable standard, if the original vendor keeps changing it just to keep the competition out.
Wow, great comments! Thanks for the feedback.
Robert – Yes, you’re right that I would prefer de facto standards to standards devised by committees, provided the above protections are included. Let me begin by noting that none of the problems you pose has been solved by open standards. These are the very issues that people gripe about with IE despite it implementing an open standard in HTTP/HTML. I think a lot of the problems you just described come from the presumption that every app should run on every implementation, which is not necessarily the case. There is nothing wrong with having a user download a new thin client runtime/implementation for a particular site and having several platform implementations, which don’t take up much space, on their computer. Then, you just sync data between apps/implementations as necessary. Alternately, application developers can always restrict themselves to a subset of features that work across most implementations and write their apps using those features. This is of course reminiscent of what they do now. My argument is that it is impossible to avoid this: standardization cannot sweep away fragmentation and specialization, which by the way is where innovation comes from. Let us acknowledge that there is no way to avoid those, nor would we necessarily want to, and keep the one benefit of open standards that we want: the freedom to reimplement. The goal of the OPP is to do precisely that. The current open standards route has not swept away fragmentation and specialization while managing to mostly choke innovation.
Regarding your LGPL/GPL suggestion, the problem with those licenses is that to the extent that everybody is forced to open most of their source, it is impossible to make money off the software itself. If you cannot hide the source, you can only make money off of it by charging for add-on services, such as Red Hat’s support or IBM’s consulting services. However, you seem to be hinting at having a mix of closed- and open-source as I referred to earlier. If so, I agree with you that this will allow other implementations to more easily compete and as I’ve already said, I think most software will end up becoming mixed like this.
tuomov – Thanks for the TeX example, I was unaware that it was an open de facto standard. I think it is understandable that FOSS doesn’t have very good design, there’s not much money there. Most of it is just engineers hacking on stuff for fun so I can understand why most wouldn’t be interested in doing actual, tough design work: there’s no money involved. As for using increased complexity to keep competitors out, I’m skeptical that any real business would do this as they then have to deal with that complexity themselves. However, it is understandable in FOSS because if you’re making most of your money on services, it helps to make the software more incomprehensible so only you can provide the service. I think this is a problem particular to FOSS and its sometimes weird business model. I am similarly skeptical that a vendor will keep changing the implementation simply to keep competition out for the same reason: they will pay a large price for maintaining the resulting complex, constantly changing platform themselves.
One problem is that people don’t indicate the “standard” and options they use. They assume that the vendor-specific version of HTML and Javascript (yuck) that they write, is the general standard, and the options the standard ones. Then software has to try to figure out what they meant. If their documents told “I’m MSHTML”, it should be easier.
(A related problem is the assumption of a white background colour: even if people write a CSS stylesheet, they don’t set the background colour, assuming everyone’s browser to have the same default as theirs. Then the page breaks when it happens to be using nearly the same foreground colour as my default background is.)
Yes, but this is only a problem for “open standards” where there isn’t much versioning going on because everybody is presumably using the same open standard (although it is my understanding that most developers do check the browser version nowadays). If you have thin clients with multiple competing runtimes/implementations, you would have versioning built in at a more fundamental level and more developers would be trying to avoid compatibility issues. The second problem you point out with CSS and user customization is one that will be inherent to any user customization system that doesn’t account for these issues. Ultimately, my point is that these types of complexity are somewhat unavoidable and can only be mitigated by building better software, not by legislating an open standard.
I find it a problem that developers (have to) check browser version. Rather, their documents should specify their expectations for the browsers to check. Now they basically lie about conforming to a formal standard , yet don’t or make further expectations that weren’t carefully enough considered in the standard. Everyone is using custom variants of the standard while claiming to conform to it.
I’m not saying everyone should stick to the same standard. State your expectations—that’s what I’m saying.
-Oh, with regard to vendors changing their formats constantly, that I missed on the first reply, one only has to consider MS Office formats. Sure it’s trouble for them to support all the constantly changing variants, but presumably less in the quarterly logic than someone being able to creater a proper alternative to their software.