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.