The project was originally created on AWS Cloudfront, Ryan and I thought we could handle the bills. In retrospect that was incredibly naive so we were fortunate to partner with Cloudflare.
At the time, cdnjs was a baby, Cloudflare had just started entering the market.
In short, Cloudflare always owned the domain, cdnjs.cloudflare.com, meaning, we were constrained to work under the DNS level.
We have both put considerable amounts of work into the project, but nothing compared to the community and the "core" contributors. I put "core" into quotes because for the last 5 years, cdnjs has largely been run by a highly dedicated man named Peter.
Peter built enormous amounts of infrastructure to support cdnjs. He is extremely diligent, intelligent and determined.
The project was Ryan's and I "baby" but we were happy to relinquish control, sorry for all the "buts", but we were not in a position to control due to the technical and commercial reasons.
Ryan and I have never personally profited off the project, we've only paid bills and late night ssh sessions.
Conversations are underway to move forward, it is likely that the project will move to an unpkg setup (assets are just mirrored to npm).
Why is the CDN Github account locked down so much that even the longest time collaborators do not have proper access? They are the ones doing the majority of the work?
We should probably rename this old repo ThomasCDN.js and fork this repo to a new CDN.js so that the ones doing the work can resume activity.
You guys are currently the weakest link and not contributing, instead just hurting the project while not communicating. Is there an internal fight about power right now? Is there some type of investment happening that you need to ensure you have control? I suspect this is turning into an enterprise business, thus the big push for consolidating control and secrecy.
If that can not work, or there is a big business push that the community doesn't need or want, the maintainers should make a new one in partnership with Cloudflare with a slight name change to avoid issues.
still waiting on an answer as to why you felt the need lock the project down so that people actually contributing to it couldn't continue to do so. Seems like very poor stewardship of FOSS projects on your part.
I am a former maintainer / librarian on cdnJS. I helped out some years ago when I wanted to learn how version control and git worked. This was in the pre-automation era (2013 to 2014 in my case), and I went through the existing libraries to find outdated instances, located new versions of the same, raised the PR to update it. All good.
Back then, and I don't know how much has changed, the libraries were maintained on GitHub and CloudFlare did the hosting. I wasn't aware of any problems with either organisation doing what they were doing, the system worked just fine. The founders (see https://cdnjs.com/about for confirmation) Thomas and Ryan were around, but not super active. Thomas was involved in building out some of the automation infrastructure, but the day-to-day of updating the repo was largely undertaken by the maintainers, and that was fine. I never 'met' either founder, but we had occasional email back and forth and they were grateful for my maintainer-ing.
I used the GitHub Mac app because I was finding my way. Whenever I changed any library, the action of the app checking a HUGE repo for any changes pegged my laptop for a few minutes every time. Not ideal, but the process of doing this librarian-ing helped me learn about a heap of stuff.
According to [1] I stopped on cdnJS mid-2014. Things got a bit twitchy for me when a library (edit: jPlayer) was pulled from the file structure because it was compromised (edit: XSS) or found malicious at release. I had a couple of user complaints directed at me because I was the one that added it in good faith originally (it passed the malware checks I ran on it). The founders stepped up to explain it wasn't me that was to blame, and one person didn't take that too well -- basically they found me on other software forums, posted threats to me and explained how the library that I had added, and someone else had removed, was crucial to their business and they'd lost such-and-such dollars in revenue with that library 404-ing without notice and that they were coming to find me and extract the money from me by force. It all died down a few weeks later.
> they found me on other software forums, posted threats to me and explained how the library that I had added, and someone else had removed, was crucial to their business and they'd lost such-and-such dollars in revenue with that library 404-ing without notice and that they were coming to find me and extract the money from me by force
Wow, that really takes "open source maintainer abuse" to a whole other level.
If cdnjs was an enterprise offering it would be reasonable to expect either a notification of removal and a generous transition period, or just cdnjs disinfecting the package behind the scenes (and then boasting about it).
But expecting the same from a free service is unreasonable. Stalking people and asking for damages because they didn't meet an unreasonable expectation is beyond unreasonable.
> it would be reasonable to expect either a notification of removal and a generous transition period
For security issues like XSS in live and deployed libraries?
I mean, I don't agree that the library should ever be removed, but if you are of the opinion that vulnerable libraries should be pulled, they should be pulled quickly no?
What's worse: uninterrupted service with a time window where you are vulnerable to a known XSS attack, or your service suddenly going offline, customers calling your support but all you can tell them is that you will be back in a few days, but at least they are not vulnerable to XSS in the meantime?
Of course for a small startup a few days notice before removal is enough, but for a large company a few days may be barely better than no heads up at all. Not everyone can move with the same agility.
If you don't pull it at all you risk people staying on the library forever because they don't want to touch a working system.
There's a lesson here for anyone who dreams of getting famous maintaining something in the open source world - if it grows huge and you're not willing to share control (and fame, and maybe money) you can't take really a break from it. You will always have to be there or risk losing it very quickly.
Software development at scale is about much more than code. It's about maintaining relationships with people, being willing to trust other people can do good work without your input, and sharing responsibility for what you started. All the really awesome open source projects have people who are good at those things at their core.
Yes. Please CDNjs, give us enterprise level support because all of us pay you the gigantic salary of...
Nothing.
Wait. Okay, no, You can't take a break because we give you huge donations that make it so the 5 maintainers can afford spend time working on it. You can easily feed 5 people or families on the annual donations of...
$52.65 [1]
Okay. In all seriousness. No one doing open source owns anyoneanything. Software at scale is a job. Jobs have salaries. Microsoft depends on it? How about Microsoft spends 10% of an engineering salary supporting it?
>Microsoft (has or any other company) supports it by having their engineers contribute to it.
If project goes down and maintainers leave the project, Microsoft also loses money spent on their engineers contributing there. They will have to fork the project, put more people on it, waste a lot of time by re-learning code and start contributing. Money and time would be better spent by just donating to current main maintainers.
If you read your comment slowly, you’ll see how it sounds like some kind of blackmail. You made no argument as to money being “better spent” donating - why can’t MS employees do the same maintenance job?
> All the really awesome open source projects have people who are good at those things at their core.
Nope, the really awesome open source projects have one or two people who dedicate large amounts of personal time and resources to the project for no reward.
Thats the foundation of open source so many are ignorant of. It's not about community, fame or fortune open source is about people sacrificing a huge part of their life for no reward or acknowledgement, only criticism when it doesn't live up to a paid service provided by a team of professionals.
>>Software development at scale is about much more than code. It's about maintaining relationships with people, being willing to trust other people can do good work without your input, and sharing responsibility for what you started.
Correct.
Worth noting that this holds true for everything at scale, not just software development.
I guess the lesson to learn here is that you shouldn't rely on externally hosted assets. Just host it yourself, its not that hard. If you're concerned about the bandwidth cost, you should probably charge more for the service your providing.
Thanks for the cache partition description. This will make projects like cdnjs less beneficial. The proposed hash:// scheme at least would leave it to the attacked site which resources to expose to such an attack.
Performance vs security trade offs seem to be popping up everywhere recently.
Immutable cache and subresource integrity get us most of the way there. I don't know if web browsers share those across domains, but I don't think there's a reason not to.
Possibly privacy. If I host a copy of a popular site's Js, I can watch download patterns and have a pretty reliable "has this user logged into site X" detector.
What you could do is the negative "they won't load this file" which could have many reasons (from connection breaking just after the HTML to JS blockers)
And I believe it's a good solution to restrict such a feature to files already marked with a hash on the origin. They would only do that for common libraries found elsewhere as well.
> There is a downside though: a copy has to be downloaded for each website, so each first website load is slowed down.
Just stop loading 100 resources on a single pageload. If a website loads just one css and maybe one js there wouldn't be any performance issues, unless of course those files are several megabytes in size.
If we just keep posting "it's broken for me with JS turned off, it should work without it" on every other Hacker News thread, surely people will be convinced eventually, and everyone will just stop using JavaScript frameworks and libraries and go back to HTML4, with full support for Lynx.
I feel like we're really close now. Come on guys, one last push.
I'm not advocating for no JS or something like that. All I'm asking for is web-devs using less resources. Use all those frameworks, but do you really need 100 requests to show a blog post?
I don't suppose the complaining here was the reason, but I have noticed several major UK sites (in retail and delivery) become more friendly to browsing without javascript recently. So-called progress is not inevitable.
I doubt this could be implemented in a way that avoids fingerprinting browsers (perhaps other than adding support for a new protocol, like ipfs directly in the browser(s)).
The mentioned magnet links[1] are closer to what I describe and more than a decade earlier. Neither is supported by default in common browsers without relying on third parties.
With the added benefit of working on the local network without access to the internet (I cite that because I encounter this requirement recently at work).
Hello from Cloudflare! We're involved with CDNJS as we host the CDN-part of the project. We will support CDNJS and the sites which rely on it, period. If your site uses CDNJS you can trust it will continue to be fast and functional.
We have engineers currently working with the CDNJS team to get updates happening again. Once that is done we will start to think about the best way to keep CDNJS updating without requiring as much human intervention in the future. Thanks for your patience and feel free to ask any questions here.
It's a free CDN that automatically pulls from NPM or Github based on repo URL without any submission/approval bottlenecks. It's also more robust with multiple CDN and DNS providers.
cdnjs doesn't work well with es6 modules or at least requires more manual labor. unpkg and jsdelivr work because they keep the structure defined in the package.json
The problem is that if you spread the privileges between many people, especially in a voluntarily project, it usually ends up with no-one doing any work. I have experienced it over and over again. Meanwhile if there is only one person in charge he/she will often end up doing a tremendous amount of work. It's like, if the the whole organization depends on you, you feel more responsibility.
Well, I've read the whole linked Issue and only then understood that it's not in fact CJDNS[1]. The latest commit there is Aug, 6, which is very frustrating. I'd love to see HN crowd paying more attention to such projects.
Software should mature and when it does, development should slow down. I don't use cjdns myself, but from what I've heard it seems to be a solid piece of software.
If you had personally submitted a PR to the project and it was sitting there unacknowledged, or you were seeing lots of PRs by others sitting unresponded to then I could see a reason for being frustrated. But there are only two open PRs at the moment, and only one of them is without any comments.
OpenSSL is a very widely used SSL library. It's used by Apache and nginx, as well as many e-mail, chat and VPN servers. Estimates include 84% of popular websites, and 96% of GitHub client keys were generated with OpenSSL [1]
Heartbleed [2] was a bug in OpenSSL disclosed in 2014, which had very severe security implications.
Subsequently, people noticed OpenSSL typically receives about $2,000 in donations a year and has just one employee who works full time on the open source code. [3]
Shortly after heartbleed it turned out openssl was funded by a couple of developers doing enhancements as contracting work and $9000/yr in donations despite being relied on by most of the internet.
Heartbleed was a direct result of lack of resources. Billions of dollars have been shifted through OpenSSL but nobody thought to contribute back to this critical infra.
Really sad to see this, I remember relying on cdnjs at a few old jobs over the years. Hope they get this sorted.
If anyone is looking for alternatives, I created Pika CDN as a modern alternative for cdnjs/jsdelivr/unpkg. It runs off of npm (so no approval bottlenecks) and is 100% modern ESM (so you can `import` every package directly in the browser without a bundler).
https://www.pika.dev/cdn
Hypothetical question - what if a "founder" of a widely adopted service like cdnjs becomes incapacitated or dead, is everyone supposed to just follow a fork or is there some kind of provision to hand over control to someone? How can the successor be chosen in such cases?
Just this happened in the Clojure community when Raynes (Anthony Grimes) died. He made a lot of utils and projects for the community available open source and since his passing in 2016, community forks have been available in other organizations or willing users who fork and continue maintenance.
Edit: just learned after looking up more about it that Raynes also seems to have been behind the creation of Elixir's Mix toolkit (Mix is Bundler, RubyGems, and Rake combined) so he touched on a lot of peoples life outside of Clojure as well.
Well, you can plan for that. N+2 and all that isn't just for servers, works for humans too :)
If you haven't planned for it? Hopefully there are maintainers/contributors who care enough and have the resources to step up, figure out a plan, and execute it. If not? Have fun maintaining your own fork and finding out about security bugs on the front page of HN.
CDN JS isn't the CDN. The gives you links and shortcuts to use other CDNs, like Cloudflare, MaxCDN, Stack-something and others. Don't think any of the libraries are served from CDNJS properties itself - how would they pay the bills?
Yeah the fuse is the actual hosting and the second is the index page. So you could fork the repo, reach out to Cloudflare and start on newcdnjs.com for the index and newcdnjs.cloudflare.com for hosting.
Whilst that's do-able, this means you'd be starting a new CDN on a new domain from scratch. Bringing the existing CDNJS traffic over to something new would be a very difficult challenge.
Forking is not as trivial as you make it sound. You need to setup CI/CD with the new fork, then persuade the community to get on board the new fork. The bigger problem is to get the infrastructure and money to host a live CDN that serves the users.
To clarify: it looks like CloudFlare is the actual CDN behind CDNJS. And getting on board the new fork would mean updates to every single reference to CDNJS URLs (in codebases), on top of the community of contributors moving. Yikes.
Seems to me like Cloudflare would be in a position where they could effectively decide on a new official fork and make sure it is one that is more sustainably maintained, then.
Seems there is a vital difference in their operating procedures though as jsDelivr is owned and operated by the for-profit company Prospect One and on their whims, compared to cdnjs which is community driven (even if the core community is really, really small).
And there's no mechanism on GitHub to point people to the new fork, from the project homepage. The best you can hope for is people notice there's no recent commit and open the issues page, to discover a possible issue about it.
Even then, it's not even clear how trustworthy any forks are. And the risk of the project fragmenting becomes high. Which is the "real" CDNJS if the original becomes stale and two credible actors both decide to fork it at the same time? In reality, there will end up being links to all three projects.
And I'm guessing that most consumers don't even go to the GitHub project, but rather through the website. And even there, they won't notice that they're not using the latest version.
> No direct financial sponsorship (or any funding) for core maintainers to work on cdnjs
Unpopular opinion ahead: I find that demanding money after “voluntarily” contributing to an open-source almost offensive to the spirit of OSS. Money changes the incentives around a community project in an irreversible way. Note that the issue here has nothing to do with financial support.
EDIT: This is regarding the “core maintainers” comment in the linked thread, and not a judgement of anyone’s ability. I gave away years of my own time to open source projects earlier in my career. It was very rewarding in many ways, even financially - what I learned made me a lot better at my job.
Am I not allowed to be ok with that, and believe that a paid contribution model is not ideal for OSS?
So if someone asks "why don't you do more voluntary work" and the answer is "besides some organizational issues there no financial support" you find that offensive?
That was not the question, and the problem at hand has nothing to do with lack of funding. That actually makes the pledge even worse.
When there are not enough interested persons to keep a project alive, let it die. As shown in other comments, the same infra can be achieved in an automated fashion without the need for lots of human intervention.
How did you get financially rewarded by participating in OSS? eg. did it help you find a job? Did you get donations. Or how did you do it?
I think the best route is 1) Get a paid job 2) Do OOS on the job. Meanwhile a lot of people do the mistake of 1) Do OSS for free 2) Ask for financial support
It seems like it stopped being volunteer work for the maintainers, but since no one else stepped up, they're stuck with the work. If I volunteer it should mean I can hand over any time and my replacement would be able to take over. Of course if that volunteer work is serving food at the food bank, many can do that. But if the food bank demands I stay and says "we need 20 hours from you this week...", is that still volunteering?
Yes, by their own conscience, if you can understand what that is. To spell it out, they'd probably feel bad about walking away from the project, even though it's taking more and more of their time.
My name is Thomas, one of the original founders of cdnjs along with Ryan (linked below by another commenter).
We originally posted cdnjs on Hacker News in 2011 -> https://news.ycombinator.com/item?id=2828516
The project was originally created on AWS Cloudfront, Ryan and I thought we could handle the bills. In retrospect that was incredibly naive so we were fortunate to partner with Cloudflare.
At the time, cdnjs was a baby, Cloudflare had just started entering the market.
In short, Cloudflare always owned the domain, cdnjs.cloudflare.com, meaning, we were constrained to work under the DNS level.
We have both put considerable amounts of work into the project, but nothing compared to the community and the "core" contributors. I put "core" into quotes because for the last 5 years, cdnjs has largely been run by a highly dedicated man named Peter.
https://github.com/PeterDaveHello
Peter built enormous amounts of infrastructure to support cdnjs. He is extremely diligent, intelligent and determined.
The project was Ryan's and I "baby" but we were happy to relinquish control, sorry for all the "buts", but we were not in a position to control due to the technical and commercial reasons.
Ryan and I have never personally profited off the project, we've only paid bills and late night ssh sessions.
Conversations are underway to move forward, it is likely that the project will move to an unpkg setup (assets are just mirrored to npm).
A lot to say, but I'm at a lack of words.
Happy to answer any and all questions.