New iPhone SE, 3 Apple Watch models coming? Moderna booster shot and omicron Popeye's meme kid now state football champ Squid Game: Most trending TV show in 2021 Best Christmas gifts 2021 PS5 restock tracker

Uncovering the secret sauce

perspective Palamida's Mark Tolliver asks whether it's time software companies should openly disclose their "ingredients."

perspective In 1990, the FDA and the Nutrition Labeling and Education Act brought us those "Nutrition Facts" food labels we alternately love and loathe.

Those discreet charts, tucked away on the back of most food packaging, tell us how many calories, grams of saturated fat and milligrams of sodium we are ingesting when we munch on our Doritos or Twinkies.

According to Nutrition Today magazine, "The objectives of the NLEA were to reduce consumer confusion about food labels, to aid them in making healthy food choices and to encourage product innovation by giving manufacturers an incentive to improve the quality of the food and make more healthy food choices available."

While it may seem somewhat far-fetched, there is an analogy in today's software industry. Open-source software undoubtedly is playing a larger and more important role in the process of software development. By participating in open-source communities and incorporating the resulting software into their development efforts, companies are effectively including "ingredients" that are not their own.

"Who cares?" Enterprise users of software tend to care a lot.

Said more formally, they are using the intellectual property of others. As they do so, they are bound by the author's terms regarding the use of his or her intellectual property.

So, just as we are increasingly interested in the contents of prepared foods, shouldn't we be similarly interested in the obligations that a software company might be passing on to us as a result of their choice of "ingredients?"

What would it look like?
Now let's think about what would happen if the software industry adopted comparable guidelines for software component labeling.

First, what would the labeling look like? Pretty straightforward. As part of the product labeling, software vendors would list the third-party component, including the version used, a simple description of what the component does, and the license that governs its use. The list should ideally cover all third-party code--commercial and open-source--and include a link to Web sites with more information regarding each component.

The next obvious question is: Who cares? Enterprise users of software tend to care a lot. Suppose a company is considering the purchase of a system to assist with managing the online identities of customers. With the heightened sensitivity in this area, it seems obvious that vendors would want to know as much as possible about software being used for that purpose.

The company might look first at the license terms and decide whether they are in compliance with existing corporate licensing policy for use of third-party intellectual property. The point is to avoid any issues with respect to intended use.

Next, the IT team might check the Web to see if the software components listed have any record of vulnerability, so that they can discuss those issues with the vendor prior to installation.

Finally, if the software content lists elements of open-source software, it is worth asking the vendor how support requests and vulnerabilities are handled. Does the vendor respond directly to support requests or turn to the open-source community for support?

The motivation for a software vendor to take this approach may seem less obvious. Some enterprises are now requiring information about open-source content as part of the purchasing criteria. Even without this, transparency could be turned into a competitive advantage, signaling a company that respects intellectual property, and whose governance policies should inspire confidence.

For the industry as a whole, a bill of goods associated with every software application would provide a new and healthy level of transparency in corporate transactions. Mergers and acquisition activity in the tech sector remained heated in 2005, up a reported 62 percent over 2004 to $339 billion in transactions. A formal and standard process of accounting for software assets would serve to protect buyers and speed the acquisition process for sellers.

Only time will tell whether this idea catches on. Collectively, we can (and should) work together to create openness in dialogue and code that will enable organizations to learn and share best practices as we go forward. It's the right thing to do, and, like food labels, a software ingredients roster may also improve product quality and encourage innovation--a mutually beneficial side-effect.

Who knows? "You are what you eat" may turn out to be as valuable a piece of advice for software consumers as it is for grocery shoppers.