what do all the new bug tracker statuses mean? Are they just different cryptic categories of wishlist or something more exciting?
- @Layershift (via Twitter)

If you haven’t stopped by the Roadmap/Wishlist lately, this is what Layershift is talking about:

Previously, we had one category called “Wishlist” that contained everything else beyond the current release.  The problem with that approach was we had to dig through the entire wishlist every time we started a new release, even though we knew that some of the items weren’t immediately actionable regardless of how many votes they had.

We also started to have issues from a vocal minority of users (who are passionate enough to care; and we love them for it) who were frustrated that their requests were occasionally pushed from release to next release through several updates.  That was happening because we kept the most interesting feedback — far more than we could possibly do in one update — assigned to the current release so we wouldn’t lose track of it at the bottom of the wishlist.  We wanted to be aware of those things as we decided where to draw the line for each update; and we chose between those items, released the update, and moved the unfinished tasks into the next update to repeat the process.

To set people’s expectations a bit better, we’ve removed the nebulous “Wishlist” category and we’ve added a few more.  We had a little fun with the new category names; because, frankly, sorting through 500+ requests every couple days can be a tedious affair.  We did add some illustrative descriptions to the categories, but JIRA (the software that runs the roadmap/wishlist) doesn’t actually display them where people would notice them.

Here are the missing descriptions:

Rather than gathering *all* the best ideas into the next release, we’ll be using The Yellow Brick Superhighway category to keep track of them.  Those are the ideas that expand the project’s reach; such as expanding the platform (what plugins are capable of) or core functionality.  These are the things we lose sleep over until they’re done.

The Sea of 1000 Wishes category is the incubator for new requests, where they receive comments and votes until they move to the near-future roadmap. It includes everything from big ideas to “It would be nice if you moved this button 3 pixels to the left”.  I wouldn’t take the sarcastic category description too seriously, as everything on that list is something we’re committed to doing if enough people ask for it.

Cryostasis is a category we’ve needed for a while to contain great ideas that just aren’t possible at the moment.  In many cases the ideas may seem simple enough, but there’s something we’d like to do with the platform (such as switching to jQuery, or performing a refactor that affects the API) that would make the requests much easier to do properly.

With Everything Looks Like a Nail, we’re finally able to sort out all the good ideas that we just don’t see ourselves making a mandatory part of Cerb4′s core.  This includes everything from “I want a live chat feature” to very subjective workflow tweaks.  We built Cerb4 on top of our Devblocks framework so we could deliver tweaks and features to segments of users — or even to individuals — without making a mess of the app and forcing an amalgamation of 1000 opinions on everyone; pleasing no-one.  Because of its subjectivity, this is the best category for sponsors to pay for the development of things they want to get them done immediately.

And lastly, An Ounce of Prevention is the category where we’re quarantining ideas that introduce too much complexity or that go against the spirit of the project; such as: locking things down to the point it hurts collaboration, editing customer email after the fact, making tickets parents of other tickets, etc.  We’re keeping those requests here in the open rather than deleting them so people are free to build their case in support of them.  This helps us manage expectations; so people don’t see one request sitting untouched for a year and think everything is neglected that way.

Ultimately, we have some big ideas for transforming the Roadmap/Wishlist into a far more interactive community meeting place.

Thoughts?

-Jeff@WGM

One common question that we’re asked nearly as often as “How the heck do you pronounce Cerberus?” is “How the heck do you guys expect to stay in business by sharing all the source code, giving away licenses, providing free support, and only charging people a one-time fee for a license they can use for several years?”

To be honest, we’ve never fully reconciled the conflicting principles that we inherited from both open source and capitalist philosophies.  We build software because we like building software.  We share so much because it’s the best way we’ve found to have a huge amount of great feedback to draw inspiration from.  It’s also the best way we’ve found to write reliable software (“more eyeballs find more bugs”).  Over 7 years later, we still get excited about new ideas because we’re still building something that we need just as much as everyone else.

There was surely a point in the history of the project where we could have done things differently and tried charging very large numbers to very large companies; yet we’ve always considered ourselves users of Cerb first and a business built around Cerb second.  While we likely would have made more money going the enterprise route, I doubt the project would be anywhere near as inspired or popular.  We want to build something for people who aren’t intimidated by innovation.

We recognized pretty early that the real value here is the experience we’re gaining from working with all of you while building this, rather than just slapping a price tag on the bits and bytes that come out of that collaboration.  Cerb4 is always going to have to evolve alongside the way people choose to communicate online.  The project is always going to need custodians that filter and refine feedback according to tightly-held values.  We’ve been well served by that philosophy so far, and we’re not at risk for becoming irrelevant just because you guys have all the source code.

I see plenty of software companies who are paranoid about letting people see the blueprints and guts of their apps because they don’t really understand where they’re creating lasting value.  People can always knock off a snapshot of your application at a given point in time, with or without the source code; but if your copycats are always dependent on your ideas and vision then you really have nothing to worry about.  You see huge companies hiding demos and screenshots of their applications because they understand the first half of that.  They fail to see that people want to ride along with an evolving project, with people they trust and enjoy collaborating with.

