We recognize that the value of what we offer is subjective for each potential buyer.  A company that has been disappointed by a dozen other projects before discovering Cerb5 tends to feel we’re not charging enough; while a company with a low-volume of email — who could just as easily use Gmail for free to accomplish their workflow — tends to feel we’re charging too much.

Like any prudent company, we’ve made several incremental adjustments to our prices over the past 8 years to better harmonize perceived value and project sustainability.  That balance is a moving target.

For perceived value, the project is constantly evolving (e.g. streamlined usability, better performance, and “feature completeness” for a given point in time) which provides a higher return on your investment.  Cerb5 can perform more duties for you than past versions, often replacing less efficient patchwork solutions.  It may even free some of your team members from tedious drudgery (e.g. filtering junk, dispatching, answering the same questions 15 times, or erratically jumping between disparate activities rather than grouping similar work together efficiently) so they can do more billable work.  Our features foster collaboration, and the software encourages your team to cultivate your address book like the asset that it is.  We save you time, money, and sanity.  The degree of that production or savings determines how much you’d be willing to pay.  Our software isn’t a commodity or a status symbol, it’s an investment.  It doesn’t start depreciating the moment you install it.  As you grow, the production or savings scale with you while our prices remain relatively fixed.

For project sustainability, prices may rise a reasonable amount over time as the project becomes more valuable.  Income from upgrades reflects that existing users have a better idea of where the project should be headed than new prospects do; and a healthy project isn’t chasing new prospects at the expense of long-time user feedback.  Our team grows and accumulates experience as we support and build.  With more experience comes more opportunities, and if it became far more lucrative for our team to disband and work on other things then that’s exactly what our best people would do.  Developers, idealistic as we may be, are still capitalists with bills to pay and families to provide for.  Commoditization of software would be bad for everyone.

Our prospective buyers tend to fall into one of four opinions, which are probably similar to the breakdown experienced by other software companies:

1. “I paid less for the last version.”
   These people often received a promotional discount to encourage early adoption, or to help them let go of an end-of-life version.  When Cerb4 first released, it was such a dramatic change from Cerb3 that a lot of people in the community weren’t sure what to make of it.  The first release certainly wasn’t our complete vision, but we also couldn’t afford to spend several years perfecting it without some real-world adoption and feedback.  We encouraged early adopters by offering Cerb3 users an unlimited worker licenses for Cerb4 for about $250.  It was a one-time cost, and it included over three and a half years of free updates as we innovated our way toward the present.  It’s hard to blame anybody for objecting to that deal ending; but it wasn’t sustainable.  That worked out to about $71.42 per year.  At that rate, it takes 700 sales to cover a hypothetical $50,000 salary, and the business model discouraged us from implementing the feedback of existing (free forever) users over prospective (“I’ll buy if you do this and that”) clients.
2. “Your prices are way too cheap and my boss is worried you guys won’t stay in business long enough to push out the next update.”
   “If it’s too good to be true…” These people place a very high value on the project.  They’re accustomed to paying a lot more in exchange for less than what we’re offering, and they want to be reassured that we have a sustainable business model before they go through the effort of switching to Cerb.  While we do occasionally lose a sale for a very large enterprise client because our low price disqualifies us, the fact we’ve been steadily improving the project since January 2002 generally overcomes this objection.
3. “Your prices are way too expensive; there are a hundred other apps out that cost less, and just as many are free.”
   Most people don’t go out of their way to tell us about all their alternatives, they just choose one and we never hear from them again.  If someone sticks around to haggle on price they probably have a good idea of the value of the project.  Either we convince them that the value is worth the price, or they convince us that they need special consideration (i.e. the essence of business).  We offer discounts to educational institutions, registered charities, established open source projects, and cash-strapped small companies.  We’re not the cheapest CRM app — there are many cheaper.  We’re not the simplest CRM app — there are dozens simpler.  We don’t want our primary selling point to be over-simplification.  Our goal is to be working on software that you may need to grow into, but that you won’t grow out of.  Even after working on this project for eight years there are still so many possibilities, and so much more work to be done.  It never fails to surprise us how many other projects think the path to enlightenment is making things ever simpler and simpler.  Technology isn’t getting simpler, it’s just getting better at interfacing with humans.  In nature, the human brain is the most unfathomably complex thing we know to exist; and yet it’s fairly easy to interface with the one you have, and its capacity for improvement is nearly limitless.  The road to the year 2010 is littered with the debris of “simpler” alternatives to the pesky complexity of human thought.
