In April, one of the open source code movement’s first and biggest success stories, the Network Time Protocol, will reach a decision point. At 30 years old, will NTP continue as the pre-eminent time synchronization system for Macs, Windows, and Linux computers and most servers on networks?
Or will this protocol go into a decline marked by drastically slowed development, fewer bug fixes, and greater security risks for the computers that use it? The question hinges to a surprising degree on the personal finances of a 59-year-old technologist in Talent, Ore., named Harlan Stenn.
Amazing how such an important protocol hinges on just one man.
http://www.informationweek.com/it-life/ntps-fate-hinges-on-father-t…
Thanks!
From the article:
That’s not how atomic clocks work. Cesium-133 is stable. It isn’t radioactive, and it doesn’t decompose.
Rather, atomic clocks work by funneling super-cooled cesium atoms down a tube and exposing them to precisely-tuned radio waves. If the frequency is just right, the atoms resonate and change their energy state. The number of atoms with this modified energy state is counted by a detector, which tunes the radio generator to the frequency that produces the peak level of cesium atoms.
This frequency is 9,192,631,770 Hz, and seconds are ticked off from the frequency that produces the most cesium atoms with the elevated energy level.
To get precise frequency on output we need… precise frequency on input. This looks like paradox. How can this be explained? Generally how can more precision be obtained starting with less precision?
Rather than trying to count how many of these oscillations happen in a second, the second is instead defined by the amount of time it takes for 9,192,631,770 oscillations to occur.
At least, for most uses of the second. There area couple of other ways to define the second, depending what you’re using it for. The Wikipedia entry is actually fairly interesting.
Not really a paradox. This frequency can be generated, and it is. It is still delivered by a classic crystal oscillator. The whole trick is that the mechanism behind detecting the right frequency relies on Cs133’s properties which never, ever, change. The Caesium part is the ultimate verification of how good the frequency output is and is it’s control input. That’s all.
Seems many important open source projects face similar troubles, particularly those that don’t have large corporate backers. Take for instance the developer of libgcrypt & gnupg.
https://gnupg.org/blog/20141214-gnupg-and-g10.html
(I actually submitted this to osnews months back but it was never published)
A new entry was posted just this past week, with a brighter outlook:
https://gnupg.org/blog/20150310-gnupg-in-february.html
Here’s the propublica article:
http://www.propublica.org/article/the-worlds-email-encryption-softw…
While it’s nice that gnupg landed some strong backers, I think it warrants a broader discussion whether these small open source projects should be dependent upon corporate sponsorship. Is there a better model? If so, what would it look like?
User-facing projects such as firefox have started to monetize users through advertising, etc, to break away from a hard dependency on google. What should developers do to monetize invisible/under-the-hood kinds of projects?
One can wonder if said corporations are biding their time, waiting for the projects to run out of funding and/or developers, and then swoop in with their own custom replacements under a more “business friendly” license…
Talk to the Linux Foundation.
Those big bad companies are putting money in the Linux Foundation, so the Linux Foundation can fund these projects.
http://www.linuxfoundation.org/programs/core-infrastructure-initiat…
Lennie,
A bit sarcastic, but speaking of the Linux Foundation, can you find a list of the projects they support and a breakdown of the funds? I had difficulty finding this on their website. Is it limited to the 15 on this page?
http://collabprojects.linuxfoundation.org/
Maybe I should have done: ‘big bad’ companies.
I couldn’t find the list either.
The collabprojects are projects that make use of the same infrastructure the Linux foundation provides for the Linux kernel project.
So probably some web- and git-repository hosting and maintenance of those systems, but also things like legal assistance.
The Linux foundation also organizes the LinuxCon(ference)/CloudOpen for the Linux kernel developers and directly related projects. At least some of these collabprojects make use of that event and get to organize their own developer conference there. Like for example the Xen project is part of CloudOpen.
I believe the Linux Foundation also owns Linux.com and they have that as an outlet to promote and inform people about their own projects and these collabprojects.
But they probably don’t fund developers on those collabprojects.
Edited 2015-03-14 17:53 UTC
The problem with the current system for developers and donors is that, as a donor, I must dispatch money by paypal or something similar to each project I would like to incentive (and pay the fees associated to each operation). It is time consuming and not very practical.
I also, generally, don’t like to contribute to a foundation and never know where the money will be applied.
If possible, a situation that would be good for both, developers and donors would be something like this:
– A central institution is responsible to collect and dispatch money to a list of registered projects by rules to be explained below;
– The coordinators of each registered project must make clear what are the development goals and financial targets for specified periods of time;
– There must exist a public accounting list for every project. Only sponsors of a particular project or its members should be allowed to post comments to this list (to cut noise and spamming). There should be links to the projects and their development/discussion lists (for example to github or sourceforge projects page);
– There should be a satisfaction rank associated to each project. Only sponsors should be able to attribute grades to projects;
– Sponsors should be able to allocate money by sum or by percentage of its contribution to a list of projects he/she picks and also specify how it will be released (scheduled on listed dates or at once);
– The sponsor list should classify projects by priority. Projects with low priority will get money from a sponsor only if there is a surplus associated to high priority ones (see next item);
– Sponsors should be able to choose what will happen when the financial target for each sponsored project is hit (give the money anyway, transfer to projects with lower priority associated or get it back);
– At any time, sponsors should be able to suspend or terminate its donations. If his options included scheduled releases, the amount on hold must be returned to him;
– The total amount of money donated and on hold, and its projected release dates, must be readily available to be consulted by anyone;
– The amount allocated by each sponsor should not be disclosed to project members unless the sponsor requests it;
– There should exist an option on sponsors lists to automatically suspend transfers to projects that fall below a specified rank threshold;
– Project members must be able to terminate/suspend acceptance and/or return part or the whole amount of money donated on nondiscriminatory terms;
– The projects may use any kind of license and may be under a company, individual or foundation control.
Perhaps, sourceforge or github could implement something like this, if it does not exist yet.
Edited 2015-03-13 03:01 UTC
acobar,
You know my honest reaction when I read your list is that, though it is well intentioned, it may be a recipe for small project developers to drown in bureaucracy.
I appreciate that some people prefer to donate money only when they can demand specific improvements in return. But I think this sense of entitlement is only really justified if someone is donating $1k+ amounts, enough to pay the developer to focus fully on your individual request.
One thing I encounter as a developer is clients who want me to implement “micro-features” for them, but what can happen is that so much time is wasted on “back and forth” emails, calls, drafts to determine work & scope that it easily consumes way more time than implementing said features. Some clients get upset if you try to bill for your overhead of dealing with them – to put it bluntly.
If we go the route of pooling money, then maybe another approach would just be an open source promotion organization collecting annual membership fees, selling swag, etc, all proceeds of which get donated to projects that members get to vote on. This way individual developers don’t have to divert as much of their attention to fundraising & managing micropayments, on which they pay exorbitant processing fees. All of this effort could be consolidated.
Another benefit may be that the organization could bring attention to projects that otherwise have a difficult time getting recognized. Lets face it, a lot of our software comes in through repos where software dependencies are installed completely automatically. This is great for easy installs, but we’re more distant from the authors than ever before – not even a visit to their webpage.
Well another option is bug bounties… One person may only be willing to donate a small amount for a given feature, but if the feature is genuinely useful others may be willing to donate too… If the donation list gets big enough to interest a developer, he can implement the feature in question and collect the bounty once enough of the donators are satisfied.
Obviously such a system isn’t foolproof, people will post vague requirements for instance, but it still could work reasonably well.
This is a really good idea but you should be already an sponsor to post such things on the accountability list or something like that. There is a need to reduce noise and spamming on Internet.
Just exchange of ideas are already covered on development lists, I think.
I don’t know if I agree with your definition of “noise and spam”. I agree we do have a lot of it, but I don’t ever consider honest discussion as such. The real noise and spam are the “me too” people, bots with fake accounts, and spam email servers, and no amount of being a sponsor on a system like this would cut down on true spam. The me too’s would still say “me too” or “bump”, and the others have nothing to do with the system in question and you may wish to post some discussion before you decide to contribute to a project to gauge how the developers treat their sponsors.
That is why the project has a development list in its hosted repository, like sourceforge, github, gitorious, bitbucked and the like.
What I was suggesting was a place to centralize funding, not a host service.
The benefit would be a large reduce of posts from people not really that interested in the project. I think it would increase focus.
OK, so my friend and I team up.
I submit a patch, fixing one issue, but with a payload a future issue.
My friend fixes the issue I introduced, collecting bounty, shares with me.
Such schemes are, sadly, open to abuse.
Even though would be nice to establish bounty bonus to outside developers, it is still up to the maintainers to accept them or not.
Not accepting fixes without giving clues why would lower the grade of the project what could, potentially, impair the influx of money, as would also the insertion of intended bugs to try to collect money by fixing them, what is clearly a form of scam.
Edited 2015-03-13 12:55 UTC
The intention of the goals and accountability list is not set on iron and fire something that must be achieved but give general hints on where the project is heading and inform people interested what was achieved. It is not a contract but a kind of letter of intentions.
Your goals may be very well “improve performance” or “clean up the code”. To me, as a sponsor, I can better judge if your goals are worth my money this way and I can decide it is. I can decide to keep donating even if very few was accomplished but on this case would be nice to have an explanation of why it happened.
A rank or grade is also interesting because this way we can avoid donating money to projects that just divert or stop to work without too much fuss.
The accountability list has the potential to give hints of things people really interested on your project may wish to see implemented, but it is not a check list and not the development list, this last has already a place in the development repository. It is easier to entice developers to fix things, stay on course to finish steps or implement enhancements this way. It would make them more interested on finally tackle the hard last 5% that consumes two times the time already expended on software development.
I don’t know if you participate in development communities but I do and I can tell you that it is frustrating when you ask for small things or waste a lot of time testing and reporting bugs and nothing happens. It just does not work well on current situation.
Edited 2015-03-13 09:25 UTC
I think something like this already exist for some FOSS projects and it is not working “wonders”.
A kind of participation is the preferred way on my opinion, even if some sponsor may opt to not post anything.
See how NGOs end using donated money on ways many sponsors don’t agree with. It also foster the interest on participation on “management” level what, frequently, do not align well with the interests of well maintained projects/sponsors or end up being abused.
acobar,
I feel like I should know what you are referring to, but I do not. Do you have an example in mind?
I have no issue with participation/interaction, I’d just be wary of funding that comes with strings attached. The goal would be to help deserving FOSS projects receive the funding they need, micromanaging their activities should be a non-goal IMHO, as this would scare off FOSS developers from endorsing the organization.
In this particular case I don’t think it’d be that big a problem, if you disagree with the direction of a project, you could simply vote not to donate your share to them and then you could let them know why.
I don’t like to point fingers. There are quite some big projects that are under staffed, receive donations and end up diverting their time on things many users don’t agree with. I will add that I am very grateful that they exist and I personally benefit from their hard work but we see ridicule situations happening. There was one that affected me. The maintainer decide to change a particular behavior, some guys complained and asked to have an option to get the old one. The maintainer never came with a trustful justification and even used the “it will make the maintenance harder” card, I submitted a two lines patch (after expending a lot o time to locate what should be modified). It was something really trivial, the patch never got merged. Three years later and many version incarnations the two line patch still works, that part of the code was not touched on newer versions.
Really, you always have to option to not ask for money. If you are for a long haul, though, reality is: you will need money. Also, as I explained, it is not a contract, it is a kind of letter of intentions. There is no do or die but some information about what is going on is the minimum you would expect if you are putting money on almost anything. Again, you, as a developer, is not obligated to answer, but it for sure would impair your evaluation by sponsors and, as a possible consequence, the flux of money directed to the project.
I also think you are exaggerating the problem related to micromanaging, you don’t need to inform every step, but it happens to be in your best interest to give some information about things. Again, it is not an obligation.
Developers have the right to not post a thing about what is going on and sponsors have the right to stop donating, in the end, a compromise would be achieved between them.
acobar,
Your illustration desperately needs an example though.
Of course FOSS devs need the money, but I don’t think a fundraising organization should get too involved in their internal affairs. I’m all for opening the lines of communications as you suggest though.
Of course, projects that are non-responsive and/or unhelpful would loose the appeal of donors, which is incentive to be responsive and helpful.
Naturally.
Well, you are not getting it directly from me. There are places to complain about things when they don’t walk straight and these are what I use. On general lines I do talk but naming the cat when it is not present or is not a place it walks in is like not give the right to defense, something I despise very much.
I see it differently.
To my eyes it is up to the project members to decide what they want to do, on that we agree.
The need for a top level management of funds, seems to me, is one of things we disagree. I don’t like people to decide by me, and I see many cases where the politics involved or are just a waste of time or resources or are biased toward directions that have nothing intrinsically pertinent to the projects, some cases are even worst. I prefer direct participation, like Switzerland’s System of Direct Democracy on Cantons, and taking in account the we are already a group inside a society, the chance that direct talks will be positive is, probably, better.
It is also intrinsic (at least to me), that it is not because you are donating more that you have more power than other sponsors, you have one vote, even tough, of course, donating more money is more enticing and lower the chance your suggesting find a deaf ear, if you ever opt to disclose how much you gave, what should be accessible by all project members and sponsors, I think.
Edited 2015-03-14 17:59 UTC
The fate of the protocol isn’t really at stake at all, just the most used implementation of said protocol. It’s a bit sad that a writer for informationweek can’t tell the difference between protocol and implementation. All these security issues and bug fixes are NOT with the NTP protocol but with the ntpd implementation.
It’s not the only NTP implementation although it is probably the most feature complete. The thing is, most people don’t need all those features, and the security issues that comes with the highly complex code, which is why we have simpler implementations like OpenNTPD.
The article does highlight the rather sad state where big business is more than happy to make use of OSS projects and code but less happy to provide financial support for the products they’re using. Heck, it would be a piss in the ocean for the likes of Google, Apple, Amazon and Rackspace to pitch in.
It’s still an overly alarmist article though. The NTP protocol won’t go away even if ntpd would. In fact, the protocol hasn’t seen any big changes in a long time IIRC. The public NTP servers won’t go away if ntpd does. The ntpd code won’t go away, it will still be there and people can continue using it.
SystemD to the Rescue!
https://wiki.archlinux.org/index.php/systemd-timesyncd
I hope that is sarcasm.
Well I’d break it down as such:
75% sarcasm/troll in the post
95% Truth
The systemd implementation does less, but few people really need more than it provides. So if you’re part of the less than 5% that uses the advanced features of ntpd, its of no help. But, for those that just want their system to stay in sync… its great!
A small side affect of systemd utilities replacing older couterparts is that they are simpler and are well funded and developed.
Seeing systemd is entirely blocked on my gentoo system – and will remain so – I’ll never get to use it
Basically, systemd is never a solution seeing everything it does is done the wrong way.
True. Its very sad that some users are not yet assimilated. Our representatives are currently busy right now helping others enjoy systemd, but if you’d leave your name, address, and architecture of your machines, we’ll take care of it as soon as possible. Thank you for your cooperation, Resistance is futile.
Make it so :p
Right On! 🙂 I totally concur
/kick systemd
[my]
*/two-cents/*
goto my:
Edited 2015-03-14 02:31 UTC
Yes and no. For many servers it’s a suitable substitute (as is clockspeed, chrony, openntpd etc) but we still need ntpd for the stratum 1 servers.
timesyncd also can’t function as a server so if you need an NTP server for your LAN you will need ntpd or one of the other alternatives.
To be honest, I find the requirements for continued ntpd development outlined in the article rather excessive.
Ntpd is 20 years old software for a protocol that hardly ever changes. It should be in low-impact maintenance mode by now where the only things needed are bug fixes and perhaps support for new clock hardware. It shouldn’t need more resources and money than what many full-blown OS projects has.
One might also question why the ntpd code repo isn’t hosted with a service like github or bitbucket, where it might gather attention and support from more developers. In fact, with a quick glance at the ntp site I can’t even find where the current repo is or how to access it. That’s a bit of a problem for an open source project.
edit: so after looking a little more I found it but…it’s using BitKeeper? The hell?
And I still think it could benefit from github or bitbucket.
Edited 2015-03-14 02:59 UTC
You may have over looked it in the article, but the guy is already spending 100 hrs/wk on just handling things as they are currently. You may think it’s trivial to move to another service, but it really isn’t for infrastructure projects. The choice of code repository is really kinda secondary to the project. If it works, and there’s no reason to believe it doesn’t, why change it to be geek fad friendly on github.
The author’s credentials are pretty laughable and the article seems to support that he’s not qualified to write articles like this one. He has no real technical background in programming nor the sciences and it shows. It’s all in journalism and management.
The one real takeaway from the article is Mr. Stenn needs qualified help. Not just money, but manpower. He’s slowly drowning. This is why it irritates me when developers decide a project is “broken” and it automatically needs to be forked to fix it. It leaves people like this behind with even less support and help he desperately needs.
But the project needs to be fixed. There’s something really wrong with it if he spends 100hr/wk on a not very large project that should only be needing bug fixes. Maybe someone should also look at if there’s a better way to run the project or structure the code.
For example, why are the parts that talks to the clock hardware and the internet facing parts in the same daemon? Since they are functionally totally different wouldn’t it be better to split these into two daemons?
Heck, maybe we actually need to let go of ntpd and start over. It wouldn’t be the first time a project has been left in the dust and replaced by something else over time.
Edited 2015-03-15 02:21 UTC
Also, you have to agree that using the commercial BitKeeper is an exceptionally bad choice for an open source project, considering BitKeepers incredibly/stupidly restrictive license.
http://article.gmane.org/gmane.comp.version-control.mercurial.devel…
It seems that would also apply to contributors to ntpd.
The article itself is a bit sensational here and there, and gets some technical bits wrong and no doubt the readers will keep on slobbering about all those details and missing the point. The point is that this project needs support. Having met Harlan multiple times I can say he looks tired and troubled – and desperate for support. I can’t understand why the big players like Red Hat and google and others don’t assist with this. The project is a little bit archaic I think, but if people see it, then surely someone should be able to help streamline it. I’m in a similar situation with PTPd I’m developing – although I don’t actively seek financial support at this stage.