Try reloading this page, or reviewing your browser settings
This video segment points out how open source programs prefer sticking with open standards that promote interoperability. However, they often have to work alongside proprietary software, which comes in many forms and sometimes actively prevents OSS programs from cooperating.
- Open standards
- data migration
- standards bodies
About this video
- Karl Beecher
- First online
- 25 December 2018
- Online ISBN
- Copyright information
- © Karl Beecher 2019
[Audio Begins] [0:00:00]
Karl Beecher: At its heart, software is all about processing data, and whether c onstitutes the pixels of a photograph of the numbers in a spreadsheet, data is always stored according to the standard. That standard describes how to work with a specific type of digital information. There’s a wealth of standards that comes in all forms. Standards for images, documents, music, video files, hardware devices and so on. There are many criteria to help you choose between them. Every standard has one property in particular that’s of interest here. It’s openness.
You can think of openness as a sliding scale, a measurement. And if you’re coming from the proprietary world, you’ve probably been using at least some software that uses fairly closed standards. If a standard is less open, it might be that its specifications are not available to the public. And so while it’s possible to pass around data written to a closed standard, writing an open source program, when you write that data, is not straightforward. And examples include Photoshop or AutoCAD files. The standard might be publicly accessible, but at the same time under the control of a single organization. This code has risks for anyone writing an open source program that supports such a standard. For example, the standard might suddenly be changed without warning and possibly rendering the program incompatible with the latest version of the standard. Microsoft’s older Office formats would fall under this category.
The standards at the more open end of the scale are both publicly accessible to the fullest extent and under some form of communal control, like a standards body. The accessibility of an open standard means anyone can create their own software implementing that standard and can learn of upcoming changes or even influence the decision process itself. For this reason, open source software heavily favors open standards.
This has a number of benefits for the user, but among the most significant is the open market of applications it creates. Different projects can produce their own programs, which each implement the same standards. This means that applications in the same market space can cater for different needs and compete on various different factors, but they will still all work with your same data. For example, the open document format, that’s ODF, specifies the standard for a range of productivity software. The text documents, spreadsheets, presentations, and so on. And the result is a marketplace of oftly software. You might have simpler versions for beginners or advanced versions for experienced users, light versions with a subset of features, heavy versions laden features, unlined versions, and so on. But you can use the same files with all of them, meaning that you can migrate between office applications with ease. So in moving to open source software, you’re moving to a world where open standards rule.
When migrating your data, you have several options ahead of you. You could convert your data into the new form covered by an open standard, or you could find an open source project that supports the proprietary standard to an acceptable extent. An earlier video in this series, Free Everyday Software Alternatives, discussed these options in detail and explained the considerations involved when migrating within an array of popular software domains. It also suggested strategies.
Something else to keep in mind is the long-term support of standards. And in this case, open source can have both benefits and drawbacks. For example, if a proprietary vendor decided to withdraw support for a feature from one of its standards, there is little that can be done by a user who wishes to keep using that feature except for continuing to use the old version of the program, assuming that’s even possible and they’re not being forced to upgrade. But if an open source project decided to remove a feature from their program, any developers who disagree with that decision could continue to support a version of the program with the feature intact. How can they do this? Well, since the code is open, they could take a copy of the code, put it into a new project, and continue development on that copy. This is called forking, and it results in two versions of the original program. For instance, this is what happened in 2011 when Open Office was forked to create LibreOffice, resulting in two competing office suites. LibreOffice has gone on to enjoy the greater success of the two.
One the one hand, this ability to fork is good. It prevents users from being powerless in face of decisions made on open source projects. On the other hand, forking can be inconvenient for the user. When two forked projects compete in the same space with the same developers, it can dilute the development effort available for each or shift most of the effort to the newer project and force users of the old project to migrate. But thankfully, forking turns out to be rare in practice. Open source projects have evolved rules and procedures for ensuring continued interoperability and settling disputes. Standards bodies like those that guide the evolution of HTML or ODF have created highly inclusive processes which allows hundreds of companies and organizations to collaborate in steering open standards. This combats fragmentation whereby in open standard it evolves into multiple incompatible implementations. This happened in the Unix world in the 1980s, which is an instructive warning from history.
So the key lessons, when migrating from proprietary software, identify any proprietary standards that you use and come up with a strategy for replacing them or continuing to use them. And choose your new applications and standards carefully. For example, if you value stability, favor widely-supported standards, preferably controlled by open and inclusive governing bodies.
In the next segment, we’ll look at support.
[0:06:13] [Audio Ends]