Moving On
My entire career seems to have come from being a CodeIgniter developer, and a vocal one at that. Since then I have risen up through the ranks of CodeIgniter developers to be active in maintaining it, but with my new job I just don't need to be on the team anymore. PHP 5.2 is finally dead to me, and as such I do not need to be part of a framework which focuses of PHP 5.2 compatibility! It's not just CodeIgniter though, I am dropping as many of my responsibilities as I can to make way for an exciting [secret] new job.
Vaguely Relevant History
When I first started using CodeIgniter in 2007ish I wrote a whole bunch of libraries: Assets, Curl, REST, CLI, GitHub API, Unzip, Cache, Template, OAuth, OAuth 2, and probably a few more which have come and gone in that time.
I was building projects and when I realised that a feature was not in CodeIgniter and nobody else had released a library - or the library was old or buggy - I'd build my own. When it was built I'd blog about it, so other people could avoid having to write the same stuff out and could potentially help me improve my own.
Over time I realised that CodeIgniter was missing things in the core that were not something I could make into a library, and so I started blogging about how you could accomplish these various tasks. Base Controllers for Admin and Public areas, multi-site, multi-environment, REST API's, etc all ended up as a blog which people would use to answer almost any StackOverflow or IRC question you could ask.
With all this blogging I ended up with quite a reputation as somebody who knows whats what in the CodeIgniter community, but it frustrated me that some features just weren't in the core. Other people were frustrated too, and the community wanted more control. I wrote an article two years ago that got a f**kload of attention, asking "What Happens Next?" and suggested that CodeIgniter would not go much further without community input.
FuelPHP To The Rescue?
I ended up getting involved with FuelPHP - in the hope that if CodeIgniter were to "die" I would have another "favourite framework" which I could use for my PHP projects (which most of my clients request specifically). At the time working on FuelPHP was awesome fun as it meant I could play with PHP 5.3 features like namespaces, more command line utilities (like Oil) and other things that just didn't fit in with the CodeIgniter philosophy - as a slow moving, backwards compatibility focused framework. It also meant that all of these hacks and tweaks I was blogging about could be rolled into the core. FuelPHP could handle multiple environments, base controllers, autoloading, etc all out of the box meaning each time I started a project I didn't need to hack it in!
Eventually EllisLab let the community have what it had been asking for. They assigned a team of "Reactor Engineers" from the community (myself included) to help develop features and peer-review pull requests. This was awesome and 2.1 had a whole bunch of great new features come in - including many of those various tweaks and tricks myself and many others had been blogging about, and 3.0-dev (as yet unreleased) has had about x40 the number of commits that any version of CodeIgniter has had in any previous version - all still without breaking the API.
CodeIgniter AND FuelPHP?
This meant for a while I used both CodeIgniter and FuelPHP, which confused a lot of people. Simply put I would mainly use CodeIgniter when I was stuck using PHP 5.2 and FuelPHP when I was able to use PHP 5.3. Things like PyroCMS (a distributed application) and crummy old client servers (dear God why won't they let me upgrade them) meant that using PHP 5.2 (and therefore CodeIgniter) was a must for me, and so being in a position to fix bugs and add features was a massive opportunity for me - and meant I wouldn't need to maintain my own "fork" of CodeIgniter.
With this reputation in the CodeIgniter community, and with this position on the team, I started getting a lot of CodeIgniter jobs off the back of it. It was pretty cool being flown out to places like Chicago to work on projects for people using CodeIgniter, but I also ended up getting typecast. The number of CodeIgniter + Bootstrap dashboards I have made is only topped by the number of f**king CodeIgniter RESTful API's I've built. It's a lot.
As of a few weeks ago I have a new job and my whole situation has changed. I am in a position where suddenly I only have one main focus: building and maintaining the backend for an iPhone app, to handle as much load as possible. No more PHP 5.2 for me then, and not as much PHP in general. PHP 5.4 for the API (specifically requested) and JavaScript frontends with EmberJS to help reduce the amount of work the servers are forced to do. If the PHP starts to get slow, we can play with HipHop or even swap out the next version of the API for NodeJS.
Sacking Off Work
So with that big-ass changearound it seemed like a decent time to quit the CodeIgniter team. After-all I won't be using it, so why spend my own time working on it more than I have in the past? Just peer-reviewing incoming requests takes up about an hour a day and I just can't spare that time anymore. After-all, investing that time used to directly reflect in the freelance offers I would get, but I don't need to anymore. It might be selfish, but that's how it works.
While I am at it I decided to quit the FuelPHP team too; I'm cutting right back.
Now I can go back to just being a user, and not have to spend hours going through emails from GitHub about bugs and feature requests.
In yet another move to shirk responsibilities I have open-sourced my two ExpressionEngine add-ons which I used to sell:
I know people have been paying for that code, but the best I can do here is to open it up. I've been in touch with several customers who are over-the-moon to see it open-sourced, so I don't feel bad about this at all. If anybody wants to take them over they're welcome, otherwise send in pull requests and I'll get them merged as and when I have the time.
What next?
The only team I won't be dumping is PyroCMS - which is just getting started. There are some massive plans coming, and we'll be switching to PHP 5.3 soon meaning great new things.
I've also been bashing together a basic admin panel for the new job using Laravel 4 (still pre-BETA) and this new framework fits in exactly with how I imagined FuelPHP 2 ending up. The difference is that Laravel has a company behind it, and Taylor has been ridiculously active. This whole last week or two he has been on Skype with me fixing bugs as I find them, and they already have a lot more done than the FuelPHP team could in the same amount of time. Laravel 3 was ok, but Laravel 4 is going to be epic.
Basically, anything using Composer packages is a huge winner for me, even Symfony is starting to look much more attractive now that I've taken the time to learn about the benefits of dependency injection, instead of just discounting it based on it looking "too complicated".
Anyway: "The Times They Are a-Changin'", so if you're a PHP Framework user: keep your eyes out for change and be receptive to it.
If you're releasing code make it PSR-2 and distribute it using Composer, write unit tests and shove it on Travis-CI. Try to make it work on as many frameworks as you can. Be smart. It takes a little extra work to implement initially, but you can double or quadruple your user-base, which can reduce ongoing work for you while increasing adoption.
If you're looking for code packages make sure they do all of that. Packagist is a good place to start looking. You want tested, well documented, re-usable code, not just some random library somebody dumped together for your specific framework that might not be maintained as soon as they switch frameworks.
Update: A lot of people are reading a lot into the mention of Laravel. I am not interested at all in Laravel 3 (the current version). I am interested in PSR-2 and Composer, which Laravel 4 (the version still in development) is entirely. I want a basic framework, with no frills whatsoever. No ORM bundled in the core, and some really simple routing and config management. That is it.
Laravel 4 keeps Blade, Eloquent, even the Validation code in their own packages which you can chose to include if you wish. I could just as easily use Silex, Slim or any micro-framework for that, then bundle a few packages. For API work I probably will be using Silex or Slim with a few PSR components bundled in, but for this dashboard application I am using a lot of Laravel components so decided to use the whole lot.
The next generation of frameworks are not what you're used to. Don't use one framework for everything, use whatever is right for the job, and use components to stop this whole "I build everything with X" mentality. It's childish and damaging to you and your projects.
Comments ()