4. “The pricing is fair.  While I’d certainly prefer to get everything I need in life for free, this purchase will pay for itself before long.  The sooner I put it to work the better off I’ll be.”
   This is where we’re aiming.

From a very early point in our project history, we vowed to write software for ourselves — not because we’re special, but for exactly the opposite reason.  Trying to please everyone is a dead-end.  We knew there had to be thousands of other companies out there who shared the same frustrations as us, and wanted the same things we did; even if they didn’t know it yet.  We were more right than we ever imagined.

-Jeff@WGM

4.1 (Build 890) is a quick maintenance release to address some minor issues reported by people who recently upgraded to the 4.1 release.  This update also includes some project-wide improvements to support the hosting multiple instances of Cerb4 from a single copy of the project files.  I’ll write more about that later.

Here’s a summary of the main fixes:

• Fixed an issue with the new ACL (permissions) system where users without access to particular plugins (e.g. Watchers/Audit Log) could prevent those plugins from triggering for everyone.
• Fixed an issue with Internet Explorer 6/7 related to non-English languages being defined as the browser locale.  Zend Framework 1.5 changed their locale auto-detection behavior and we inherited the bug.
• Fixed a few more places where the permissions weren’t being restricted properly (mostly: close ticket, assign ticket).
• Fixed the issue with the Support Center not allowing certain browsers to cache the resources (namely images); which often manifested more in SSL mode.  Things should be speedier again.
• A handful of other things.

In addition to the bug fixes, there were also a few improvements.  The bigger improvements here don’t directly apply to day-to-day use of the app, but make room for more scalability (cloud computing, distributed installations):

• Usability: You can now remove attachments that you had added to a ticket reply without having to discard and start over.  It’s silly browsers don’t provide this functionality since they’re the ones rendering the file upload control.
• Platform: The /libs/devblocks/tmp directory has been moved to /storage/tmp to simplify permissions and scaling.  The ‘storage’ directory should be the only place on the filesystem needing write access.
• Platform: the Cerb4 code now properly supports symlink installations.  We used realpath() in PHP previously which dereferenced virtual paths and led to problems.  The only things you need at the instance-level now is a framework.config.php file and the /storage/ directory; the rest can be symlinks to shared files.  This means you can cheaply share an APC cache between dozens of helpdesks per server.  We’ll write up some more instructions about this on the wiki.

Thanks for being a part of the Cerb4 community!

-Jeff@WGM

With the release of Cerberus Helpdesk 4.1 today, and a pile of over 147 improvements inspired by your feedback delivered into your waiting arms, it’s finally time for me to vindicate a comment I made about a year ago.

Back in May 2008, I wrote a blog post justifying a price drop at the time by saying:

You’re probably thinking this lead-in sounds like a typical justification for raising prices, right? Well here’s the curve ball… we think we’ve been pricing Cerb4 too high based on its exciting future potential that (for the most part) only we can see right now.

On our end, we have a unique perspective of the Cerb4 rewrite.  It gave us an opportunity to wipe the slate clean and start over with a load of things we knew we wanted to do better.  E-mail has changed far less over the past few years than the tools and philosophies behind building fast and scalable apps for the web.  Back in 2002 we didn’t expect the project to grow to this point.  There was no vision or plan in place, and the code was working only because it was between being broken.  By 2006 it was getting difficult for us to make any changes to Cerb3 without breaking things, as we had bootstrapped the project since the early days by accepting nearly every feature request in exchange for a couple sales.

