Andrew Updegrove is a co-founder and partner of the Boston law firm of Gesmer Updegrove LLP and an internationally recognized expert on standard setting and open source organizations and how to form them. He has represented over 70 standard setting, promotional, and advocacy consortia and open source projects. In 2005, he received the President’s Award for Journalism for his work at ConsortiumInfo.org and in the Consortium Standards Bulletin. Andrew is also a fellow of OpenForum Academy. This post was originally published on ConsortiumInfo.org, a comprehensive resource on the Internet on the topics of consortia and standard setting.
—
Well, that’s a blog title I never expected to use here.
Back in 2003, over 800 blog posts ago, I decided to launch something I called the Standards Blog. Not surprisingly, it focused mostly on the development, implementation and importance of open standards. But I also wrote about other areas of open collaboration, such as open data, open research, and of course, open source software. Over time, there were more and more stories about open source worth writing, as well as pieces on the sometimes tricky intersection of open standards and open source.
I also launched a daily-updated news aggregation service around the same time. That news feed also focused on stories relating to open standards. You can find 8,352 news items in that archive now, sorted by topic and technology area. I still update that feed every week day. For most of the last twelve years, the problem wasn’t finding important and interesting open standards stories, but deciding which four or five I should select every day for posting. Here, too, the number of open source stories relating to the achievement of the same business goals began to increase.
Two years ago something new and different began to happen: the number of open standards stories pulled in by the Google Alerts I use to source them began to plummet. Even more tellingly, the number of open source stories mentioning open standards began to markedly increase. And also this: the number of launch announcements of new standards consortia dropped in rough proportion to the increasing number of stories reporting on the launch of new, significantly funded open source foundations.
Do you sense a pattern here?
Of course you do. And here’s what it means: The top IT companies are increasingly opting to use open source software to solve problems that they used to address with open standards. And where standards must still play a role, the same companies are deciding to develop the open source software first and the related standards later, rather than the traditional practice of doing it the other way around. The reasons are many and obvious: time to market is faster, interoperability is often more easily obtainable, development economies are dramatic, and the number of standards ultimately needed is far less.
The shift in the focus from open standard to open source should therefore not surprise, nor should the fact that the cash and personnel resources dedicated to these new collaborative organizations is dramatically greater than those historically dedicated to new standards consortia.
Interestingly, when standards have been needed to support new platforms also being enabled by open source software, such as the Cloud, Internet of Things, networking and virtualization, IT companies have almost always opted to develop them in pre-existing consortia and traditional standards development bodies, instead of new consortia launched for that purpose.
This is a major change from practices prevailing over the last twenty years, when the advent of any new technology was accompanied by a veritable algal bloom of new, often competing standards consortia. Each of these new organizations was created as much to give credibility to, and promote, the new technology as the inevitable next big thing. Now this sort of full-court press is being carried out through new, dedicated open source foundations and projects instead. That’s where the strategic battles are being won or lost, so any related standards development needs can be satisfied in any competent organization.
This change, too, has been dramatic. In the past, any diagram of standards developers supporting a new technology or platform was dominated by new consortia launched for the purpose of developing those standards. But a diagram of IoT or Cloud standards today almost exclusively includes only old, familiar names.
Further transformations are occurring behind the scenes. Directors of standards development within major IT companies are not being replaced when they retire. At the same time, budgets funding participation in open source projects are exploding. And where young engineers automatically incorporate open source code into their work, they may be only dimly aware at best of the role of standards in achieving their objectives, or how those standards are developed.
The change in the press is even more dramatic. Without anyone ever reporting on the change, or perhaps even noticing it, the word “standards” has been repurposed to describe code bases rather than specifications. And perhaps advisedly so, because these code bases solve the problems that standards used to address. Whenever the phrase “open source and open standards is used,” much more often than not it’s in a story focusing on open source software rather than open standards. Usually, the inclusion of the words open standards is more of a rote afterthought than a conscious reference to any specific standards. Perhaps this is because the change in methodologies has been so natural and inevitable. But these changes are profound.
It may be that we are living in one of those times when the significance of change is recognized only by the historians who identify and analyze it in retrospect. When they do, I hope they conclude that this transformation was managed wisely, and that the competencies and best practices that have been carefully developed over the last 130 years of standards setting are not forgotten. After all, while the need for open IT standards may be diminishing, it will not disappear. And there is much to be learned from that long, hard road that open source developers would do well to study and repurpose to their own cause, something they have rarely done to date.
—
Source: http://www.openforumeurope.org