Choosing the right software for the job can be a painstaking process. On all of the major platforms, there is a plethora of tools available for most tasks. Picking the first thing that comes along without evaluating all of the options might save some time up front, but it will lead to headaches further on down the line.
I am critical of all software that I use. I will try all of the alternatives and weigh their pros and cons before deciding upon which one to use. This takes time, and I often end up purchasing software that I will not use in the long-run just to test it out, but it leads me to being happier with the choices I make. I know I am using the best tool for both myself and the task at hand.
There are five criterion that I make sure all of the software I use meets. If at anytime something I am evaluating does not meet one of these rules, I will not consider it for long-term use.
Available across all platforms that I need it on
This point might seem obvious, but what I mean is that for any one task, I am using the same piece of software across all of the platforms that I am doing that task on. By restricting myself to the same application on all platforms, I am able to make sure that I have the same feature-set available at all times. Having to switch platforms just to complete one small part of a task is not ideal.
Sometimes, this requires me to evaluate what the needs of the task are on different platforms. What makes sense on iOS might not make sense on macOS. This forces me to consider which platforms I want to complete the task on. For example, if I only write while on macOS, having a writing application on iOS might not be required.
Long and continued maintenance history
Outdated software will cause problems in the long-run, and it prevents you from taking advantage of new advances in computing.
Software that has a long maintenance history indicates that updates will continue into the future. Software with a successful business model and/or active and large open-source community around it is likely to be maintained for a number of years still. Despite being 40 years old, one of the reason Emacs is popular is that it sees active development.
A long maintenance history is important for software that takes a lot of practice to use. If something takes a few months to master, you don't want to be stuck without recourse should a critical bug be discovered. And being forced to have to weigh spending as much time learning new tools or continuing to use the old antiquated software can be a difficult choice.
Finally, modern security practices mandate using software that is up-to-date and patched. Without it, bugs and exploits could allow catastrophic data loss.
When programs stop being maintained, they tend to fall off the radar. When looking for new tools, I will not consider the one that was last updated 5 years ago. But continual evaluation of all current software is important to. Any application that stops being updated should be considered for removal from use, before a problem arises.
The more complicated the task, the more popular it needs to be
If a program is highly technical but has a small user-base, there's a risk it will be discontinued at some point. Highly technical software takes more knowledge and time to maintain. If there is not a financial incentive or large open-source user-base to help contribute, these applications can die if the creators do not feel that updating it is worthwhile.
The more popular an application is, the higher the likelihood of it being available on multiple platforms.
Operates on open formats
A big danger in saving data in proprietary formats is that one day, they might not be accessible. Proprietary formats might require reverse engineering just to be able to read them. This can lead to different applications handling the files in different ways, leading to inconsistencies in how the data is viewed and potential data loss.
When I was an undergraduate and graduate student, most of my papers were written using Bean, which saves files in the Rich Text Format, and Apple Pages, which uses its own proprietary format. Both formats have different levels of support. Rich Text has multiple versions, and not all applications support each version, opening up the potential for data loss. And few programs support reading the Pages format, let alone saving to it.
To prevent myself from losing out on these papers, I have been converting them to plain text so that the content is saved, as well as PDF exports so that I can see how the original paper was formatted. Doing this while I have access to Pages is important, as LibreOffice seems to be the only viable way to open them outside of the Apple ecosystem, and support for the format is both limited and only recently added.
Making sure all future documents are saved in an open format is a top priority for me. I do not want to risk 20 or 30 years from now not having the ability to open something that was at some point important to me. Right now, this means plain text files or HTML files, as support for them is long-standing and will continue well into the future.
Efficient computer usage
The final piece of the software puzzle is using applications that are efficient at what they do. This refers to two forms of efficiency.
The first is that the interface is well designed. If I feel like I am fighting against the interface and not getting work done, then it is a tool I do not want to use. This does not mean that complicated tools that require practice are out of the question, just that there needs to be a reason for being complicated, with obvious gains that could not be done with a more simplistic interface.
The second part is that the program makes good use of computer resources. Today, this means not using anything that relies on web technologies for their logic and rendering. These applications are slower and use more memory than something programmed natively. This can lead to worsened battery life in mobile devices, and general slowness on all but the fastest desktop devices.
Finding the balance between searching for tools and using them
This is my criteria for all software that I use. When evaluating new applications, if it does not meet all of these criteria, I rule out its use. I also do not constantly try to replace my tools. To be sure, I keep up with new tools released, but given the first point of using something that has been around for a while, I will not switch to it right away. It is easy to fall into the trap of constantly learning new tools instead of using them to do actual work.
OS: iOS, macOS
Used Since: April 2, 2010
Previously Used: Google Play Books
OS: iOS, macOS
Used Since: August 26, 2013
OS: iOS, macOS
Used Since: December 12, 2010
Previously Used: NetNewsWire, Unread
OS: iOS, macOS
Used Since: February 20, 2018
Previously Used: Reminders
Name: iA Writer
OS: iOS, macOS
Used Since: January 14, 2014
Previously Used: Bean, OpenOffice.org, Pages, Scrivener
Used Since: July 16, 2014
Previously Used: Apple Podcasts, iTunes
Used Since: December 22, 2016
Previously Used: Sleep Cycle, Sleep++
Name: Sublime Text
Used Since: July 1, 2011
Previously Used: Atom, Emacs, TextWrangler, Neovim, Visual Studio Code
Name: Alacritty, iTerm
Used Since: December 25, 2007
Previously Used: Terminal
Used Since: July 15, 2016
Previously Used: Time Machine
Used Since: June 30, 2011
Previously Used: Adobe Photoshop CS6, GIMP
Used Since: May 13, 2016
Previously Used: Colloquy, Limechat, mIRC