IT certifications can’t measure capability

Professional qualifications sound like a great thing, especially to hiring managers. But could the push to expand them into state and national regulation chill open source use and developer innovation? A recent panel at a UNESCO summit concluded it might.

The panel, in which I was a participant, was organized by the IP3 project, a group seeking to promote “professionalism,” defined by the lead speaker in a way I’d summarize as “that which can be certified and regulated.” The motivations for such guarantees of “professionalism” were project success and system security. Speakers noted that there were already 10 states in the United States, as well as all of Canada, that regulate the use of the term “software engineer.” The IP3 project wants to encourage the uptake.

[ Also on InfoWorld: IT certifications no longer sure path to premium pay | Is a computer science degree worth the paper it’s printed on? | Track the latest trends in open source with InfoWorld’s Technology: Open Source newsletter. ]

Those motivations deserve close inspection. Plenty of public IT projects fail, but my experience suggests that a lack of credentials on the part of the techologists involved — or even poor software engineering — is generally not the primary cause.

How sausage is really made In most cases, projects fail because managers pick proprietary technologies from suppliers based on a range of criteria that have little bearing on the suitability of the software from the perspective of a software engineer. They are influenced by corporate marketing, by existing contractual relationships, by technology lock-in, and — sometimes — by relationships with senior executives. Middleware often gets picked on the golf course.

Likewise, system security has many dimensions. While bad guys attack, it’s amazing how often the vector was a proprietary system. Reports often speak generically of “malware getting on computers,” such as the one in this week’s Houston Chronicle about the security of oil rigs, but the unspoken element is that untargeted malware most commonly affects Windows-based systems, especially ones running older versions of the OS.

In both cases, the skills of the software engineers don’t guarantee the success of the project or the avoidance of security incidents; rather, it’s the integrity of the processes that led to software selection. That’s guaranteed less by professional certification and more by transparency, open source software, and system audits. When skilled engineers select technologies purely on merit and go on to defend their choices under audit, they’re likely to prefer open solutions, which they are free to analyze independent of vendor oversight.

Regulating people rather than auditing implementations is even worse for open source communities. Open source software is created by multiple unrelated developers with different motivations outside the scope of the open source community — personal interest and business usage being the most common. Their ability to create is enabled by the four freedoms: to use, study, modify, and share software for any purpose without restriction. The liberty to engage with and around the software is fundamental to open source, and open source licenses (validated by OSI) deliver that liberty to communities.

Open source and certification Open source is a community activity that builds governance from trust and consensus. Projects wishing to adopt a set of best practices (such as those expressed by the Apache Software Foundation or the Eclipse Foundation) take their project to that community rather than expecting external certification. Those seeking the services of a professional recognized by a given community may well prefer a certification from that community, such as that offered commercially by Red Hat, collegially by LPI, or by a community such as The Document Foundation.

These certifications each presuppose a level of professional education appropriate to the tasks their scope embraces. All the same, they are granular, applying the best measures appropriate to the technology and skills under consideration, rather than trying to devise a general abstraction for “IT professionalism.”

The certification being devised for LibreOffice professionals is particularly interesting and unusual. It involves a community providing outsiders — especially HR and procurement professionals — with accreditation of the good standing of its members, who can then be distinguished from general support companies that simply include LibreOffice in a long list of products they hope they’ll never actually have to troubleshoot.

At a state or national level, skills recognition for those engaged in critical infrastructure may be necessary. But regulatory requirements can easily become a competitive weapon, and when targeted at professionals rather than at systems, they can chill innovation. As a result, regulatory control of software engineering is rightly a contentious issue.

The right way to handle certs and regs On the panel, I was asked for concrete recommendations for how professional certification and regulation should be handled in the light of the growth of open source software. I made three recommendations.

First, college-level education in the collaborative skills required to excel in open source is required. Currently, formal IT education is often lacking, as hiring managers across the country can confirm. Students are frequently taught and assessed in isolation from each other and from engagement with real-world software. They are not taught collaboration skills or encouraged to perform software engineering in the context of community. We need to develop education techniques and resources that lead to such skills as a key part of computer science education.

Second, granular certification of the reputation and the good standing of community members should be performed by communities rather than disengaged entities. This was the tradition in earlier times with professional associations like IEEE and ACM, but in today’s open source world, the appropriate communities are now the hosts for development. The experiment at The Document Foundation is worth tracking in this regard.

Finally, national/regional/international certification creates a serious risk of chilling innovation. It should be strictly bounded and limited only to critical purposes. Ideally it should be achieved by the certification of systems. This should be performed by expert auditors — they, rather than software developers, may be an appropriate target for regulatory certification.

Some fear the arrogance of youth and praise the wisdom of years. But youthful freshness can also be a source of innovation and wisdom, and the voice of experience can be an arrogant call for conservatism. I fear that regulatory interference could perpetuate old thinking, provide a vector for vendor lock-in, and limit the innovation of upcoming generations of engineers in the name of a misguided, old-school notion of professionalism.

This article, “IT certifications can’t measure capability,” was originally published at InfoWorld.com. Read more of the Open Sources blog and follow the latest developments in open source at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.