Cerb4 is a business investment, it’s not a $50 video game.  There’s no build-up to a final level with a big boss at the end, after which you uninstall and move on to something else.  We’re not selling something consumable.  Cerb4 becomes a member of your team, every day, pulling its own weight, helping your people communicate, improving in its small way whatever the founding purpose of your organization is.  You wouldn’t want a team member who couldn’t learn from past mistakes, so why would a cheap knockoff pose a threat?  A knockoff isn’t going to have any context for how a great application arrived at its conclusions.  They can’t show their intermediate work.  They’ll have a high propensity for repeating most mistakes which start with seemingly obvious answers.

Here is where capitalism creeps back in (as it should).  The inevitable flaw in our idealistic attitude about licensing is that someday the word-of-mouth referrals we get won’t continue to bring in enough new people to pay our existing team of people who are attending to our existing happy users.  That premise is already flawed to begin with because we should always be spending most of our time working with the people who are already on-board about the current direction of the project — not compromising our vision to appeal to a wider audience.

We want it both ways.  We don’t feel that charging more for licenses, or charging annual renewals for owned licenses, is providing any extra value to you guys.  However, we do need more ways to fund the project year-to-year from existing people who like working with us — people who want us to remain in business.  We’ve had an endearing chuckle over the occasional distraught call we’ll receive from someone who is genuinely concerned if we’ll be around next year — but, appreciation from us aside, we realize it’s a serious concern for many people who are investing in the project as a long-term decision (which we’d like to think is everyone).

So here’s our compromise.  A major way we can provide ongoing value to existing, happy Cerb4 users is to make sure we’re handling any issues or feedback as quickly as possible.  We do a lot of free support between Town Hall chat, our helpdesk, the forums, the blog, Twitter, etc.  While we don’t plan on cutting anyone off from free help, we’d like to offer a ‘Priority Support’ optional service to people who want assurances that their ideas and concerns will be answered the same business day we receive them.  Those people will jump to the front of the line everywhere that we interface with the community.  When we’re finished with the Priority issues then we’ll handle everything else.  We’ll make sure all Priority issues have responses before we leave at the end of the day; whether there are 15 or 150.

We started from the basis that anything we bring in on services for existing licenses from happy, willing, existing users is better than our one-time licenses which require so much attention on bringing in new business.  We are also conscious of the fact that if *everybody* is a priority then nobody is a priority.  So we established a price for the new level of support that we feel is sustainable to always have enough people trained on our end to help you out.  We also probably could have asked for a lot more if we felt like managing support contracts on a monthly basis, but we decided we wanted to cover people for an entire year to reduce the hassle on both sides.  We can offer a more pure price if we’re not factoring in the cost of chasing down invoices and expired credit cards every day.  When we’re asking for a lump sum for a service we have to keep things psychologically reasonable.

We arrived at a price of $399/yr for Priority Support for treating three (3) of your provided contacts as extra special; which is discounted to $199/yr for small businesses (under $250K USD revenues), educational institutions, registered non-profits, and open source projects.  Depending on who you are, that’s probably going to seem like too much or too little.  If you think it’s too much, don’t pay it!  You clearly don’t see the value in having our near-decade of experience on this project at your beck and call.  If you feel it’s way too cheap, then buy it and think of some things you’d like to sponsor from the development roadmap to get them done faster.  We don’t ask for donations, but we’re happy to accept financial “calls to action” on something you feel you need sooner than later.  We also ask for less on custom development requests if it’s something we can roll back into the project for everyone to benefit from.

Since this post is already wordy enough, you can find the full list of benefits for the Priority Support plan in the shop:
http://shop.webgroupmedia.com/cerb4-priority-support.html

If you can see the value in supporting the project in that way, in return for our rapt attention to what you’re hoping to accomplish using Cerb4, then please sign up for a year of Priority Support (it’s about $33 a month).

Before I retreat to 4.2.2 and 4.3 development again for a while, there’s one more service we’re now offering as a package deal of several smaller things we’ve done on a consulting basis.  We’re calling it the Cerb4 Tune-Up service, and you can find the full list of perks, once again, in the shop:
http://shop.webgroupmedia.com/tune-up.html

We’ve seen many people run into trouble during an upgrade over simple things that could have been avoided by just following the docs.  Unfortunately, this has given that group of people a general distrust of upgrading.  With the Cerb4 Tune-Up service we’ll be your wing-man during the upgrade, maintenance, and backup of your helpdesk.  For $75 USD, one time.

As an added perk, we felt it would be fair to give Priority Support people one free Tune-Up per quarter (i.e. once every 90 days).  That’s about the same pace that we’re planning major releases like 4.3 and 4.4 for the foreseeable future — so it works out pretty well.

