The Open Source Cookbook: A Baker’s Guide to Modern Application Development

It is often said that open source software is like a recipe. In this context, let’s discuss your grandmother’s favorite cookies. It’s quite possible your grandmother is known throughout the family as having the most famous chocolate chip cookies. Maybe she’s better known for her Pecan Sandies, or her Rich Tea Biscuits. Whichever is her claim to fame, we would all be lucky for her willingness to share the recipe. She may, however, request simply that if you make her cookies yourself, you tell the people you’re serving that it’s your grandmother’s recipe. Of course, you can always modify her recipe as you see fit. That is the essence of open source software; ingenuity, collaboration, and attribution. When cooking or baking, you are likely to use a combination of your own know-how, recipes you’ve borrowed from others, and some ready-made bits you purchase from elsewhere. That is the essence of modern application development; the code you write, the code you borrow, and the software you purchase or license.

Not All Open Source Recipes Are Equal

Let’s begin our cookbook by selecting our recipe. I’ve had some phenomenal baked goods, and I’ve had some not-so-phenomenal baked goods (there is rarely a bad baked good). But I’ve been surprised before, by a croissant from a diner that didn’t taste like the one from the local French bakery, or by a buttercream frosting at a supermarket that just didn’t have the same delicate touch as the one I make at home. In each case, I expected the same as I had before – by title – yet encountered a much different experience. When selecting your recipes, it’s important to understand which type of a particular food you are expecting to make, or you may be met with a different taste when you finish than you were hoping for when you began. Open source components have the same challenge; while two components may share a name, they may differ greatly depending on the vendor that provides them. For example, while one vendor’s take on an open source component (what the tech community refers to as a distribution, or distro) may be, fundamentally, the same as another’s, they may have made some minor changes to suit their needs (i.e. compare Red Hat Enterprise Linux and Ubuntu, as they pertain to Linux). These changes can have implications on function or compatibility, and should be deeply considered when selecting open source components for your applications. In other words: be wary of pastries which share a name, but come from different shops, and understand the origin of your open source components.

Open Source Recipes Evolve Over Time

No recipe is perfect from the start. Often, it is only after many tastings and failed batches do we evolve the recipe to a version we are very proud of. I often make banana bread, and have done so for about ten years. Over this time period, I’ve made some batches with fresh bananas, and some with overly ripe ones. I’ve tried adding chocolate chips, blueberries, and nuts. I’ve made conscious decisions to add more butter, and accidental additions of too much salt or sugar. Each batch was still “banana bread,” yet each batch was distinctly different in flavor and texture. Open source recipes often evolve in a similar nature. Changes to open source components can manifest themselves as new versions, and often are the result of development efforts in parallel to the current main project (referred to as branches or forks). Branches often include development activity for new features, bug fixes, and testing, and can be incorporated back into the main project. These branches and forks can be the result of collaborative evolution, or simply one contributor’s ambitious activity. Regardless, with each new version of a component, we are slightly more removed from the origin of the component (the trunk, or master branch). When different vendors evolve a component across various distros, the deviation among the projects from the original “copied” version increases. This is referred to as “technical debt” and can have implications on a component’s maintenance and support. Simply put: As time goes by, different bakeries’ interpretations of the same recipe will likely become more distinct from one another, and components from different distros will often become more distinct over time.

Selecting Your Open Source Recipe

As with cooking, when incorporating open source components into applications, it’s important to understand origin and evolution of what you’re baking into your software. Carefully review your open source component versions, and evaluate the community’s activity in order to have the greatest chance possible to predict the possible technical debt you may inherit. Two distinct components may share a name, yet originate from two different distributions (distros, colloquially). And each distro experiences forks in which both major and minor changes occur. This can create a significant deviation, over time, among two different types of what had otherwise been considered the same component. It can introduce additional maintenance and development costs for you in the future, or expose you to unexpected security and compatibility issues if you don’t fully understand the nuances of each. Discover how CxSCA helps organizations secure and manage open source within their mission-critical software.