A few weeks ago, I was talking to my good friend Eric Mann about an open-source package he maintains. This particular package has quite a number of downloads and active users, despite Eric trying to abandon it a few years ago. He’s since restarted development on it, but now he faces a problem: people are upset that he’s dropped legacy PHP version support.
This particular package is popular within the WordPress ecosystem, which is big on backwards compatibility. Despite the fact that both PHP 5.6 and 7.0 stopped receiving even security updates at the end of 2018, there are still plenty of users out there running their applications in old, insecure versions of PHP. As a result, some people were rather upset when Eric stated “I’m not going to spend my [limited] time supporting EOL’d versions of PHP.”
Some commenters were quick to jump in with remarks ranging from “well, it doesn’t take that much time to support older versions of PHP…” to “WordPress supports older versions of PHP, so should you!”, but Eric remained firm: if you want support for older versions of PHP, you can either pay me for my time or contribute the code yourself.
It may sound a little harsh, but I’m 100% with Eric on this one: he doesn’t owe anybody his time and effort. That’s time he could be spending with his family, out hiking, or working on projects that he enjoys. Heck, knowing what Eric can do, back-porting support for old versions of PHP should be way down on his list of priorities.
From a private conversation Eric and I had:
Steve Grunwell
I’m kinda serious about the “Legacy Edition” thing. PHP 7.0? $50. 5.6? $500. 5.5? $5000. Just add a zero for every version back they want. Using versions Eric’s okay with supporting? Great, you get it for free!The price would be per site, and if they need help getting on modern PHP, well, they can hire you as a consultant. “I can save you $5000/site with one simple trick!” (upgrading PHP)
Eric Mann
Any objections to my stealing this?Steve Grunwell
No, please do. Otherwise I was afraid I’d do it for you and route all (or most ?) of the money to you
It started as a joke, a way to tell people “put your money where your mouth is.” What it became is so much cooler.
Homestead Fifty Six
Monday morning, I saw the following tweet from my friend Joe Ferguson:
Still need PHP 5.6 in local dev?
Announcing Homestead Fifty Six: A subscription supported #Vagrant box based on @HomesteadDev but supporting older PHP versions: https://t.co/Z3dta7S5wZ#phpc #homestead #2ndBestVagrantBoxOnEarth
— Joe Ferguson Dot Me (@JoePFerguson) March 11, 2019
“Damn, he stole my idea!”, I thought. I showed the tweet to Eric when he came online (timezones and all that), and he let me know that the idea had come up in a conversation with Joe a few days prior.
Joe is in a similar position to Eric: he’s the maintainer of a very popular, open-source project but also knows that in order to continue delivering great new features, the older versions of PHP will eventually be dropped. Users can still opt to install PHP 5.6 themselves on Homestead, but Joe’s time shouldn’t be wasted tracking down issues on versions of PHP that are, for all intents and purposes, dead.
Seeing the idea in practice just furthers the case for it: if a company is running their app on a server running PHP 5.6, they’re making the decision — conscious or not — that keeping their application(s) running on an unsupported version of PHP is more valuable to them than the time it would take to move the application onto PHP 7.1 or newer. Where Homestead Fifty Six comes in is that gap between “it’s not worth our time/money to upgrade PHP versions yet” and “how long are we willing to let our development environments go unmaintained?”
https://twitter.com/grmpyprogrammer/status/1105127106567127040
If someone needs legacy support in a library for software that’s no longer recommended for use, your options have historically been:
- Stick to earlier versions of the library, but miss out on all the cool, new features
- Upgrade your stack so you can continue using the latest version of the library
Joe has added a third option: make it easy to pay for legacy support in the library. If/when you upgrade your stack, you can switch back to using the free version that everyone else is using, but this model means you’re not left in the dark. The developers who are stuck on PHP 5.6 (for now) get active support, while Joe gets paid for his time. Win-win?
What do you think?
I’m clearly a proponent for this model, but I’m sure there are those who don’t feel the same. Is this model good for software, or are there some not-so-obvious downsides to consider? Please leave comments below!
Leave a Reply