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.