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.

Share this article with your friends!

Comments (0)

Add new comment

CAPTCHA
This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.