That’s why for almost the first two years of Cerb4, we spent the majority of our time sweating through the invisible engineering required to make future development easier — designing a system that *would* be changed daily from good feedback, and would be built to thrive in that environment — even when all that work didn’t translate into anything people could see or play with.  Everything was about future potential.  We could picture it, but we couldn’t keep asking you guys to close your eyes and imagine it.

I’d like to think today we no longer need to ask you guys to imagine it.  It took two years of hard work and soul-searching to build the platform and concepts of 4.0, and from that point it only took about 3 months to deliver the 147+ improvements in 4.1.  That total counts some huge leaps forward (e.g. workspaces, custom fields done right, worker-level permissions) as single improvements.  We could never have done that without the Cerb4 rewrite.  Beyond the speed of 4.1 development, the app is (almost paradoxically) *more* maintainable now than before the recent update.  That’s all the result of having a plan.

Alright, I can hear the grumblers in the back row muttering “Enough with the foreplay…” — OK… OK!

We’ve had a lot of success with the community-edition of Cerb4 introducing new people to the project.  That version limits people to 3 workers and blocks a couple non-essential features.  We’ve talked to so many people who would like to use the full app, but felt the jump from $0 to $499 was too steep; and we’ve agreed, but we still felt strongly against disabling anything important to create a cheaper version.

With the latest development we feel we’re finally at a point where we can reintroduce the per-worker licensing, in the interest of offering a more affordable entry-price (even more crucial in the present economy), with the ability to scale up the number of workers gradually as Cerb4 pays off.

In a nutshell:

• We’re still offering free licenses to qualifying charities and open source projects.
• Small businesses (below $250,000 USD per year revenue) and educational institutions can now purchase Cerb4 for $99 (total) for the first 3 workers, for all functionality, and $50 per additional worker up to 15.  After 15 workers a license will become unlimited.
• Everyone else can purchase Cerb4 for $199 (total) for the first 3 workers and $75 per additional worker up to 15.  Then the same thing happens, a 15 worker license becomes unlimited.
• Everyone who sponsored Cerb4 development up to this point by already buying a license has an unlimited license with no costs and no strings.  You may have to ping us for a new serial number, but we owe everything to you guys/gals for believing in us.  You kept the lights on so we could get to this point.  Thank you! Thank you!  Thank you!
• Starter Licenses (the first 3 workers) and additional worker licenses can now be purchased from our store.
• We’ve also reintroduced an Unlimited License in the store which has the benefit of being $100 cheaper to buy up front than to upgrade past 15 workers.  It also retains the above discount for small business and educational use.

Inevitably, these changes are going to be much cheaper for some people going forward and a little more expensive for others.  We’ll probably have some issues come back to the surface, like “unpaid helpdesk volunteers” or disabled worker accounts.  We’ll continue to err on the side of fairness.

Everything said, we feel the one-time cost per worker *is* fair given everything you’re getting in return at this point — but I’d like to make one thing abundantly clear: If you want to use Cerb4 and money is the only thing stopping you, pick up a phone or open your e-mail client and talk to us.  We’ll help you out.  We don’t see ourselves as selling bits that are already written; the current state of things is our resumé, and your purchase will fund development going forward (with whatever new innovations that brings).  If it was realistic, we’d just plop down a huge subjective tip jar and be done with it. :)  We’re obviously not economists, but our process has worked well enough for the past 7 years.  Thanks to you for that!

I’m preparing several new videos to walk through the latest changes.  I’ll also do another post here about the biggest improvements.  If you’re really eager, you can scroll through the full list of changes in the forums.  I’ve bolded the things I think you’ll find most interesting.

Enjoy!

-Jeff@WGM

Ever since Cerb4 was a secret wink shared between me and my keyboard I’ve had this nagging feeling that notifications sent in e-mail about new e-mail seemed rather silly.  I originally tried to get away with only providing RSS notifications in the beta versions, but the community was quick (and right) to defend the existence of “e-mail about e-mail”.

