Oscar Renalias

LifeType is a reasonably well-known multi-user and multi-blog platform built on PHP that I led for about 4 years since 2004, probably earlier than that, I can't remember but 2004 was the year of the first public release. I haven't been actively involved with the project for a couple of years by now, due to work and personal reasons but I've been meaning to write about my experiences with it over the years. Today I will start with the things that didn't work so well, or that I would have done differently were I starting LifeType all over again.

Support only one option, and support it well. 

This applies to combinations of modules/platforms/versions/configuration options, as the amount of possible combinations will grow too large to make it possible to support, e.g. PHP4 or PHP5, with/without escape_quotes, with/without a Unicode database, with/without mod_rewrite. Don't be afraid of reducing your target user base by reducing the options; those users who really want to use your software will have no problem setting things up as per your requirements. Those who can't go through the trouble are probably not the kind of user you are looking for anyway.

A couple of examples from LifeType:

• In LifeType we had support for many different ways of implementing friendly URLs: mod_rewrite, ForceType, etc, and in the end it was very difficult to support them all reliably
• We also tried to support both PHP4 and PHP5, since in the beginning of LifeType PHP5 was only in its early stages of deployment. Looking back, this was a mistake since PHP5 had some very good features that we had to ignore for some time and the code ended up being a mixture of PHP4 plus features from PHP5 but with workarounds so that they would also work in PHP5.

Additionally, having to support all these combinations will make your development environment too complicated (if even possible at all)

UTF-8 is the only way

Dealing with the myriad of encodings for non-Latin languages out there is not worth the hassle, specially if all the encodings will be mixed in the same database. If you're going to support multiple languages don't even think about it, UTF-8 is the only option. This is obviously very easy to say now in 2010 but in 2004 when LifeType was started things were not so clear and even PHP only supported UTF-8 well via additional modules that were not always installed in hosts.

Don't make it too easy

You don't have to make your software impossible to install but you don't want to make it too easy either, specially if the software itself is somewhat complex as this will attract less knowledgeable users. 

Set up a bug tracking system early enough

If you go for something like code.google.com or github.com, issue management is already in place for you. If you're running your own development infrastructure, consider setting something up so that users can report issues. 

However, based on my personal experience you should ignore forums at all costs. For every useful post in the forums, you'll get 50 questions that have been answered before, that are part of the FAQs or that should be reported as bugs; if your users can't be bothered to use the search functionality or learn how to use a bug tracking system, they don't deserve your time and attention either.

As the project leader, you have to be a dictator

If this some software that you started to scratch your own itch and that you later publicly released, drive it according to your own vision. It is fine to listen to users but most of the times they just ask for features that they personally need. No matter how easy it sounds to implement a feature, more code and more features mean more testing and more potential combinations (see above), which also means more potential problems for you as the developer.

It's not about engineering excellence, but end-users!

Unless you're building a platform, framework, application server or something that people can build other things on, your end users don't care how many development patterns or fancy OOP features you use through your code; 99% of end-users only care about features and ease of use, and the remaining 1% are either hackers or plugin developers who can probably manage with whatever code anyway, regardless of how kludgy or brilliant it is.

Wordpress is in my opinion the best example of this. Last time I looked at the WP code I was horrified, with its lack of object-oriented programming and mixture of SQL code with HTML code and PHP code in several places (disclaimer: that was a while ago, things may have changed since then!) But on the other hand it had plenty of features, it looked good out of the box and it worked relatively well with little effort and at the end of the day, that's what matters to users (for blogging applications anyway)