I have been aware of FogBugz for some time as I am a regular reader of “Joel on Software”, have read several of Joel Spolsky’s books and have listened to interviewers with him from sources like IT Conversations. Andy and I have been looking for a good bug tracking package for some time and being daunted by the complexity and the difficulty with installing BugZilla we decided to look into FogBugz.
Andy took the first leap and bought himself a copy of FogBugz. Now I should point out that FogBugz is a commercial software package made by Fog Creek Software here in New York City. FogBugz is licensed on a “per-user” level which works very well and it should be noted that your initial purchase includes a license for the administrator and a license for one developer. The package also comes with a ninety day, no questions asked guarantee so that you can feel confident trying the package even though there is no simple trial download.
Once I had purchased the package I was able to choose to download the versions for Windows, Mac OS X (deprecated PowerPC only) or UNIX. I found this strange as Mac OS X is every bit as much UNIX as Linux, BSD or any other flavour that I could choose from and yet the Mac OS X version of the software is apparently completely different from the UNIX versions as it doesn’t even get supported on the same processor architecture. I selected the UNIX version as that is our primary platform and the one that we are able to support the best (we can also deploy small applications like this cost effectively on small, low resource virtual machines very cost effectively.)
Once I selected the UNIX option I was faced with a very small list of supported platforms. This is extra discouraging as the Mac OS X PowerPC platform is getting specific support instead of focusing on a good, broad UNIX strategy in general. The UNIX selection was dismal and disappointing. I don’t expect many supported platforms but from a product like this I have certain base expectations which include Red Hat RHEL 4 and Novell’s SUSE 10 as a bare minimum with hopefully support for Solaris 10 and Ubuntu 6.06 LTS. These are the four primary enterprise class platforms that the UNIX community is going to use with Solaris generally being used only by larger businesses. (I am not making any statements about the cost advantages of Linux vs. Solaris – I personally think that Solaris can be a great choice for small businesses as well I am just stating that small businesses seldom have Solaris servers.) For most businesses Red Hat RHEL 4 is the only platform needed and if this was the only supported platform I would understand. However, the actual support list is possibly the saddest list of supported platforms that I have ever seen from a commercial business application.
These are the UNIX platforms that are officially supported by Fog Creek Software for FogBugz: Red Hat 8 & 9 (these are very old version from the time when Red Hat did not have separate server and desktop editions showing Fog Creek’s penchant for running their products on desktop devices – current products supported by Red Hat are many generations newer than this with RHEL 2.1, 3 and 4 being the only reasonably new versions and only RHEL 4 being installed in most shops today and RHEL 5 due very soon), Fedora Core 3 and 4 (FC 6 is current and Fedora 7 is due very soon), Debian 3.0 (which has been classified by Debian as “archived”,) FreeBSD as new as 5.4 (but they are on the six series and have been for years now,) Gentoo 2005 (obviously not current), Mandrake 9.2 (Mandrake is no longer a product – it was superseded by Mandriva a few years ago), Mandriva 2005 (once again, old,) SUSE 8 and 9 (but not 10 which is the current series (10.2 is current) and 11 is due soon), Solaris 8, 9 and 10 and Ubuntu 6.06 LTS. Of this entire list only Solaris and Ubuntu are considered to be serious and current server operating systems.
The problem with FogBugz on Solaris is that only Solaris on Sparc is supported and not Solaris and x86. This is one of the reasons why small companies tend not to use Solaris because its native platform is rather expensive and specialized. This severely limits the usefulness of Solaris as a platform for many customers. It is also completely out of character for Fog Creek to support one extremely enterprise platform while everything else is the total opposite. The only operating system option that remains as a sensible, broadly available platform is Ubuntu 6.06 LTS. This is the one option that actually makes sense. Ubuntu is fairly popular as a server platform (although not in the league or Red Hat or SUSE it is at least a very serious choice) and version 6.06 LTS is the “enterprise” edition of Ubuntu that is both current and is available with support from its parent company Canonical. However, Ubuntu has yet to gain serious traction as a server OS and varies significantly from the common enterprise server Linux options so your usual IT staff will have a bit of a learning curve to switch over to it which is not what you want when deploying an important system such as your bug tracking system. You want simple and stable and you want something that fits into your current corporate architecture.
The other operating systems available under UNIX, that is not Solaris or Ubuntu which we saw are seldom good options unless you are big enough like us to have Sparc servers or have staff that have already standardized on the very unpopular Ubuntu Server, are all, except for FreeBSD, desktop targeted systems, especially Fedora (the “experimental” version of Red Hat) and Gentoo, and all are horribly out of date most of the options being several years old. So even those operating systems that once upon a time had the availability of support options from their makers (like Red Hat 9) have passed their End of Life by many years. No self-respecting systems administrator (or anyone who values their jobs) would ever take the kind of risk necessary to install such ancient, unsupported systems. These system are years past the end of their security and stability bug fixes and running them would leave your IT shop very vulnerable unnecessarily. This selection worried both Andy and I very much because we began this process by doubting the long term support and availability of the FogBugz product. Even if FogBugz continues to be available we have little confidence that Fog Creek will continue to make it available on modern, supported operating systems. We can only assume that Ubuntu 6.06 is the last version of Ubuntu that they will ever support and that in two and a half years when Canonical no longer supplies bug fixes to 6.06 that we will be stuck with no supported options whatsoever. Perhaps more worrisome is the impression that Fog Creek Software has moved into a “holding pattern” and is not making current software because they are no longer looking to innovate but just to get as much money as possible off of their past work and will just shut down when that is no longer paying enough to keep the lights on. The platform selection available is extremely indicative of a company on the verge of closure. If they do intend to be in business for a long time they are definitely not running the company that way.
In addition to poor operating system selection and horrendous version support, FogBugz also only supports Linux and FreeBSD operating systems on x86 32bit! I realize that many shops are currently still using 32bit Intel and AMD architecture systems and my plans are to perform my installation no a 32bit system but many shops have invested in AMD64 technology with Opteron processors or they follow-on Xeon processors with EM64T. In either case many IT departments have moved to 64bit and do not want to be installing 32bit products anew. More importantly many shops may have been planning on including FogBugz on a large intranet server that is pre-existing. Often today this server would be a 64bit server and FogBugz is not supported in this arrangement. Of course, no shop is running any of the “toy” operating systems that are supported by Fog Creek on any current production servers so the availability of existing web servers is irrelevant.
That was our first tip that something was wrong. Windows is the only broad platform that seems to have any serious level of support and it is, IMHO, clearly the wrong choice for a product such as this. Windows has its place but for a small application such as this it is not it. The only thing that would make me reconsider that position would be if FogBugz leveraged the very impressive ASP.NET platform available on Windows 2000 and 2003. That brings me to my next point.
Possibly the most troubling aspect of FogBugz is that the application is written in Microsoft’s very old Active Server Pages or ASP platform. ASP is available on Windows products still today but it is old, slow and no longer developed. It is also not significantly available on any other platform nor does anyone really care, as far as I know. I have never heard of ASP being considered a competitive advantage for any platform and I was not aware that any serious shop was still using the technology for new products. ASP was a moderately acceptable technology in its day but that day was many years ago and much of the current web based product architecture has matured since then and ASP was long ago relegated to the annals of web history. ASP is not a fast, stable or robust as ASP.NET. I have read Joel Spolsky’s defense of using ASP in Fog Creek products in the past and I have personally found his arguments to be thin and questionable. The thing that leads me to believe that ASP is even more of a bad choice than it seems is because ASP is not available, at least not natively, on Mac OS X or on any other flavour of UNIX.
On the UNIX platforms inclusive of Mac OS X FogBugz is written using PHP. PHP is a scripting language used on the server side and is very similar to ASP. The differences are that PHP is currently being developed, vastly more widely used, can be accelerated through many different means and is far more robust and feature rich. It is also platform agnostic so you can write in PHP for many platforms without needing to port your code or at least with only minor porting needs. Instead of writing FogBugz in PHP and making it available on every platform using the same code base Fog Creek writes FogBugz in ASP and has the PHP code generated by the ASP. It is good that they are using an automated build for this process but it tends to make one think that the PHP being generated is ancient and not kept up to date at all. It also tends to lead to limiting powerful PHP to the rather wispy feature set of ASP. (I can just imagine how embarrassing it is for Fog Creek when interviewing programming candidates when they tell them what tools they will be working with!) From the supported UNIX platform list it is clear that FogBugz only leverages features of PHP available up to version 4.0 which is quite old at this point and there are many significant enhancements that have occurred since then that should be being taken advantage of by any current production software of this nature.
Our final shock, prior to actually touching the software, was the list of supported databases. On the Windows family there are three options: Microsoft SQL Server, MySQL and Jet. SQL Server and MySQL are both big, enterprise class databases and are very reasonable options. Supporting Jet is just silly. Jet is a “toy” desktop database used by Access when the people working with Access don’t bother to go to SQL Server (which is freely available on every platform using Jet.) Jet does have the advantage of being file based instead of using a Relational Database Management System (RDBMS) which means that for really tiny installations of FogBugz where you want it to take up as few resources as possible that FogBugz does not run a database server and instead just stores everything in a file. This would work for really tiny shops, I guess. But personally I would go to SQL Server even if for just a single developer. SQL Server 2005 Enterprise is free and a really great product and extremely easy to use.
In the end, all three supported databases are very reasonable options although if there is ten minutes being put into Jet I would question it. But whatever, features are good things. What I am surprised by is the lack of support for PostgreSQL which is less popular than MySQL but is still quite popular and gaining in popularity all of the time. PostgreSQL is an enterprise database that is often considered to be superior to MySQL and is freely available, like MySQL. It is common for software the supports one to support the other. With a good database abstraction layer supporting many databases (Oracle, DB2, Sybase, SQLite, Ingres, etc.) would be very easy indeed. MySQL and PostgreSQL are very good option, though, because of their broad support, licensing terms, stability, features and cost. Both can be used for an unlimited number of users without having to pay per-user for licenses. In a large installation of FogBugz it could become a cost issue using Microsoft SQL Server as the user licenses would add up very quickly (in a large installation the free version would no longer be adequate and the enterprise scale and cost would be needed.) MySQL and PostgreSQL offer their enterprise features for free so smaller businesses can enjoy similar benefits to companies paying for expensive Microsoft SQL Server.
For these reasons I would have been happy to see broader database support as adding additional databases should be relatively easy. I am not asking for every database to be supported but one or two additional choices would have been nice. As it happens we would have chosen MySQL in either case but I can easily imagine shops that would have liked other options.
All of the factors that I have mentioned so far seem to point to FogBugz being designed thinking that it would not be purchased by serious IT shops with real systems administrators and real servers. It really appears that they are envisioning this as a product being purchased by people who are developing software at home, on Windows and aren’t particularly worried about stability, speed, features or availability. In which case making this product a web based product seems to be a strange choice. A Windows native application would seem to make more sense. It light of the issues that I have mentioned it is hard to imagine very many actual enterprises or serious businesses being willing to even evaluate this product as it would violate IT department standards in many situations and falls beyond the range of “best practices” anywhere.
Companies need to realize that a bug tracking system is almost always going to be used as a critical corporate function even if it is just being used for the software developers to use themselves. No developer is going to be effective if their bug database is hacked or lost or unavailable. The cost of the potential lost developer time is not worth the risk of a product like this, IMHO. I just find my developers to be highly valuable and using amateur software to support them is a risk that I cannot justify.
All in all it is a dim picture before we even attempt to install FogBugz. We chose Ubuntu 6.06 LTS running on VMWare Server 1.01 which means that we have to use MySQL as our database.
After finally getting a supported platform in place it was time to begin the actual process of installing FogBugz. FogBugz is a commercial product and have certain expectations for the installation of a product that I am purchasing, more or less, for its ease of installation. There are several competing packages on the market, more notably BugZilla, that are free and open source. The biggest drawback of using these packages is that we were unable to find one with a good installation system so this was a driving factor to try FogBugz.
Unfortunately we discovered that the installation process was not as simple and straightforward as one would hope. Instead of providing a standard RPM package or even a DEB as the supported platform is Debian based Ubuntu the software was only available as a tarball which is not a preferred distribution format for enterprise environments.
If the only issue with the distribution was that it was a tarball (a file that has been “tape archived” and then compressed) it would be relatively minor. Several major products are distributed this way although I recommend against it as enterprises like a simple, standard deployment system (like MSI on Windows) that allows for easy tracking of deployed applications. But the installation is not that simple and requires a bit of manual intervention, file copies and more.
Given the amount of manual work that had to be done and that there was no package management system being used it was quickly discovered that I had to spend a long time dealing with manual package management that should not occur under Linux. It is similar to dealing with a Windows system with manual DLL installs except this is Linux and there is a system to automate all of that and it was not used. Very unprofessional. The installation process was not documented even for the supported platforms so I had a lot of trial and error to do to get the product up and running. It seems as though I am the only person to have ever installed this product and that they were just guessing that it would work properly. Not encouraging.
I finally did manage to get the package installed and working with the exception of the PHP acceleration detection. No matter what I did that portion of the FogBugz software would not work properly. As there was no proper documentation I was working blind and, as far as I could tell from my limited experience with PHP caching and acceleration, the FogBugz software was not working properly in its detection routines and everything else was working just fine. But this caused me to never get a “clean” install but always with errors.
Once the system was installed and running we tried it out for a day. The package itself is fine but not ground breaking. It is a nice package but I found it to be rather unintuitive but I am not a full time developer and perhaps for someone who is using this all day long the interface is perfect. I cannot make any good statement about the product itself. The interface was far better than other products that we looked at – much cleaner and simpler and ready to use out of the box.
In the end, after discussions with the development lead who’s call it was to decide to keep the software we finally decided that we were not happy with FogBugz and would return it. If the package installed without manual intervention or even if it was predictable and simple to reinstall I believe that his preference for the interface and ease of use would have made us decide to keep the product. But having our IT support have to support a new operating system just for this one product, have it licensed per user instead of free and open source, written in ASP and so difficult to reinstall that we could not provide reasonable assurance that it could be restored after a failure made it a dangerous product that we could not recommend to any serious business who will rely on the functionality. It is a good start but Fog Creek Software needs to, in my opinion, think of this as a tool for businesses and not as a toy for single person start-ups and they may have a new customer in us. But the focus from the ground up appears to be as a toy and not as enterprise business software and we can’t justify the time and money necessary to make this software work.
In the end we returned our license and got a refund. The customer service at Fog Bugz was awesome. They asked some questions and took our responses and seemed genuinely interested and concerned as to our reasons why we couldn’t use the software as well as our suggestions, like supporting Red Hat 4, that would make us even more likely to use it in the future. The customer service was so good that it made me wish that I wasn’t returning FogBugz and tempted me to give it another try. But in the end the software just isn’t ready for prime time yet and we are going to move on to BugZilla as ugly and difficult as it is.