The main distinction between notifications and watchers is in how they really fill two completely different needs:

• Watcher functionality, which consists of automatically sending copies of incoming or outgoing mail to separate addresses, is especially useful for managerial oversight, quality control, training, archiving/backups, or synchronization.  In these situations the copied e-mail isn’t primarily prompting someone to visit the helpdesk because there’s new mail.  It’s just more efficient for these activities to deal with a stream of e-mail to another mailbox (especially with something like oversight) than it is to click into every single ticket from a search or report.  In these situations a full copy of each e-mail message is the most useful content to deal with, opposed to a line of text saying “There is a new message!”.
• Notifications, on the other hand, are specifically intended to “ping” a worker to return to the helpdesk because there is new content that needs their attention.  This is the situation where I have usability and ideological problems with “new e-mail about new e-mail”.  RSS, while less familiar to your average user than e-mail, is specifically designed to syndicate events like a news feed.  A huge benefit of RSS is that it’s in a different context than e-mail, and you can also receive updates about non-email events at the same time.  You aren’t mixing up these RSS “pings” with your typical e-mail; nor are they contributing to the e-mail overload that Cerb4 is supposed to be taking off your shoulders in the first place.  While I’ll likely do another write-up with RSS tips, I consider the most important tip to have two different tools for reading blogs by RSS and receiving status updates by RSS.  For blogs I use Google Reader and for status updates I use Vienna (MacOSX) or FeedDemon (Windows).  When you’re working you don’t want a notification ping every few seconds because you’re watching 300 blogs.  You don’t want to learn to ignore the notifications completely (another reason to separate notifications from e-mail).

There is a subset of the community that uses the watcher functionality to circumvent the browser-interface and reply from handheld devices or traditional e-mail clients like Outlook.  That’s fine.  We designed the system so that was possible; the headers are proxied (in other words, your personal e-mail address is rewritten so the client receives your replies from the helpdesk and your direct contact information is protected) — but that’s not the main reason the watcher functionality exists.

A quick digression: a lot of the confusion between both situations comes from the fact we lump our original watcher functionality in with a plugin called “E-mail Notifications”.  The purist in me likes to pretend that e-mail notifications still don’t exist.  We really should rename that specific functionality back to “watchers”.

Food for thought!

-Jeff@WGM

Regarding The Fundamentals Of Our Cerby Are Strong:
we are not sure what to make of this message and find it, frankly, alarming. Are we to understand that your company and your product are in danger and that we had better move to another product? To us, this message sounds like a cry for help, or at least it rings alarm bells.
-a concerned Cerb4 customer

Hey there,

The issue is that everything we can do from our end — price, functionality, value, philosophy — has the risk of being overshadowed by the Market’s irrational, paralyzing fear of financial Armageddon.

As I mentioned in the very first paragraph of that message, our company tends to experience an upside when budgets are tight since our software is relatively inexpensive and provides a great value.  The only negative implication I can find in the message we sent out is the ‘downside’ note that we’re not winning every sale — who does in any situation?

We’ve always had the risk, when getting most of our income from one-time sales, that we’d someday saturate our niche.  Realizing that inevitability, we’ve built up our On-Demand option that provides ongoing services (e.g. application hosting, backups, optimization, support, custom development) for monthly residuals.  While that’s more of a time investment than simply selling licenses to run on your hardware, it’s also more stable and creates a stronger “outsource” partnership between us and our clients.  It’s leasing out our experience instead of depending entirely on software which was written in the past.

We’re not in grave financial danger — we could run the company from a coffee shop on a shared laptop if it came down to it.  Unless we start making a lot of silly mistakes, or the sky actually does fall, it’s not going to get that bad.

If we lose the pulse of the community and stop producing software that you feel is worth what you’re paying, then that would be a very appropriate point for you to jump overboard.  However, if you’re simply worried that some external forces will dissolve our company and force us into unemployment, you can worry when we start giving everything away for free and we stop writing spry responses to your e-mails of concern. ;)

