Four Reasons I Like Developing with Open Source Code

  

 Email Article  

Tweet  

  

I have been a developer for a number of years (yes, it’s a large-ish number) and I’ve worked on teams that have developed software on commercial platforms, on teams that have used a mixture of open source and commercial components, and on teams that have used primarily open source. Overall, I’ve developed (no pun intended) a preference for using open source tools and components whenever it’s feasible.  Here are some of the reasons why I prefer to develop with open source code:

1. Availability

“Because it’s there” may not sound like a compelling reason; however, when working on a thorny problem, finding that someone already has a viable solution, or a good foundation for my own solution can prove invaluable.

An area where the open side of open source software really comes into play is the availability of OSS solutions for just about any general need. Does the project need to build in compression to reduce bandwidth usage? Zlib is an excellent, well-tested possibility.  Need SSL to meet your security team’s requirements? The OpenSSL project has got your back. Does your web app do complex analysis that you’d like to show off in interactive graphs? Take a look at the Data-Driven Documents JavaScript suite.

Thanks to the passionate community of open source developers, there are a tremendous number of libraries, tools, scripts etc. covering an extraordinary range of functionality, user experience enhancements and so forth. That’s one of the things that most appeals to me as a developer: seeing what some of the brilliant minds in the computer world are releasing into the grid for everyone to play with.

I think this is one of the reasons that the LAMP stack became such a successful and widely adopted way to build web applications in the late 90s and early 00s. Most of the commercial solutions were unreliable, overly complex, or prohibitively expensive. The open source LAMP stack combined the solid base of the Linux operating system, the reliable and scalable Apache web server, the fast MySQL database management system and the adequate PHP language in a freely available, tightly integrated stack.

Having this stack readily available allowed many a team, or individual to build complex web apps on a shoestring budget and with a relative minimum of configuration fuss and muss.  This led to the LAMP stack becoming one of the most widely adopted platforms of the early web era and to its continued widespread use today.

2. Portability

Given the general fragmentation of user platforms into a variety of operating systems and architectures, one of the daunting tasks facing developers is the ability to produce software that can run on, for example, an ARM chip based device running Android and an Intel-based Linux server.

Once again, open source systems offer a great approach to this problem. Not to be tautological, but since the source code for open source projects is openly available for a developer to tinker with and because many of the projects use widely available tools and build systems, porting a project based on open source from one platform to another became much more feasible.

Additionally, many open source projects—like the UI-oriented Qt platform—work to provide a cross-platform foundation, designed specifically for building solutions targeting multiple systems.

3. Lower Cost

In an enterprise context, the direct and indirect costs of any outside system, commercial, or open source are critically important. Once again, open source projects can be a compelling solution when appropriately vetted. Typically, the upfront cost to introduce open source into a project is low, with no vendor charges and the same cost of integration as any commercial component (i.e. time and effort).  As long as a team is aware of the licensing restrictions of the open source projects, the indirect costs can also be minimized.

This makes it important to use something like OLEX Scanning and License Analysis to ensure that the team doesn’t inadvertently introduce a component with burdensome or expensive obligations, or, alternately, that they are aware of the costs of complying with the obligations imposed by the license of an essential component.

4. Support

Finally, one of the best features of a good open source project is a thriving support ecosystem. Not only do project participants share insights and help fix bugs, the projects users often do as well. This makes it so much easier to find new approaches to a problem, or other ways to test my own code.

In situations where one of my teams has been required to have a support contract in order to use a new component in a project, we’ve used commercial companies that provide support for open source projects.  OpenLogic (my current employer) is one such company that provides service and support and I think we do a pretty good job, although I may be a bit biased. Managers may prefer the sense of security that goes with a support contract, so these companies offer a good solution to address these concerns.