For me it’s a little more concrete, and a little less abstract when it comes to why a viable alternative to EZproxy is necessary. It has very little to do with the cost of EZproxy itself, and much more to do with support, features, and functionality.
There exists a trivial DoS attack against EZproxy that I reported to OCLC about 2 years ago, and has not been addressed yet. Native IPv6 support by EZproxy has slipped by years now. I have patrons using IPv6 for access today that I want to provide a better experience than forcing them to use a 6to4 gateway at their ISP. You cannot proxy https to http with EZproxy to secure the patron to proxy side of the proxy communication, increasing your patron’s privacy. I have requested that OCLC make a minor change to their existing AD authentication support to enable generic LDAP/Kerberos authentication that was denied because “no one wants it”. Since they support AD, 95% of the code required already exists, and would make a lot more sense than some of the other authentication schemes that EZproxy already supports. This closes the door on integration with eDirectory, IPA, SUN Directory Server, OpenLDAP, etc. for no good reason. OCLC has been the steward of EZproxy for over 5 years now, and in that time, they are yet to fully document the software. Every few months some new obscure configuration option gets discussed on the EZproxy list that I’ve never seen before, and I have been working with this software for over a decade now. This is not only limited to existing configuration options, either — there was no documentation on the new MimeFilter option when it was first introduced. I would have expected that the IT staff at OCLC that is managing the EZproxy service would have demanded full documentation by now, and that documentation would have been released to customers as well. EZproxy does not cluster well. The peering support is functional, but not seamless when there is a failure. When a proxy in the server pool goes down, the patron is prompted for authentication again when they land on a new proxy server, since EZproxy does not share session state. External load balancers cannot fix this problem, either, for the same reason. EZproxy does not support gzip compression, causing library access use an additional 80-90% bandwidth for textual content (HTML, CSS, JS, etc). EZproxy does not support caching, causing library access to use an additional 30-50% additional bandwidth for cacheable web assets. (And yes, you can park a cache in front of EZproxy to offset this, which is how I collected the 30-50% numbers, but doing so breaks the “it’s easy and just works” model that EZproxy promises.) Combine the lack of gzip support with the lack of caching support, and you are looking at around a 60-80% overall increase in bandwidth consumption. When you have a user community measured in hundreds of users, things like gzip compression and caching may not matter as much, but when your user community is measured in the hundreds of thousands of patrons, these things really do matter, and mean the difference between doubling your bandwidth costs this year, or deferring that expense 5-7 years down the road. So it’s not _just_ $500 per year when you take a step back and look at the bigger picture. It’s $500 per year, plus the per Mb cost of your internet connection — both inbound and outbound — which can be measured in hundreds of dollars per month for larger sites. If you could could cut that by 2/3 just by switching to a different proxy solution, that might get your attention, even if you shifted the $500/yr support costs to a different entity. Imagine never hearing “wow this library network is slow” again because a web page that used to load 1MB of content was able to gzip that down to 600KB, and 300KB of that content was served off the local proxy server, leaving just 300KB to pull off the remote server. How much is a better user experience worth to you? Bottom line: competition is good. Just look at how Internet Explorer is almost a sane browser now, thanks largely to competition from Firefox and Chrome. If coming up with a viable alternative to EZproxy using open source tools causes a security, features, and functionality arms race, then everyone wins. -- Andrew Anderson, Director of Development, Library and Information Resources Network, Inc. http://www.lirn.net/ | http://www.twitter.com/LIRNnotes | http://www.facebook.com/LIRNnotes On Jan 31, 2014, at 18:43, Kyle Banerjee <kyle.baner...@gmail.com> wrote: > On Fri, Jan 31, 2014 at 3:10 PM, Salazar, Christina < > christina.sala...@csuci.edu> wrote: > >> I think though that razor thin budgets aside, the EZProxy using community >> is vulnerable to what amounts to a monopoly. Don't get any ideas, OCLC >> peeps (just kiddin') but now we're so captive to EZProxy, what are our >> options if OCLC wants to gradually (or not so gradually) jack up the price? >> >> Does being this captive to a single product justify community developer >> time? >> > > In all fairness, most of us could be said to be captive to a number of open > source tools. > > OCLC is a library cooperative so member libraries have mechanisms to push > things one way or the other (keeping in mind that it's a big ship to turn). > But every now and then, member libraries speak up when they see something > that they think doesn't serve their interests and OCLC changes as a result > -- remember the record use policy flap a couple years back? I seriously > doubt they'd do anything too nutty with EZProxy because too many libraries > care about it. > > kyle