-Jeff@WGM

Cerb3 was a bumpy patch in the rear-facing road of Cerberus Helpdesk updates. It’s a point where we had already realized that Cerb2 was making many daily tasks more difficult than necessary, but in finding a solution with that knowledge we made the major mistake of trying to introduce new ideas without removing any old ones. That rookie mistake was driven by a false sense of loyalty to the most conservative (and vocal) segment of our community who, in hindsight, will be “appalled” by the prospect of having to retrain their users regardless of our thinking. The final result of Cerb3 under those conditions, completely by our own hand, and in present agreement with the outcry at the time, came off as “gimmicky”. At the Cerb3 release, several long-term users said the project now felt like a “Frankenstein mix of ideas plucked from different places”.

Before I’ve completely assassinated Cerb3’s character, let me temper the above with a few facts: (1) I’ve been the lead designer on every version of Cerberus Helpdesk since the beginning in Jan 2002; (2) while pushing Cerb3 after its release, we did genuinely feel it was the best collection of answers we had to offer at the time; and (3) the simple and elegant solutions we’ve discovered since wouldn’t be nearly as poignant without Cerb3’s “com-mutiny” and our first real prospect of losing the community’s trust by trying to please everyone and ultimately pleasing no one.

I say this to establish the fundamental point about Cerb4: we knew the most important thing for the long-term survivability of the project was to return the focus to our original purpose — giving teams a low-hassle tool specifically built to share high-volume webmail — and that our best option for accomplishing that goal was to remove much more than we added. Instead of risking another Frankenstein, we started over and individually crafted each feature to support a singular, consistent vision for the project. For that reason, it’s a huge mistake to look at Cerb4 and compare it to earlier versions in terms of feature parity.

When Cerb3 reigned we knew about the “Frankenstein Factor”, but it was still just a disclaimer to say there were better ways to do everything. We hadn’t explored what those better ways were; and because of that, it was only ideologically painful to work with the system — as in, “there has to be a better way”.

What the Cerb4 rewrite has done to our marketing is interesting; it’s difficult for me to sit down and make a list of “killer” features in Cerb4, because, like any good tool, I’m not thinking about the steps required to use it — it just naturally extends my own capabilities. The fact the software gets out of the way *is* the killer feature.

That’s been our marketing challenge since the rewrite has started producing results: if you’re a user who hasn’t upgraded, how do we convince you it’s worth upgrading if we can’t be any more specific than “better workflow”? It turns out we have an endless litany of examples, and all we have to do to uncover them is to park ourselves in front of Cerb3 and try to use it again. With our inefficiency-forgiving habits broken, a trip back to Cerb3 land is like an HBO Late Night Comedy special — “what were the *beepers* thinking who designed this *beeping* thing?”

I could go into the striking differences for me — “peek”, inbox filters, buckets, Overview, Dispatch — but I promise you that the most effective way to evaluate, and benefit from, the improvements in Cerb4 for yourself is to use it long enough that your existing habitual bias starts to waver.

-Jeff@WGM

My new role from the boss upstairs that I decided to undertake is Cerb4 “Community Manager”. You know, that funny job title you hear tossed around popular online companies. It’s gotten so big it’s even entered the video game space over the past decade.

So what kind of monumental changes to Cerb4 can you expect, thanks to my new found powers? It shames me to admit it, but more than likely I’m just going to be that guy who writes to the blog every week. To prepare I’ve been playing with a few ideas on how to spice up our blog space:

