Open Source for MBAs: A Primer

If you’re neither a scientist, nor active in the open-source community, it can be difficult to properly understand why people write open-source software. Why would people just give away the products of so much hard work?

I fully understand why one would be wary of a free product with no apparent profit model. After all, it’s only proper caution to check for Trojans when receiving a horse.

The trick with open-source software is to think about it in different terms. Traditionally, if you needed a piece of software or documentation or some other product that can be copied or photocopied, you had two options:

1. You could find something that met your needs and then pay per-seat or per-site for a version someone else had written.
2. You could hire someone to create your own version from scratch.

Paying for an existing solution can get expensive if you need a lot of copies, but writing your own version from scratch usually costs even more.

Using someone else’s solution makes you dependant on them for fixing bugs and writing new features, but writing and maintaining your own draws resources away from competing in whatever markets you occupy.

Open-source provides a third option with a slightly different payment structure. Instead of money, open-source vendors want you to pay for their software in externalities and, if they’re lucky, maybe you’ll chip in with a bug fix or a new feature to sweeten the pot for everyone.

One popular way is to set up a business to sell support contracts to businesses using the software in mission-critical places… often at prices lower than companies like Oracle and Microsoft who know they have you by the unmentionables.

Here are a few other examples of externalities that commonly motivate people to give away their code:

1. If you write a piece of software to solve your own problems, up to 90% of the time and money you spend on it over its lifetime can be spent on maintenance. If it’s not the “secret sauce” that makes your business competitive, then it’s just an expense and sharing the code with the world is a non-taxable payment for good publicity and an air of progressiveness in the eyes of potential employees. It may also reduce the amount of money spent if someone else fixes a bug and submits the fix back to you.
2. On a more individual level, we all like to be acknowledged. Contributing to an established open-source project or founding one that becomes popular is one of the quickest and easiest ways to build a favourable reputation among your peers, expand your resumé, and gain portfolio pieces that aren’t crippled by restrictive copyright terms.
3. Why involve the overhead of charging for your software, collecting sales tax, and then paying the money to advertising agencies to set up “viral marketing” campaigns, when giving it away for free cuts out the middle-men and takes you straight to “If people use your software and like it, then they will tell their friends and co-workers.” (Genuine word-of-mouth advertising is also more sincere and, therefore, more lasting)
4. If you run a successful open-source project, nothing makes a better business card for your support services than letting potential customers use and customize your software for low-risk applications for free. Even big companies like Microsoft often use a variation on this technique when they allow a certain amount of illegal copying in order to get individuals hooked on and familiar with their products. Open-source just introduces honesty and a better ethical and moral framework to the technique.
5. If you give away your software for free, like many companies do with the “non-Pro” versions of their tools, people are dependant on you for any changes they need. Fixing bugs, adding features, etc. That’s a heavy burden to carry and, if you fall behind, it’s bad for your reputation. If you release the source code, you are granting skilled users and companies the ability to fix problems they encounter, and to then offer the fix to everyone without putting more pressure on you.

Just because open-source developers and vendors aren’t getting paid for their software in money doesn’t mean they aren’t getting paid. To an open-source developer, their software is their business card, a pride-worthy piece of art they want to share with the world, a tool they crafted to fix their own problems, a foot in the door for related products and services, and the seed for a group of like-minded people to collaborate with.

Also, while it doesn’t necessarily affect the bottom line, programmers often have a deep understanding of how easy it is to copy software, which makes one’s job more satisfying if they know they’re being paid for their time (which is a scarce commodity) rather than copies of their software (which are vanishingly cheap to make).

As a final acknowledgement, if you are considering sharing software that you’ve written yourself, there are a few hidden gotchas to getting a community to form and they all boil down to whether or not potential participants feel empowered. Here are the basic rules:

• Use an un-modified version of a popular license that people know and understand, like the Apache license or the GNU GPL or LGPL licenses. Legalese is scary and programmers aren’t lawyers.
• Write clear instructions on how to compile a working program from your code. Make sure they actually work on a freshly installed machine. (I use VirtualBox for this)
• Provide an easy-to-use system for filing bug reports and feature requests, and offering up contributions. There are many tools for this as well as sites which will host your project for free. (I suggest GitHub or BitBucket)
• Strive to make participants feel that their concerns are being listened to.

In short, there needs to be a smooth learning curve that can take people from “just wandered in” all the way up to “respected participant”.

Open Source for MBAs: A Primer by Stephan Sokolow is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.