The last time I posted a blog post like this, we had a number of people immediately ask if I was making a subtle cry for help during a recession.  I assure you, this isn’t a cry for help.  We’ve been here for 8 years.  We’re a lean bootstrapped company, with a well-respected project, with a decent flow of new interest in the project, with many On-Demand sites whirring away and paying monthly — and we’d have to do quite a lot wrong from this point to be in serious trouble.  I’d be less interested in the fact we’re asking existing, happy people to continue contributing and more interested in the fact we’re doing something worthwhile enough that you read this entire post. ;)

Thanks, as always, for adding your voice and thoughts to the project!

-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

From: Cerb 4.1: Using workspaces, group filters and custom fields to auto-sort priority support

One thing I don’t understand is why this “Priority Support” example uses groups instead of buckets? Surely you can easily do the filtering (e.g. separate dashboards/workspaces) on buckets, but it seems to make more sense since the bucket is like a sub-folder of support, and these “Priority” customers are a sub-set of your total customer base who are requesting support at any time.

From what I can see buckets are somewhat neglected, and try as I might I’m finding it difficult to find a good use for them. I know that you try provide the tools rather than the use cases for them as such, but can you perhaps explain a bit about the sort of concepts you had in mind for buckets when they were developed?

-Damien (in the blog comments)

Hey Damien!

There’s no particular reason the example uses Groups over Buckets, it was just easier to illustrate.  On our production Cerb4 we use the groups “Development, Sales, Marketing, Corporate, Support Tier1-Tier3″; and buckets break down products or activities per group.  In development we collect “Wishlist” and “Bugs” as buckets, as well as replies to surveys about the roadmap, or people applying to beta test something.

I wouldn’t say buckets are neglected as a whole, though they were in this example.  Basically, we use buckets when everyone inside a group has a fairly equal chance of being able to handle the tickets within that group, and we use groups when different sets of people are involved; which is why we tier support 3 levels using groups (the developers get more involved as issues get more complex, and they aren’t interrupted with day-to-day questions on the front lines).

The problem with buckets is they’re just a single dimension.  If you decide to sort by product, language, skillset, timezone, normal/priority, or any similar metric, then you’re stuck looking at everything from one POV.  What this video was trying to show is you can use custom fields to add multiple dimensions (customer timezone+products+support level) and then use Workspaces to display lists that will always be a more fine-tuned workflow than the hardcoded Workflow tab will be.

With 4.1, buckets are actually more useful when you use them because their importance can be ordered within a group which affects how they display on Workflow/Overview.  Workflow also works entirely by flagging specific buckets as important (“buckets that are expected to be empty if we do our job right”) on that tab while hiding the rest on Overview.  That concept has been a huge boon for both on our live helpdesk and on my personal webmail.

You’re right that we try to provide tools for building workflow without endorsing a specific way of doing things, but we really should be providing more “How we use it” case study examples on the site and wiki.  There are probably plenty of tips in how I use Cerb4 differently for WGM or for my own personal e-mail that I take for granted.  When I get a couple minutes I’ll write a lot more about it.

Thanks!

-Jeff@WGM

Is there any way for us to monitor if the parser is encountering errors on incoming e-mail?
-a Cerb4 user

Hey there!

The main reason we added the ?loglevel=3 parameter to the /cron URLs is so it will suppress any unnecessary output when running the scheduler. It should only print errors to the screen (where something like ?loglevel=6 would print more debug/trace information). Traditionally, cronjobs will e-mail any resulting output to an administrator.

In the past we had people redirect output to /dev/null since the cronjob was noisy. We no longer suggest that since it does make sense to be notified if there were any problems parsing (which should be really rare, we audit the parser heavily).

As for a monitoring solution like Cacti or Nagios, we don’t capture every PHP error in Cerb4 since a lot of that could happen before our code has a chance to run or exit cleanly. I suppose you could have something like Nagios tail the PHP error_log, but you’d probably get a lot of pointless notifications. The most dependable notification would likely be the e-mail from the cronjob returning any output. When all goes well it should be silent on ?loglevel=3.

-Jeff@WGM

Can you tell me more about your CRM plugin?
-a curious Cerb4 customer

Sure!

At the moment the CRM plugin allows you to find ‘opportunities’ (leads) from helpdesk conversations and track them separate from tickets.  The nice thing about that is you can import leads from anywhere (as simple as e-mail addresses or with all their contact info), and then you can see what historical conversations you’ve had with those people.  For example, if I have a beta form on our website for a new project, I could import any signups as opportunities in the helpdesk, and then I could quickly tell which of them we know something about from past tickets.

Ultimately we’d like to use the plugin to do product management and associate products/services with customers.  Then each time someone writes in I’d know what our current relationship with them is.  I’d also be able to track custom fields along with the product/service.  For example, I’d be able to track a few notes about your Cerb4 configuration so we don’t ask you the same questions over and over each time you write in for support.  It’s bad for business if every time you write in we act like it’s the first time we’ve heard of you.

CRM for us right now is still more about what we can do than what we’ve already done; but as the latest released just showed, now that we have a really solid e-mail component at the heart of Cerb4 we can start to do some really interesting things on top of it.  Feedback capturing and time tracking are just the beginning of that mindset.

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