Moving On

My guess is this will largely go un-noticed but I felt a formal blog post was in order for announcing my decision to stop contributing to AptitudeCMS and Geeklog.

I owe quite a bit to Geeklog…after installing Linux and PHP for the first time over 12 years ago I ran across Geeklog, learned a thing or two about open source development and started Iowa Outdoors (which I’ve since sold). Not long after that I was fortunate enough to serve as the project lead for Geeklog before handing it off to the current lead, Dirk Haun. Back then, there weren’t many viable options in the now overcrowded PHP CMS market. Sadly, I’ve watched Geeklog’s popularity slowly decline to its current state. That said, I have a few constructive things to say to the Geeklog community and the PHP community at large.

First to the Geeklog community. You’ve run into rough times. WordPress, Joomla, Drupal and company really are the champions in this space. Without doing more digging than I care to, I know Geeklog is far behind in any of the hard metrics that really matter (code commits, # of active developers, etc). Just a hint of proof is had by comparing Geeklog’s Ohloh stats with this, this and this. Then there those things you can’t quite quantify, the passion of the community and the level of innovation happening. Right now I feel the Geeklog community is pretty stagnant. Some of this is likely to be blamed on the fork of Geeklog (whose Ohloh stats don’t speak well either). Fact is if you combine both glFusion and Geeklog’s numbers together it still paints a pretty bad picture. You could argue they don’t need to aspire to be like WordPress, Joomla and Drupal which is fine but what I think has gotten lost in all of this nobody has consciously said if that’s the game they want to play and, if not, what differentiates Geeklog from the rest? In the meantime, the set of features added over the past year or two suggest, in fact, they are playing catch-up to some of the features found in those other systems. That’s not bad, but my point is Geeklog seems to lack a tangible goal. I guess that is part of the nature of open source…the perpetual, organic, itching of scratches but I still feel open source projects need to have long term visions far beyond the next commit, next point release and even next major release. With that said here’s some suggestions for Geeklog’s community in no particular order:

• Change your name – I attempted to address this with AptitudeCMS and failed but something has to be done. I’m not sure if there is a precedent for a name change in a well established open source project but it has to happen for Geeklog. To me it is branding 101. For anybody outside of a blogger or hobbyist, it’s hard to take the Geeklog brand seriously. Pointy haired managers scoff at such a name (I’ve seen it). Sure you risk confusing or alienating people but I feel Geeklog, as a brand, is hard to sell. That said, even without a name change the remaining points are crucial.
• Change your image – The Geeklog homepage screams mid-1990′s era design. It’s the first impression we give users. Even if you don’t want to compete directly with the bigger kids on the block, you can’t argue that Joomla, WordPress and even the Geeklog fork looks better. It’s the first impression a user gets. I think improving the Geeklog homepage will lead to more interest. Once captivated, I have now doubt the codebase speaks for itself but, for now, the Geeklog homepage is forgettable for new users.
• Get social – Geeklog is no where to be found on Twitter, Facebook, etc. The missed opportunities here are, frankly, staggering. The PHP community (as well as Drupal, Joomla, etc) all have a strong presence in these areas and I have no doubt the Geeklog community could benefit by joining the conversation.
• Blog – Let’s face it, there isn’t much in the way of active Geeklog developers. The ones there really need to blog about what’s going on behind the scenes. What are you working on? What’s a challenge you are facing? Any good commits lately? This in part gets back to the goal setting discussion but it is more todo with giving the community a glimpse of what is going on.
• Find a partner – Ok, this is probably one of the more controversial points and one that is often dodged in open source discussions but behind nearly all successful open source projects is an organization. Sometimes it is not-for-profits but many times it is a private company or two. Right now there isn’t a single Geeklog developer paid to work full time or even half-time on the core of the system. Geeklog’s current codebase, in my opinion, has to be worth that investment. I think part of the problem here has to do with the name, image and branding issues I brought up. That said, I know of a lot of organizations making selfish use of Geeklog without giving anything back. No bugs, no code, no testing, no translations nada. Zilch. Now before the hardcore OSS supporters flame me, I’m not suggesting the project be effectively run by a company or an organization, rather, there should be enough of a community still where they can contribute developer hours to the project. I believe strongly the project itself needs to remain organic able to change with the needs of those who lead…but that some investment by industry is needed. Who will stand up?

Now to the PHP community at large. As I look at AptitudeCMS, I see a body of work that started before there were any other PHP frameworks around. I started with an MVC implementation. I incorporated a simple template engine. Later added an ORM. Much of this happened over many employers and well before anybody uttered Zend Framework for the first time. AptitudeCMS as a project is a failure in large part because it was never really released as a “formal” project until well after current PHP framework space became cluttered. Fine, it is what it is. However, to see this stuff rot and be used only when I have a new project come up seems silly. I’m pleading, for my own sanity, don’t let this code go to waste. Feel free to dissect it, borrow anything you find useful and laugh at any bad code you dig up. Some areas of focus:

• MVCnPHP – It’s a viable alternative to Zend Framework’s MVC implementation. It’s small, configureless and doesn’t present file contention issues common with ZF controllers. I’m sure a Zender can point out ways around this but most ZF projects I’ve seen have all the logic in the controller which seems really wrong to me and is a bit painful when you have multiple developers working in the same controller. Sure SVN, etc can handle the merge but you end up with a lot of merges. MVCnPHP is much more atomic, view logic goes in a simple, small view class. Command logic goes in a similar command class. The controller is only responsible for routing requests between views and commands. An upside to this is MVCnPHP also has basic support for tainted variables. For the unaware, it’s a simple feature that notifies developers with exceptions when an unsanitized GET or POST variable is used.
• Filtering – I built a filter class on top of Zend Framework that can easily be added to MVCnPHP views and commands. Without much work it could also be incorporated into Zend Framework MVC implementations. Look first here then see the “cool code” in the Filter class which is nothing more than a class that passes calls thru to Zend’s library and then the abstract view that uses it. I doubt the code will tickle you as is but I think conceptually it has merit for someone out there.
• ORM->Form and Form->ORM – Because we use Propel we were able to dream up a way where we could hand a view an object and have it pre-fill from that object without us having to explicitly set the form field values. Similarly, in our commands we found a handy way of creating the same ORM objects from the submitted form without having to explicitly map and set the ORM object’s values. This was a huge time saver. I think with a little work this code could be modified for Doctrine. Here’s how we map a form submission to a set of object(s) and here is mapping a object to the form

One thing I want to warn the community at large about is I’m seeing what feels to me like a trend in PHP to conform. You could argue that this very blog post is me, in a way admitting defeat and conforming, but I want to state the obvious that you always have a choice. It seems like many people are choosing to use part of a framework they have already installed instead of challenging whether or not it is the best tool for the job. Just because a filter class is included in Zend Framework doesn’t mean you have to use it. Just because ezComponents has a workflow component doesn’t mean you must employ it. Fact is AptitudeCMS includes Zend Framework, has some PEAR libraries and even some things like MVCnPHP. You can argue bloat, file sizes, which is valid but I’m confident you can still cherry pick the best parts of a framework to give you something you can work with long term. I’ve used Flexy instead of Smarty, MVCnPHP instead of Zend Framework and Propel instead of Doctrine. Some could see those as one bad decision after another but it’s simply the result of a cherry picking exercise I did long ago. Today I’d likely make different decisions but I can tell you I wouldn’t put all my eggs in one basket. Nor should you.

This blog entry, a self admission to failure, hopefully didn’t upset anybody along the way. To be clear I’m the only one who failed here. Maybe “fail” is too harsh a word as I’m quite happy to make this transition but I want to be clear to Dirk Haun, the Geeklog Project and those of you whom I’ve brushed IDE’s with are all people I very much respect. I hate “losing” and this feels like a loss and will always feel that way. If anybody makes use of any of these suggestions please pass that along in an email to me. It will take a bit of the sting off.

Tags: PHP