• New Tips & Tricks I’ve discovered with all the  hours and hours of Q/A, testing and re-testing Cerb4. Plus more from the rest of our staff. And better yet insightful tips I steal from the forums ;)
• A look at the development process Behind Cerb4. Sharing the how & why we approach fixes and requests the way we do.
• Community Feedback Question & Answer. A chance to highlight problems that come up from time to time for Cerb4 users and more importantly a chance to share the answer with everyone.
• Tutorials and hopefully lots of ‘em. How-to snippets for anything and everything Cerb4. We’d love to throw some more video screencasts up on our website too!
• JIRA Milestone Round-Up, the name and idea is still in development but we’d like to find a way to share our opinions with the community on any unscheduled JIRA issues. By unscheduled we mean they’re still in the “no progress” queue and haven’t been scheduled yet for an upcoming release. We already have internal meetings where we go through these issues one at a time, we want to open up that meeting to you.
• Feature Request Spotlight where we showcase a new idea submitted to JIRA. These will be ripped straight from the mind’s of the Cerb4 community and displayed here for your reading pleasure. This is a way to expose an interesting feature to fresh faces that may have missed it in the junk-pile that is our tracking portal. Hopefully tunneling more votes and feedback so we can gauge interest from an even wider audience.
• Most importantly My Personal Rants on all things Cerberus.

My goal is to find time to do a couple of these write-ups on a regular basis. Got something better? Post it in the comments and tell us how much these ideas stink!

-joegeck@wgm

Putting a Price Tag on Bits and Bytes

Software is a tough business, but pricing software is an even tougher business. As obsessive full-time developers we often want as many people as possible to be using our projects, but we also have to strike a balance with the fact there are bills to pay and families to feed.

The price you’re paying for our software has to factor in the costs of ongoing development and support. In our case, the Cerb4 licensing cost is basically just passing around a (slightly-coerced) tip jar for people who like what they see so far so development can continue. As developers we like to constantly be stuck thinking about the future and what new things are possible from the pieces we’ve just built.

Customers tend to approach things differently. Very few prospective users are genuinely thinking about future potential when they see a price tag on software. They take a look through all the corners of a demo and website to get a feel for what is currently possible with the software – probably because they’ve learned over the years that developers can be incredibly undependable in their estimates about new development (and they’re right; but hey, we’re working with ethereal “thought stuff” here).

You’re probably thinking this lead-in sounds like a typical justification for raising prices, right? Well here’s the curve ball… we think we’ve been pricing Cerb4 too high based on its exciting future potential that (for the most part) only we can see right now.

A few months ago we switched over to per-user pricing because it seemed like a great way to offer a lower entry price for companies with few users, while companies with more users could contribute more (based on the theory software seats scale like office chairs). But that’s proven pretty artificial, and for these few months since that decision we’ve been dealing with several tough questions about per-user pricing, like: What if I want to deactivate workers who have left the company without deleting their history? What if we’re a small company that has dozens of volunteer helpdesk workers?

It has recently dawned on us that we’re just setting up an artificial obstacle for people with these worker limits. If you buy into our project, we want you to feel like you own the software. It’s not our style to litter the project with hooks and throttles just for the sake of cash flow. Just like overly-aggressive license validation procedures, it ends up punishing all the paying users out of the paranoia of going broke. The reality is that if we’re doing something genuinely useful we’ll find a way to keep the rent paid, the lights on and the fridge stocked. We may not become the next Microsoft or Salesforce.com with that mindset, but at least we won’t be holding you guys back when you decide to spend a few hundred dollars to use Cerb4 for your mission critical e-mail.

So here’s what we’re going to do: We’re going to remove the per-worker limitations for everyone. Those of you with 5 worker licenses are likely going “Woo hoo!” while those with 25+ worker licenses may be going “What the hell, Jeff?”. Please keep in mind what we’re trying to do here is for the project and community before ourselves, and the fact we may come off as manic-depressive in our search for ideal pricing from time to time has to do with the fact we’re developers, not prescient economists. We’re not fickle, we’re just incrementalists. Each tweak is based on a lot of ongoing observation about the impact of each decision in the real world (which is pretty hard to predict). We’ll continue to find ways to reward people who’s early contributions have helped us grow over the years.

The Impact on Owned Licenses

