Doghouse – FOSS Training

At the Linaro Conference in Bangkok, one of the keynotes was dedicated to "License Compliance." The speakers were two people I have known for a long time: Shane Coughlan, from the Free Software Foundation, Europe, and Harald Welte, who has been associated with Free Software since his teenage years and who (as Harald himself pointed out) "is no longer a teenager  … ."

The topic of license compliance has been discussed many times. After Harald explained why he personally started spending his own time and money pursuing companies who did not follow the GPL licensing, he was asked what could be done to make this less of an issue, but he had no real answer.

I stood up and volunteered an answer: "It will stop when the business people of tomorrow are taught the issues of Free and Open Source Software [FOSS] in the universities of today."

I recently started working with universities to train computer engineering students in the use and creation of FOSS. Some universities are incorporating this training into their mandatory engineering curriculum. However, some universities are treating the topics as electives (allowing their students to opt out of the training) or not offering the training at all, which often means that organizations like Linaro have to develop their own training to take good "closed source" computer engineering students and turn them into good Free and Open Source engineers.

Modern-day software engineers should know something as basic as using a distributed source code control system, or making sure that the licenses of the code being integrated into a product are compatible with the other code being using, or even understanding the business model of the final product.

However, ignorance of these issues does not end with engineers and often is magnified by managers who were trained at university 30 years ago, before the concepts of Free and Open Source Software were widely known.

Such topics also include managing a product through its life cycle when some or most of the code comes from a community of people not necessarily tuned to the needs of a corporation but instead have metrics that determine only when code is worthy of being released. Most likely FOSS business models were not taught to these managers when they were students  – only the business models of proprietary software.

The reality, however, is even worse because upper-level managers, such as CTOs or board members, do not even know what questions to ask when hiring the managers who in turn will be hiring (or trying to hire) FOSS software engineers. Because it is unlikely that these upper-level managers will be going back to university to learn these skills, it is probably worthwhile to develop training specifically aimed at providing the information to this level of management.

Of course, many books, magazine articles, and web pages discuss the subject of how to be a good "FOSS manager." (I have written many of these articles myself.) However, the material tends to be scattered, and much of the problem is that these managers are not even aware of what they do not know.

This situation mirrors the state of affairs in 1999 when we formed the Linux Professional Institute (LPI). We then had upper-level managers who needed Linux professionals but did not even know the questions to ask that would help them determine the competency of the people applying for jobs. LPI studied the issues, created the objectives of each level of professionalism, and then created the tests that certified that knowledge. Perhaps that type of certification could help in the hiring of FOSS managers today.

This brings me to the question: What knowledge should a manager of FOSS people and products have? I have mentioned software licenses, but what about issues of "upstreaming code"? Surely a manager of FOSS should know what that means and understand not only the legal issues but also the value of upstreaming code to the product itself. Should the manager be familiar with examples of FOSS business plans? Should the FOSS manager know that the schedules around FOSS projects might be more flexible than they are used to having with paid, dedicated engineers? Do they know that collaboration with their competitors is expected, and not just a nice saying?

I would like LPI to develop a certification for Managers of Free and Open Source Software and to have the FOSS community help determine what should be tested in that certification. I think it might make everyone's life easier in the long run, and from the number of engineers taking pictures of Harald's slides, I think many of the engineers might agree.