A number of interesting press releases by industry experts published this year show some of the most impressive data ever on the exponential growth of open source software adoption. Open source buzz is humming both behind the scenes and on the front page in just about every major industry that touches a piece of modern technology!  

The growing acceptance of open source software in the workplace prompts a strong push for open source training for recent college graduates. I cannot speak for all recent college graduates, and I cannot speak for every university, but I can speak from my experiences and the experiences of others I have talked with on this subject.

Before I jump into my topic, here is some background for those new to open source licenses.

In my last two posts, I discussed the evolution of open source knowledge: where we came from, where are we now, and how did we get here. I provided some examples of common misunderstandings and knowledge gaps and suggested that such gaps may be due to the need to take action without taking as much time to prepare and plan as is optimal.  The sum total is that misconceptions and misunderstandings about open source persist both within and outside the software industry.

What is an open source software (OSS) bill of materials (BOM)? In the simplest terms, it is a list of the OSS components used in an application. But, it can actually be much more. Most OSS BOMs will, at a minimum, also contain the licensing information associated with each OSS component.

I am asked two very reasonable questions, on a very regular basis, by some very interesting people.

Open source audits are never as simple as they seem. You have successfully tackled your first open source audit and you are probably asking yourself what to do to help with future audits. The answer is: preparation.  The steps you take before you start the auditing process will make the project that much more successful. To help with future audits, let's look at a few tips and tricks you can use before you begin an audit:

Scanning and auditing your code for open source software (OSS) is a great first step towards compliance. However, some organizations may be reluctant to perform scans because of concerns about how disruptive the process can be to their development effort. In this article, I will explore a couple different approaches to scanning your code for OSS and the potential disruption associated with each.  I have organized the article from the least to most disruptive approach.

For those of you who have been to Japan, you know how beautiful the country is, how welcoming the culture is, and how dedicated the workforce is.  For those of you who have not yet had the opportunity to visit, I highly recommend putting this trip on your “bucket list." 

The use of open source in website development has become mainstream - I dare say ubiquitous.  Many developers utilize open source projects to build and scale dynamic websites. WordPress, Joomla, and Drupal are some of the more popular (you’ve probably heard of all three).  LAMP stacks are used to run web servers.  MySQL databases are used for website databases.  Firefox is used to test and trouble shoot coding and rendering issues, as well as to browse; you may, in fact, be reading this post in it right now… I could go on and on.  In the world of website application development you’d be hard pressed to find a site that doesn’t leverage open source code to some extent. Irrespective of size, organizations are running their websites using open source technology.