Open Source Components Assets

Are FOSS Components Assets?

Posted on Posted in Software Assets

“A resource with economic value that an individual, corporation or country owns or controls with the expectation that it will provide future benefit”

The way organisations adopt new software applications has changed significantly in the past 5 years. Previously organisations would licence commercial software products from mainstream vendors and use the applications as building blocks to create the required solution. Quite often this would mean licensing expensive applications but only using a small percentage of the functionality. An added complication was the need to track and manage licence compliance for all the vendors and applications.

This need to manage licence compliance spawned an industry for Software Asset Management which includes standards for Software Asset Management the first being published in 2006 ISO/IEC 19770-1 Standard for Software Asset Management.

With the introduction of new mobile platforms such as Android, organisations are now building their own applications or commissioning bespoke solutions from  third party independent software vendors. These applications are built by piecing together proprietary, third-party, Open Source Software , and contractor 3rd party components of code. The wide availability of Open Source Software (OSS) frees developers from having to reinvent the wheel, while accelerating development and reducing costs. For organisations this presents a far more efficient model for delivering solutions where you code what you need and re-use what you have coded. As opposed to the old model of licensing software where much of the functionality is not required and therefore unused.

Open Source Software has become ubiquitous in all major technology solution verticals for example

Mobile – Android

Cloud – Openstack, Cloudstack, Cloudera…

Big Data – Hadoop, MySQL, PostgreSQL…

Social – Cassandra, Drupal…..

Gartner predict “By 2016, Open Source Software will be included in mission-critical applications within 99% of Global 2000 enterprises.”

Outside of development departments there is little awareness of the obligations and risks of using Open Source Software components to build applications. These components can come from various places: Supply chain code, internally developed code, reused code, third party code, legacy code, proprietary code. Each component having its own attributes and obligations.

Similar to any third-party commercial software, organisations need to respect the licensing and copyright terms that govern how the OSS code can be used, address the security vulnerabilities that may be associated with the software, and abide by export control regulations if the used software contains implementations of encryption algorithms.

These obligations are commercial business issues and is why all software whether proprietary or open source needs to be treated as a business asset.

It is essential that every organisation create a clearly defined and well communicated Open Source Software Policy . This policy should be a framework and guideline for both internal and external software development teams to work within. Developers should be focussed on creating great software and not having to have the overhead of self governance. Eventually the policy should become part of the culture and avoid where possible risk being engineered into an application which may need to be expensively remediated in the future.

Once a policy is in place an organisation can then implement tools to discover and maintain what third party Open Source Software components and libraries have been used in the software development process and whether or not they comply with the companies Open Source Softwre Policy. There are free tools that can be used for this such as FOSSology or commercial offerings such as Black Duck Hub, Flexera Flexnet Code Insight and TripleCheck.

11 thoughts on “Are FOSS Components Assets?

  1. A very good classical topic to tackle… but having the accounting defenition of an asset is ambiguous … to the community who is developing it is an asset in the fact that they are investing their time and adding experience and getting a higher paycheck … search about kernel developers and how they find a high paycheck after 5th patch or so…. now for the company who wabts to use the software … it is also an asset like any other asset if used well and a in a good manner will generate future benefit…moreover providing and alternative to properiety software is a favor to society by creating competition thus lowering the prices of prop software A very deep deep subject indeed … but in brief the trend is opensource adoption and open source is changing the world… and it can be valuable in the hands of people with enough knowledge … Properiety software has its strong points too so it all depends on how much resources and the quality of these resources to be able to handle non properiety impementations
    Other consumer oriented examples One succesful software is vlc player which beats every other player easily and is ported to ipad… mozilla softwares(thunderbird…firefox…) of course …not going in to server stuff 🙂

  2. Indeed. Companies also don’t “have” closed source software. They have licenses the terms and conditions of which are far less permissive than most OSS, can often change with little warning, and rarely come with any guarantee of continued support for the long term or even allowance for the possibility of continued support. With most OSS the user could itself provide support by making upgrades/modifications to the source code.

  3. Does this article lack a conclusion? I would say: OSS components, “having” open-source software cannot be an asset, since it is under joint ownership and cannot be transferred with money in return. However /using/ OSS and having an open-source culture in an organization is a quite heavy asset. It means that the org. can benefit from immediate and low-cost access to a huge trove of IT solutions. Little less known, /participation/ in open-source communities is an asset, too. Companies or individuals with proven participation have better access to other projects/teams (in reward), get their voice more respected and have quicker responses when reporting issues.

  4. Not reliable, No support, Higher installation costs n saving money in our company dint happen specially technical support too costlier than commercial one,Some buggy SW is much better. facing problem of regular updates.

  5. I find your points applicable to ventures with labor/skills issues regarding the components they are adopting, not the components themselves. However, open source still hasn’t eliminated proprietary software. Sometimes, a venture is better off with the latter than the former.

  6. It’s an important conversation to have. Without getting into great detail. Who will support your custom open source code. Is it well documented? Is there reliable support, for patching, OS upgrades, Data Base upgrades. Do you trust the group who created the code with access to (Everything) Do you get the best solution? Or they best that could be done within the confines of a specific technology or program language. what is the cost to reengage to modify your custom solution? Can you modify it? With technology changing at the current pace, there has to be an ongoing relationship with an entity you can rely on and TRUST. *You get what you pay for*

  7. Good points. There are many situations where liability to a vendor is a better decision than dependency on internal labor/skills. When using proprietary software, it is wise to focus on vendor INdependence in integrating it into an application. Vendor technical documentation is marketing material, too. 😉

  8. It was left without conclusion to generate discussion. Software from proprietary vendors is not owned other than by the licensor. Organisations licence the right to use the software. Software in general is an intangible asset. Organisations treat proprietary software as an intangible asset and manage the business risks. OSS is generally overlooked from a business perspective. OSS components can carry significant risk the XimpleWare/Versata lawsuit is an example of this. Not to mention security risk management. As you point out the benefits are huge but organisations should not ignore managing OSS in a structured way.)

  9. Open software is somewhat like everyday hardware. Everyone has access to the ‘nuts and bolts’, but it’s what you make of it and how you make it that determines the end application’s value. “With the introduction of new mobile platforms such as Android…” Android mobile didn’t introduce this. It’s really a more pervasive adoption of a practice preceding Android mobile development. 🙂 A corporation should be aware of the general open source agreements and perhaps wary of anything but that with regard to open source adoption. My $0.02 is a corporation should do more than policies; it should manifest those policies in general-purpose architectures/frameworks. However, a drawback to that is making sure there isn’t an ivory towers group dictating to development via that framework. It’s very rare a given framework cannot undergo revisions, extensions, and review to policies while requirements and functionality is determined at the same time. Then, bring the two together in development of the value-added functionality using that framework.

  10. It’s good to see someone raising the issue of OSS in relation to SAM. There seems to be a common misconception that a. all OSS is free… and b. OSS means no licence ts & cs to comply with… and some organisations are starting to suffer the consequences.

Leave a Reply

Your email address will not be published.