NTPsec: The Wrong Fork for the Wrong Reasons
Off the Beat: Bruce Byfield's Blog
Forks -- the splitting of one project from another -- are a natural part of free software. They are implicit in the Free Software Foundation's Four Freedoms, and I would no more attempt to deny the right of a fork to exist than I would attempt to insist that everyone use one Linux distribution or desktop environment.
However, a few weeks ago, while preparing an article about the animosity between the Network Time Protocol and its hostile fork NTPsec, I came to the conclusion that there are forks that deserve support, and others that do not. The more I investigated, the harder a neutral presentation of NTPsec became. Increasingly, it seemed a fork made for most of the wrong reasons and in all the wrong ways, that, in the face of the NTP's need for support as part of the core infrastructure, amounted to nothing less than irresponsibility.
This comment has nothing to do with the code quality of either project, which I admit I am unfit to evaluate. However, while NTP is not perfect, NTPsec triggers too many warning signs for me to trust the motivations behind it.
Alarm After Alarm
Consider, for example, the fact that NTPsec's founders, Eric Raymond and Susan Sons, were originally approached to help find financial support for NTP. Newcomers should not be expected to be subservient, but neither, if they have any sense, should they be excused a lack of diplomacy, or a willingness to listen to the old guard, especially on a subject as arcane as NTP.
Yet within a matter of months, Raymond and Sons apparently moved from helping to planning to take over the NTP project altogether. Some of their ideas, like switching from the proprietary Bitkeeper code repository to the free-licensed Git, seem sensible, but others do not -- including ousting Harlan Stenn, the current project manager, and, after reforming the project, mothballing it as mere maintenance. The best I can call such an approach is rash, considering that even a casual investigation into NTP suggests that it requires ongoing development.
The second alarm triggered by NTPsec comes when Sons describes her own sense of mission, In an interview with O'Reilly, Sons expresses her growing conviction that "the Internet is going to fall down if I don't fix this." Yes, NTP requires support, but it is struggling rather than collapsing. And, more to the point, I have learned to be suspicious of such grandiose mission statements when I hear them. Linus Torvalds, by contrast, did not announce his operating system by proclaiming how he was going to single-handedly change the world, but by inviting others to participate in an interesting new project. He was too involved in the work to frame himself as a hero.
In addition, Sons claims that some of the developers working on key projects like NTP are "are older than my father" -- presumably, in their fifties or sixties -- and so out of date that they should retire. Aging developers will shortly become a growing concern throughout free software, and Sons is right that younger recruits should be encouraged. Yet she sounds as though she supposes no one else is aware of the issue, and makes ageist comments that would be comical if not so offensive and s0 dismissal of accumulated expertise.
The third alarm is how easily Stenn repudiates her description of the NTP project. Sons claims, for example, that NTP's coding standards are outdated, and patches are dangerously slow in coming. In response, Stenn replies that NTP builds for a wide variety of systems, and that any problems would have been reported. "If hardware is still in use," Stenn says, "from our point of view there is an actual benefit to doing what we can to make sure folks can build the latest code on older machines."
As for the slowness in releasing patches, Stenn states that NTP released five major patches in 2016, the last of which brought the code up to date as of November 2016. Another patch is currently being readied for release.
However, the biggest alarm lies in Sons's more grandiose statements. She claims, for example, that NTP depends on a server whose root password has been lost -- a statement so incredible it does not require Stenn's flat denial to discount. Similarly, Son's list of NTPsec accomplishments loses credibility when you realize that of course NTPsec must be smaller: NTP is a complete reference implementation, and must include many lines of code that NTPsec can choose to ignore.
Why This Matters
I am not going to speculate about Raymond's or Sons's motivations. However, the brashness, grandiose sense of mission, the easily repudiated claims, and outright exaggerations combine to create the conviction that these are not the hands I want to see in control of any key infrastructure. The kindest interpretation I can place on such actions and statements is that those making them do not know what they do not know.
Meanwhile NTPsec has convinced many in the media that it is singlehandedly saving the protocol. The danger is that free software is being convinced that a serious problem is being addressed when the truth may be that little useful to the community is being done. Instead, where once a single project struggled for funding, we now have two.
comments powered by Disqus