Picking a technology for internal use

Note: This is part 4 of 4 in a series about making technology decisions. Read part 1 here.

The only kinds of proprietary software Freelock actually pays for are development and testing tools – tools we use to actually create our work products, or provide us with access to tools we otherwise can’t support (e.g. testing across a bunch of browsers we don’t have).

For individual developers/creators, we want to provide whatever tools they need so they can do their jobs best. We allow a lot of discretion in these choices, and don’t mandate any standards.

We do maintain several unusual values as a shop, though, and encourage and support people who want to express those through the tools they select:

• Bias towards open source – Wherever possible, we choose open source. It aligns with our values of working with the community, respecting freedom, providing the ability to self-support, reach core developers, and more. Wherever there is a viable open source solution, that’s our first choice, even if it involves a bit more pain up front to use.
• Strive towards quality results over quick shortcuts (for example, the old HTML editors that inserted tons of extra markup that lead to heavy, slow-loading pages that now penalize your search engine results)
• Proprietary software has many hidden costs to consider – cost of switching to another solution, risk of vendor lock-in, vendors closing shop, getting acquired, etc. These risks are greater in Software as a Service than in desktop software you download and can run even if the company goes away – Saas vendors may have lax security policies, get hacked, lose data through carelessness, expose data to unknown outsiders, or even be a target for a sophisticated attacker
• When purchasing any kind of software, it should be as commodity as possible – we manage dozens of cloud servers, but can replace any of them at any number of other vendors without significant difference. For an IDE or graphic editor, if a vendor goes away, we can pick a different editor and keep working with no interruption and just an individual learning curve to pick up the new software.
• Custom, bespoke solutions should be considered experimental, proof-of-concept. If successful, should look to turn into either a competitive business advantage, or made open source as a way of “giving back” and gaining more leverage (these are not mutually exclusive options, by the way).
• Bias towards platforms we know – This is simply practicality. Generally we want to provide a solution as quickly and effectively as we can – having to learn a new platform to get the job done when our current platform is capable of solving it is simply making a smart business decision. The grass is not always greener… Using platforms built in technologies we know makes it easier for us to contribute as well.
• Bias against the market leader – When picking a technology, we look for tech with widespread adoption and a large user base, but we usually shy away from the most widely used solution. Several reasons for this: popularity doesn’t usually equate to technical excellence; solutions that enter the market later have a leg up in terms of lessons learned, failures of the earlier entries; secondary solutions tend to have a focus on technical excellence, and often provide far better value; philosophically we think every market should have multiple players, that having alternatives is far better than having a monoculture, and so we support alternatives.
• Bias toward open and inclusive communities – we want to work with people who share our values.