Why Should I Build on Open-Source Tools?

posted in: Uncategorized | 0

In recent years many open-source software products have become available on the Internet. An open-source product can be defined as a software product that is has both binary and source code available for download without cost, and the software has a permissive license for reuse in another software product. Many notable examples include Mozilla Firefox, Wikipedia, GIMP (bitmap graphics editor), Inkscape (vector graphics editor), and WordPress.

The underlying foundation for building these software products are open-source platforms and programming languages – which we’ll collectively refer to as tools. The notable open-source platform is the Linux operating system, which competes against Windows, Mac OS X, and UNIX. Open-source programming languages include Python, Ruby, PHP, and Perl. Programming languages allow software developers (people) to write instructions to perform on a computer. Open-source software products are built on these open-source tools.

There are several reasons for developing on an open-source tools, the platform and programming language, compared to closed-source (paid) software. Let me enumerate the reasons:

1. If a person relies on a particular open-source tool, the developer has the liberty to fix bugs and add features by editing source code. In contrast, closed-source tools require approval from the gatekeepers, usually corporations, to permit changes, a bureaucratic process. As an aside, most developers won’t change popular open-source tools because core developer teams will emerge to maintain open-source projects. For example, Mozilla Foundation maintains the Firefox web browser.

2. Closed-source tools are a long-term risk to software products. When a software product is built upon a closed-source tool, it is assumed that a corporation/organization to maintain and release future updates. Given that corporations and organizations have sole control of the tool’s direction, a corporation can stop building or revoke a tool. The result is software that is built on a legacy tool. For example, I built several software products on closed-source tools such as Visual Basic 6 and Windows Forms .NET, which are no longer are supported by Microsoft.

3. Open-source tools are receptive to enhancements. Given that developers can modify and submit changes to open-source tools, they become better than any one individual or organization; that is, the whole is greater than the sum of its parts.

4. Open-source tools can be audited. Given that software has intentional or unintentional security holes, developers are able to inspect and audit an open-source project. For example, in 2008 a bug in OpenSSH caused RSA keys to be cracked easily; a security audit of this open-source tool revealed when and who introduced the bug.

Open-source tools, however, are not the holy grail of software development. There are equally compelling cases where closed-source tools are needed and preferred, for example, when handling sensitive data or when a corporation wants to keep its secret sauce.

In summary, there is a strong argument for building software products on open-source tools. The challenge is how to remunerate software developers to build open-source tools. We can get inspiration from organizations such as the Mozilla Foundation,  Canonical (maker of Ubuntu Linux), and others to remunerate open-source software developers and benefit the software engineering community.