IT certifications can't measure capability

Governments want to define professionalism through certifications -- rather than community reputation built on real work

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.

1 2 Page 1
Page 1 of 2