SMF Revisited

I haven’t spent much time with the folks at Simple Machines Form in a long time, but I was recently given the opportunity to discuss the question of what I would have done differently, if we’d started the project knowing what we now know. The question is a hard one – because our motivations at the time, were very different that what would motivate us now.

At the time, there wasn’t any good, 100% free, PHP+MySQL discussion forum package out there – so decided to build one and to use it as a learning opportunity for ourselves and for others. Those were the goals: PHP+MySQL Forum, and Learning Tool. Now, however, I probably would be bringing a more ambitious suite of goals to the table. For example, “Simplify the task of managing public asynchronous communications” or “support and build better standards between online communities”. Building a “communication tool” as opposed to a “forum” forces us to re-visit basic assumptions, which have been used in forum packages for years now. Either way, here are some thoughts.

First, I would have followed an MVC architecture for the code. Although SMF does a reasonably good job of separating code from layout (as good as any other package out there), it’s not a true MVC application, and that makes it difficult to develop for and extend. It also makes it very difficult to split the forum out across servers. However, to be fair, we deliberately went more procedural in the early days because it was easier to teach developers – that’s something we would have given up.

Second, I would have changed the way we handled the execution path. SMF tries to control everything, from startup to shut down, with changes to PHP ini settings, buffers, error handlers, etc. This makes SMF incredibly difficult to integrate into another package. I would have taken a Single-Entrance, Single-Exit approach, and let SMF be wrapped, included, etc. Although this would have made other tasks harder, it would have opened up the door to easier integrations, that didn’t required shared memory and includes (which makes it almost impossible to integrate with GPL’d code).

Third, I would have changed the appraoch to localization and internationalization (l18n and i10n) – the SMF concept of language files is nice, but it isn’t very extensible and it is inherently difficult to use when you’re building extensions. Borrowing something like CakePHP’s __() function would have been a good idea.

Finaly, I would have build the software with the API’s in mind from day 1. The biggest issue in most of these shrink-wrapped packages, is that most vendors believe their software is the be-all, end-all of the software stack, and they don’t properly consider the other elements in the workflow. I’d be looking at a couple of basic RESTful API’s (create/read/update/delete) posts and members, a more complex API for admin functions, and an API for exposing and leveraging members. This last would be specifically to let people build systems around the SMF membership more readily, and to let people run forums that integrate into other logins more easily (i.e. run a forum that hooks into my office LDAP server for authentication, or OpenId, or Facebook Connect).

Either way, I would have been trying to develop some standard API’s, then I would have contributed modifications to other forum pacakges so that they, too, could implement the same APIs. We have a big challenge in the online community space, in that we haven’t made our data very portable, nor have we agreed on any standard APIs other than exporting RSS feeds of our posts.

That being said, these “what if” dreams are based on a lot of learning and a shift in what’s important to me. SMF was always a learning project for the team members, and part of that learning process is going through good and bad decisions – not just shortcutting to the solution.


VP HCM Products at NetSuite and Founder of TribeHR and Lewis Media. Waterloo Region Enthusiast and active volunteer.

Submit a comment

Your email address will not be published. Required fields are marked *