We’re setting the “owned license” base price for the project to $499 with no artificial limitations. We’ve brought back the small business discount for companies making less than $250,000 USD gross revenues per year which knocks 20% off the price (to $399). Educational institutions get a similar 20% discount (also to $399). Users upgrading from Cerberus Helpdesk 3.x get a 30% discount (to $349, the discount used to be 50% but it was against $995 for unlimited, so you’re still saving about $150 more from this tweak).

The Impact on “As-a-Service” Hosted Licenses

On the hosting “software as a service” end, we’ve stopped tiering pricing by users as well. The scaling issues we face in managing servers have very little correlation to total users, and more to do with how companies manage their e-mail behaviorally (e.g. never deleting spam, receiving lots of work-in-progress attachments). We’ve moved to a much more straightforward pricing model on hosting of just basing it on storage. All hosting plans from today will start with 5GB of storage for $49/mo. 5GB additional storage is +$25/mo and 10GB additional storage (prepaid) is +$42/mo. If this was purely dollars for hosted gigabytes it would be a bit expensive, but this covers the software, upgrades, support, phone support, backups, server monitoring at 4AM, and all those things which you’re glad we’re doing so you don’t have to.

With that Out of the Way…

I can’t guarantee that several months from now I won’t be sitting here telling you something else based on future information and observations; but with all the information and history we have at our disposal right now we feel this is the best direction for funding Cerberus Helpdesk’s ongoing development (so we can continue to reach for all that exciting potential we’re always talking about).

If you have any questions about what we’re doing, how we’re doing it, or what we’re aiming for, ask away! If you’d like to rant, send me the URL to your forum thread and I’ll read through it and post my thoughts without getting defensive or cranky. Nothing is off limits.

Thanks!

-Jeff

We started Cerb4 with the idea of supporting MySQL, PostgreSQL, MSSQL, Oracle, etc. As development has progressed, we’ve hit several issues where our database functionality needs won’t abstract or overlap effectively.

The major benefits of Cerb4 standardizing on MySQL 4.1+:

• Fulltext searching: Right now we’re implementing database-driven functionality where our supported platforms (MySQL and PostgreSQL, at the moment) overlap. On text searching, this currently centers on basic SQL-92 “LIKE” syntax searches. The downsides here are pretty obvious; there’s no boolean support, wildcard searching is grossly inefficient when looking for multiple words and the order of keywords must be precise. The ideal situation is to have the full feature set of MySQL’s FULLTEXT index type, which, while not perfect, opens up a more Google-like syntax that’s much more useful than what we’re currently doing.
• Internationalization: It’s much faster and cleaner to be able to depend on MySQL’s encodings and multibyte behavior than to abstract how each platform approaches i18n. MySQL has its own tricks too, like “SET NAMES utf-8;” being issued per connection to ensure the client and server are handling multibyte encoding the same way.
• Sub-queries/Foreign Keys/Cascades/Joins: With day-to-day functionality we haven’t had much of a problem avoiding sub-queries or foreign keys for MySQL 3.23′s benefit. However, to support this rather old version of MySQL we lose the ability to be efficient in database patches and maintenance tasks. While not exclusive benefits of MySQL 4.1+, cascaded deletes on foreign keys, sub-queries and joins in UPDATE/DELETE would make patching and maintenance much more efficient. We end up with a lot of N+1 queries presently, where if ‘N’ is based on a table like ‘ticket’ it may end up around 1 million repeats of a query. This ends up clashing with the default PHP execution time of 30 seconds (which is fine for rendering a typical page, and an eternal pain for upgrading/maintenance tasks in PHP when the execution time can’t be overloaded at script level).
• Transactions: Another needless concession to MySQL 3.23, without transactions we have a much harder time making sure partial data isn’t written to the database — especially while parsing tickets. Transactions ensure everything is successful or none of the changes are applied. We’ve always needed this, and MySQL 3.23 support has always been in the way.

All of these issues contribute to the speed of development.

That’s the case to be made on our end. Making this change would unstick several big feature requests, that are far more important to us than the marketing bulletin of ‘database independence’. We’d really like to hear from you if this change would be a problem for you.

Please take a moment to vote on this issue in the forums.