Free software is decades old, and while its principles have aged well, they are a bit more removed from everyday computing than they were when they were written. This is unfortunate, since computing is steadily increasing its role in our everyday lives.

I think about this a lot because digital tools are a way to multiply yourself, like powersuit that confers not just additional power, but new capability as well. When those tools are not yours, and especially when they are controlled by someone else, it's tempting to leverage the tool's capabilities just enough to get the job done, without ever gaining true proficiency.

This is a lost opportunity: when you give someone ownership of their tools, and the opportunity to invest in their own mastery of those tools without fear that someone will strip that away, they can become adept. But this is rare nowadays: our operating systems, apps, and services have all set an expectation that the user has little say about how software behaves, including when and how it changes behavior.

For comparison, consider the years of training that goes into learning to play a violin. It's a difficult task that requires a substantial investment to gain proficiency. Would such an investment be advisable if a product manager changed how the violin worked every couple of years? What if they simply discontinued violins altogether in favor of guitars? Musicians would become disillusioned, since mastery would lose its value.

If you're interested in becoming great with your tools, you'll have to pick tools you have control over. I've worked on developing mastery with Linux, Emacs, and Tiddlywiki, for example. All three are now a permanent part of how I live and work. Reflecting on the beginning, I was learning how Linux worked when Windows NT was a thing, and when MacOS 9 was the latest version available. Yet, most of what I learned then about running Linux day-to-day is still relevant more than 20 years later, from compiling the kernel to working with package management. More importantly, I feel like my tools are working for me every day.

Depending on your field, sooner or later you'll encounter tools that you don't have control over. That's okay! This isn't about dogma or some kind of ideological purity, but rather the practicality of investing time and energy where there's the most payoff, not just today, but over the coming years. This means there is no right answer, but there's still a good way to proceed.

So, my advice when picking a tool is to ask a few questions:

1. Is this tool something you'll use again and want to be good at? If so, think about what other tools are available that you can leverage, and then compare them both and how well they can accomplish you goal today, as well as into the future. Don't be shy about taking 15 minutes to research this!
2. Whose computer is the software running on? This is the first question that digs into who will make decisions about your tools. If they don't run on your machine, they can go away at any time. It becomes critical to consider whether you trust whoever owns the computer to let you run the software when you need to. In cases where you 'own' the computer but you don't have full say about what it runs, consider who does. This is very relevant if you're using iOS, since Apple has final say about what those devices are allowed to run.
3. Who determines what versions of the software are available? If only a company can produce new versions of the software, consider what goals the company has, and if they align with your own. Ten years ago, folks might point out that 'if you are not paying, you are the product.' This was true, but didn't go far enough. These days, you need to look out for cases where you are paying and you're the product (e.g. Apple devices, Android devices, smart TVs).
4. Who determines which version of the software in running? Often software can be downloaded and run on a local device, which can allow the user to decide when to upgrade. But modern app stores will often auto-update locally installed software with no indication of what changed. This is doubly true for software-as-a-service, where the end user has essentially no control over what version is running.
5. Who determines how the software behaves? Ultimately, as the software changes, those changes will be in pursuit of some goal. Think about whether you have the same goal as the software authors or not.

These questions might seem academic, or theoretical, but my experience tells me otherwise. I've settled on a mix of cutting-edge tools that I have less control over (MacOS, GitHub, Google Docs, and Chrome) and older tools that I control more completely (Linux, Fossil, Tiddlywiki, and Firefox). This allows me to learn and leverage new technologies while still being able to fall back to powerful, customized tools when I need to.