Free Alternatives to Everyday Software

Moving Your Data Across

Your browser needs to be JavaScript capable to view this video

Try reloading this page, or reviewing your browser settings

This video describes the typical challenges of moving to a new open source application when needing to maintain access to your existing data. It explains data standards (both open and proprietary) and the use of import and export.

Keywords

  • Data
  • files
  • migration
  • standards
  • formats
  • import
  • export

About this video

Author(s)
Karl Beecher
First online
04 December 2019
DOI
https://doi.org/10.1007/978-1-4842-4377-0_3
Online ISBN
978-1-4842-4377-0
Publisher
Apress
Copyright information
© Karl Beecher 2019

Video Transcript

Karl Beecher: In this segment, we learned about the general challenges you face when you move existing data into new open source applications.

So all programs store data, and whether that data constitutes the pixels of a photograph or the numbers in the spreadsheet, data is always stood according to a standard. Data standard describes how to work with a specific type of digital information that means the ways of writing or interpreting that data are established and agreed upon. For any type of computer data, be it images, documents, spreadsheets, music files, there’s often a wealth of different standards to choose from. Different criteria can guide your choice of standard.

Within each category, some standards are more popular than others. Some are more efficient than others. Some are richer in features than others. But there’s also another criteria to consider when choosing a standard: openness. Some standards are more open than others. Data written according to an open standard means that the procedures for using that data are publicly accessible and subject to some kind of public procedure for changing them. The accessibility of an open standard allows anyone to create their own software for implementing that standard.

So what could make a standard less open? The specifications of a closed standard or not available to the public, and so while it’s possible to pass around data written to a closed standard, you can’t easily write your own software that can read and write that data. The standard might be publicly accessible, but at the same time under the tight control of the single entity. This carries risks for anyone wanting to write software that implements such a standard. For example, the standard might be subject to a sudden change without any consultation and rendering your software possibly incompatible with the latest version of the standard. It’s also possible in some jurisdictions to patent standards. Authors of programs using such standards would potentially have to pay royalties on each copy of the program produced. Something that tends to disqualify opensource software since it can be copied around freely.

Unsurprisingly then, authors of open source programs have a strong preference for open standards which have publicly available specifications or developed in consultation with the user community and are unencumbered by patents. Let’s take that knowledge and see how it plays out in practice. When you migrate from one application to another, you’d have to ensure you can take your existing data with you. Data migration can be relatively straightforward, particularly if both old and new programs use open standards. Examples of open file standards include ODF. That’s Open Document Format. The file format used in many open source office applications. A PDF. Document and image format which was formerly a closed standard open by Adobe until they released it as an open standard in 2008. PNG or ping files for representative images or Ogg Vorbis which is a type of audio file.

If your proprietor application stores your data in open formats like these and your new open source application should be able to work with their existing files without issue. However, proprietary software sometimes stores their data in files according to closed standards. For example, Photoshop stores its files in PSD format. The RAR format with a proprietary standard as are the original Microsoft Office file formats like DOC files. However, just because the standards are closed doesn’t mean open source software can’t support them at some level, but you should be aware of the risks. Often open source program is wishing to support a proprietary standard can’t see the code or secure the corporation of the original programs authors, so they might instead reverse engineer it by analyzing the contents of the files and deducing how it works. That means the resultant open source program might not necessarily support all features correctly. For example, GIMP. The open source image editor can work with Photoshop files, but not always perfectly. A document created by Microsoft Word might not look exactly the same when viewed in LibreOffice.

Everyone’s needs are different, so in each case you need to see which features work fine and which don’t, and whether they open source alternatives support them to an extent acceptable to you. You should investigate whether your new open source program providing input function for converting the old files into a new standards compliant version. And keep in mind that you may in future be working with people who continue to use the proprietary program that can potentially make the exchange of files frustrating. What applications have to handle large amounts of complex data? They usually don’t store it in individual files. Instead they choose to store structured data across a whole load of interrelated files.

Database management systems and email servers are examples of this. Your considerations become accordingly more complex. Let’s take as an example. Moving to a new open source database management system. So how are you moving the data? If you’ve got an export the existing data and import it into your new database, this raise questions. Are import and export features available in the respect of applications? Do both application speak compatible language? For example, many database of store data using SQL. And while SQL is a standard, many vendors either own nonstandard extensions, meaning that what one database exports is not necessarily comprehensible by another without some kind of adjustment. Alternatively, for database management systems that work according to a client server model, you could connect to your existing database server using a new open source client program. In this case, you need to ensure that the client understands what the database service says. In both cases, you also need to be mindful whether the new program support all features you require.

Now, all the considerations we’ve discussed so far can require a lot of technical expertise. If you don’t have the time or the skill to deal with things like installation, maintenance, migration, and so on, then you’ll have to get yourself some support. The next segment, we’ll describe what options you have.