Scalix Forums

To paraphrase Kent Brockman (Simpsons TV reporter): "I, for one, welcome our new Xandros overlords." Well...maybe.

Last May, prior to Walter Lim's departure from the company, my frustration with Scalix had come to a head, particularly at the arrival of my maintenance renewal. I told him that I didn't feel that I could continue using Scalix in production, and he asked me what specific steps Scalix could take to remedy the situation. I then sent him a wish list, which he later forwarded to Glenn. At the time, it seemed right to address my concerns directly to management, rather than the public.

Given the recent acquisition by Xandros, and probably some serious deliberation by both Scalix and Xandros management about the future road map, I think that they could benefit from some constructive feedback from the community. To that end, what follows is a list of recommendations and wishes for Scalix. I'm interested to know which items resonate with the community, and which don't.

Simplify administration
Openmail didn't exactly start with an inuitive configuration structure, and its binary, multi-line logging makes the use of a logging server (or any automated log analysis) an exercise left to contortionists--I never bothered. As Scalix has grown and added more features, the configuration problem has gotten even worse, if that were possible. Many lightly or undocumented configuration files litter multiple directories, often shifting around between upgrades. And logging now takes place in multiple directories as well, making troubleshooting more complex than it need be.

Centralize configuration and add version control

• Even if all configuration files and directories were simply aliased to one area by default, that would be a start.
• Use subversion or something similar to allow easy change logs, snapshots and rollbacks of not just single config files, but entire directories if needed. This would also let admins and support get a quick look at what changes were made over time.

Create support script to speed support diagnosis
Many vendors have support scripts designed to gather and archive machine info (boot log, recent system logs, network settings, application configs and logs, etc.). Users are instructed to run the script prior to contacting support, and to upload the results to their support portal. The script runs interactively, asking about the nature of the problems, gathering additional data relevant to the issue (or defaulting to getting everything if the user is unsure). So much of the support process involves: "What version are you running," "Run this command and let me know what happens," or "Send me the output of 'x'," and so on. This could serve to simplify and speed diagnosis and resolution.

Create logwatch configurations and notifications for Scalix logs

Create a mechanism to allow Scalix connector instances to log errors to the server, to pre-empt the frustrated calls from users.


Revamp and consolidate online support resources

Make a support portal
Dave Kelly posted a blog entry some months ago asking for feedback on getting users to read the support materials, and he acknowledged the scattered nature of the resources: wiki, forums, knowledge base, manuals, bugzilla. He also asked for ideas--mine follow.

• For the short-term, the support page shouldn't be a collection of links. It should be a portal page, showing the most recent/popular entries from the various areas (forums, wiki, knowledgebase, bugzilla), with those that support (or the users!) deems most useful given special priority.
• It should also have an "uber-search" form to search all the above-mentioned areas simultaneously.

Redo the forums--Scalix has outgrown phpBB

• I'd urge you to completely redo the forums. Look at forum software from Jive Software, for example, that permits users to vote on entries as the best solutions. The Scalix forums have become so unusable that it's now very difficult to find anything in them, which leads to long-answered questions being repeated, unnecessary support emails and calls, and even more orphaned, unanswered threads that lookm bad and encourage frustration (then requiring support to issue the standard mea culpa that they answer forum entries as time permits).
• Moderate! The forums have a fair amount of chaff, and the signal-to-noise ratio seems to get lower and lower. It needs pruning and hierarchy. Promote the best and most relevant solutions, group related issues, and demote or delete the trolls, the incomprehensible, and the "Can you help my Linuxx?" posts. Yes some people will whine about censorship...whatever...the rest of us will thank you for a far more usable resource.

Remove the division between support requests and the forums.
It's clear that many support requests reveal information that everyone could benefit from--it currently takes an additional effort from the participants to "copy" that information into the forums. I know I've meant to on several occasions, but rarely have. The material seems to migrate to the forums weeks or months later, if ever.

Put the Scalix training manual online!
I realize that training is likely a profit center for Scalix, but even at my training, the materials were often out of date, and entirely "dead tree." No electronic version was made available, and there was no table of contents or index. It's borderline unusable. Why not push that material out to the wiki to encourage updates, explanations, and corrections? I seriously doubt that this would have much--if any--negative impact on the number of admins seeking training. Anything that makes the learning curve less steep allows Scalix to increasingly offload support to 3rd parties over time, permitting more rapid growth (look at Alfresco's success with this method). That would seem to be a good thing to me.

Create a troubleshooting guide

• Walk admins through basic steps, common things to check, commands to run, so on and so forth.
• Right now, google "Scalix troubleshooting" and see what comes back--it's pretty sad.

Update, migrate, or scuttle the knowledge base
95% of the content hasn't been touched in a year or more, and some of it has been supplanted by the wiki.

Client-access to ticketing system

• Allow customers to view their own tickets online, along with status and any publicly-viewable comments.
• Also, make a point of following up (even automatically) on outstanding tickets that haven't had activity. Provide a window, and if no reply is heard back in that window, auto-close the ticket and send an email to that effect.

Make more or all bugs public
I submitted a bug report (one of several this year) and was informed that it was a duplicate of an existing bug. How did I miss the existing bug? It was restricted from public viewing. This has happened twice to me, and I doubt I'm the only one. This seems a little pointless, and at worst, it's a time-waster for customers. I don't know if there are many other "restricted" bugs, but if there are, I'd make them public.

Add chat to the support area
Maybe no one will be jumping at the chance to be the live, chat support person, but I think it would help over time, and I'd also allow users to join instant messaging rooms where they can offer each other live, timely assistance.

Encourage community contributions

Create more examples of ways to exploit Scalix's abilities
Many of the new features in Scalix 11 are interesting and useful in theory, but there's a conspicuous lack of useful examples to inspire others with. Look at the Administration Plugins page. That lonely, addpf.sh script was been the sole occupant for some time, and only one other plugin has appeared since.

Create a "forge" site
I left this in even though this appeared after I sent this to Scalix--I wonder how many customers even know about it
While these can get messy, they also drive a lot of innovation and enthusiasm (see Sugar's and Alfresco's forge sites). I'd encourage Scalix to do the same. Create several seed projects, and then open the flood gates. A wiki can't really take its place, particularly with regard to organizing discussion and bug-tracking for each project.

Widen the wireless syncing options (a.k.a., ditch Notify)

• I know you all are already thinking about this. Florian told me about the Funambol/SyncML interest last summer, but I think this needs to be a priority. Personally, I think NotifyLink is a disaster, or at least a sinking ship. The client software is buggy, poorly documented, and frequently stops working or worse, starts deleting at random moments.
• The downside of their support for so many server apps and hardware clients is that the app is necessarily a lowest-common-denominator application. The interface is clunky. It doesn't take advantage of high-res screens. And on the Palm, at least, it doesn't auto-type previously-used email addresses--you have to type them each time (or use the awful lookup function). It is, in short, a dinosaur. Worse, it's often a dead or non-syncing dinosaur.
• My low opinion of Notify bottomed-out, however, with the daylight saving debacle this year. Appointments started showing up an hour off for NLES users. NotifyLink posted an unhelpful it's-not-fixable note on their KB, suggesting that users write out the time in the appointment description..I think I actually laughed out loud. Support confirmed this unfixability by phone. I reached out to Scalix support, and later filed a bug report with Scalix. I never heard back regarding the support request. Shortly thereafter, however, I found a fix for the problem. I found a way to extract the "Exchange-only" cdo.dll from a Microsoft patch, and posted the steps with the bug. Florian closed the bug with a notice that the problem was a Notify issue, which it was. When I emailed the solution to Notify, however, I never heard back, and that same, pointless KB note remains there to this day. I even fixed it for them and they couldn't get their act together sufficiently to pass the fix on to their other customers.
• Oh yes, and they don't actually seem to announce any of their patches or upgrades. I've only ever received emails about upgrades for client hardware that we've never used. I just get to be surprised every once in a while when I check their site.
• Notify's problems shouldn't be Scalix's problems, but when they're the only game in town, and so many execs and decision makers blithely assume that it's "Scalix for my Treo," Notify's failures and problems get unfairly attributed as Scalix's failings.

Okay, Scalix users, feel free to agree or disagree, but please do speak up.

--Aaron Hathaway

Now, this is a thread that could take up all my time going forward, but I guess your wish is my command.....

ahathaway wrote:Simplify administration
Openmail didn't exactly start with an inuitive configuration structure, and its binary, multi-line logging makes the use of a logging server (or any automated log analysis) an exercise left to contortionists--I never bothered. As Scalix has grown and added more features, the configuration problem has gotten even worse, if that were possible. Many lightly or undocumented configuration files litter multiple directories, often shifting around between upgrades. And logging now takes place in multiple directories as well, making troubleshooting more complex than it need be.

Centralize configuration and add version control

• Even if all configuration files and directories were simply aliased to one area by default, that would be a start.
• Use subversion or something similar to allow easy change logs, snapshots and rollbacks of not just single config files, but entire directories if needed. This would also let admins and support get a quick look at what changes were made over time.

Create support script to speed support diagnosis
Many vendors have support scripts designed to gather and archive machine info (boot log, recent system logs, network settings, application configs and logs, etc.). Users are instructed to run the script prior to contacting support, and to upload the results to their support portal. The script runs interactively, asking about the nature of the problems, gathering additional data relevant to the issue (or defaulting to getting everything if the user is unsure). So much of the support process involves: "What version are you running," "Run this command and let me know what happens," or "Send me the output of 'x'," and so on. This could serve to simplify and speed diagnosis and resolution.

Create logwatch configurations and notifications for Scalix logs

Create a mechanism to allow Scalix connector instances to log errors to the server, to pre-empt the frustrated calls from users.

Xandros' strategy is all about ease of configuration; this starts with the OS and goes through distributed management tools supporting multiple different platforms, including RedHat and SuSE. While most of the Scalix product is going to remain in place after this restructuring, I believe you'll see the biggest change in the admin environment. The Scalix Admin Console (SAC) might eventually go away and make room for a solution based on Xandros' management infrastructure, the xMC and the BridgeWays distributed management product (again, note, that this will *not* depend on the use of the Xandros operating system..... Details and timeline t.b.d., but it's guaranteed to change!

Revamp and consolidate online support resources

Make a support portal
Dave Kelly posted a blog entry some months ago asking for feedback on getting users to read the support materials, and he acknowledged the scattered nature of the resources: wiki, forums, knowledge base, manuals, bugzilla. He also asked for ideas--mine follow.

• For the short-term, the support page shouldn't be a collection of links. It should be a portal page, showing the most recent/popular entries from the various areas (forums, wiki, knowledgebase, bugzilla), with those that support (or the users!) deems most useful given special priority.
• It should also have an "uber-search" form to search all the above-mentioned areas simultaneously.

Redo the forums--Scalix has outgrown phpBB

• I'd urge you to completely redo the forums. Look at forum software from Jive Software, for example, that permits users to vote on entries as the best solutions. The Scalix forums have become so unusable that it's now very difficult to find anything in them, which leads to long-answered questions being repeated, unnecessary support emails and calls, and even more orphaned, unanswered threads that lookm bad and encourage frustration (then requiring support to issue the standard mea culpa that they answer forum entries as time permits).
• Moderate! The forums have a fair amount of chaff, and the signal-to-noise ratio seems to get lower and lower. It needs pruning and hierarchy. Promote the best and most relevant solutions, group related issues, and demote or delete the trolls, the incomprehensible, and the "Can you help my Linuxx?" posts. Yes some people will whine about censorship...whatever...the rest of us will thank you for a far more usable resource.

Remove the division between support requests and the forums.
It's clear that many support requests reveal information that everyone could benefit from--it currently takes an additional effort from the participants to "copy" that information into the forums. I know I've meant to on several occasions, but rarely have. The material seems to migrate to the forums weeks or months later, if ever.

Put the Scalix training manual online!
I realize that training is likely a profit center for Scalix, but even at my training, the materials were often out of date, and entirely "dead tree." No electronic version was made available, and there was no table of contents or index. It's borderline unusable. Why not push that material out to the wiki to encourage updates, explanations, and corrections? I seriously doubt that this would have much--if any--negative impact on the number of admins seeking training. Anything that makes the learning curve less steep allows Scalix to increasingly offload support to 3rd parties over time, permitting more rapid growth (look at Alfresco's success with this method). That would seem to be a good thing to me.

Create a troubleshooting guide

• Walk admins through basic steps, common things to check, commands to run, so on and so forth.
• Right now, google "Scalix troubleshooting" and see what comes back--it's pretty sad.

Update, migrate, or scuttle the knowledge base
95% of the content hasn't been touched in a year or more, and some of it has been supplanted by the wiki.

I agree that some areas of documentation, training structure (though I believe the instruction in our training has been excellent, given the skill of the instructors) and Knowledge-base-type documentation require serious update and/or a relaunch. Obviously, it's a grown structure and as you rightfully comment, we have outgrown some of it - part of the 'usual' pain of turning a startup into an established company. Given Xandros' grew up rather on the consumer side and volume business, some of their processes have better scaleability, while some of ours did provide more personalized service to larger enterprise account, to the better or the worse. We're currently evaluating what the merged structure will look like; most or all of the above are under consideration and we'll see what we can do. We'll need to strike a balance between commercial offerings and free services, though, i.e. free support through the forum and paid-for, commercial support offerings for paying customers; given that we operate in Open Source space where service and support is indeed more relevant than license revenue, this becomes a key business requirement.

Client-access to ticketing system

• Allow customers to view their own tickets online, along with status and any publicly-viewable comments.
• Also, make a point of following up (even automatically) on outstanding tickets that haven't had activity. Provide a window, and if no reply is heard back in that window, auto-close the ticket and send an email to that effect.

We will be adopting Xandros' ticketing system as part of the integration (very soon, actually, might be as early as next week) and that will provide further options to support customers. Also, our geographic and timezone support coverage will be improved.

Make more or all bugs public
I submitted a bug report (one of several this year) and was informed that it was a duplicate of an existing bug. How did I miss the existing bug? It was restricted from public viewing. This has happened twice to me, and I doubt I'm the only one. This seems a little pointless, and at worst, it's a time-waster for customers. I don't know if there are many other "restricted" bugs, but if there are, I'd make them public.

Too much work, sorry. I have made about 500 formerly restricted bugs public and by default, all bugs posted after August 2006 were public, except for a very short list of a few. Bugtracking in a commercial environment has some issues, a) some of the old bugs have a lot of customer information in there - in the new ones we have the option to mark some comments private, but keep the bug open in general - cleaning up a single bug, marking everything as appropriate, etc., takes about 5 minutes - we have more than 10000 non-public ones in the database, so you can imagine.... In general, we want transparency though. However, there is another problem, b) making everything viewable might create the wrong expectations with commercial customers; while the OSS and Linux community understands the meaning of priorities and targets in a bugtracker, commercial customers don't; I always wanted to blog about how to read bugzilla, but never really got there - it must be clear that we can only commit/guarantee certain things about bugfixes through a commercial process, i.e. that would actually go through Scalix Tech Support and the Issue/Casetracking system while Bugzilla is primarily a technical collection of information used by engineering.

Add chat to the support area
Maybe no one will be jumping at the chance to be the live, chat support person, but I think it would help over time, and I'd also allow users to join instant messaging rooms where they can offer each other live, timely assistance.

If this is attended by scalix support personnel, would you be willing to pay for it? An open IRC channel for the community (with some voluntary, non-sla scalix involvement) seems like a good idea...

Encourage community contributions

Create more examples of ways to exploit Scalix's abilities
Many of the new features in Scalix 11 are interesting and useful in theory, but there's a conspicuous lack of useful examples to inspire others with. Look at the Administration Plugins page. That lonely, addpf.sh script was been the sole occupant for some time, and only one other plugin has appeared since.

Thought of that - just didn't find the resources to do it - can you provide some contribs here?

Create a "forge" site
I left this in even though this appeared after I sent this to Scalix--I wonder how many customers even know about it
While these can get messy, they also drive a lot of innovation and enthusiasm (see Sugar's and Alfresco's forge sites). I'd encourage Scalix to do the same. Create several seed projects, and then open the flood gates. A wiki can't really take its place, particularly with regard to organizing discussion and bug-tracking for each project.

et voila - http://forge.scalix.com

Widen the wireless syncing options (a.k.a., ditch Notify)

• I know you all are already thinking about this. Florian told me about the Funambol/SyncML interest last summer, but I think this needs to be a priority. Personally, I think NotifyLink is a disaster, or at least a sinking ship. The client software is buggy, poorly documented, and frequently stops working or worse, starts deleting at random moments.
• The downside of their support for so many server apps and hardware clients is that the app is necessarily a lowest-common-denominator application. The interface is clunky. It doesn't take advantage of high-res screens. And on the Palm, at least, it doesn't auto-type previously-used email addresses--you have to type them each time (or use the awful lookup function). It is, in short, a dinosaur. Worse, it's often a dead or non-syncing dinosaur.
• My low opinion of Notify bottomed-out, however, with the daylight saving debacle this year. Appointments started showing up an hour off for NLES users. NotifyLink posted an unhelpful it's-not-fixable note on their KB, suggesting that users write out the time in the appointment description..I think I actually laughed out loud. Support confirmed this unfixability by phone. I reached out to Scalix support, and later filed a bug report with Scalix. I never heard back regarding the support request. Shortly thereafter, however, I found a fix for the problem. I found a way to extract the "Exchange-only" cdo.dll from a Microsoft patch, and posted the steps with the bug. Florian closed the bug with a notice that the problem was a Notify issue, which it was. When I emailed the solution to Notify, however, I never heard back, and that same, pointless KB note remains there to this day. I even fixed it for them and they couldn't get their act together sufficiently to pass the fix on to their other customers.
• Oh yes, and they don't actually seem to announce any of their patches or upgrades. I've only ever received emails about upgrades for client hardware that we've never used. I just get to be surprised every once in a while when I check their site.
• Notify's problems shouldn't be Scalix's problems, but when they're the only game in town, and so many execs and decision makers blithely assume that it's "Scalix for my Treo," Notify's failures and problems get unfairly attributed as Scalix's failings.

Okay, Scalix users, feel free to agree or disagree, but please do speak up.

--Aaron Hathaway

Well, Notify has been a trusted partner of ours for more than 2 years now and we started working with them when we were really small and unknown; at this point there are certainly no plans to ditch them. Obviously every product has some concerns about it, but I also know a couple of customers who are happy with Notify's offering, given their decent Blackberry support (a device that almost no other vendors besides RIM themselves properly supports) and their multi-backend, multi-client (Wireless clients of choice) offerings.

I firmly believe that there is no one-size-fits-all solution in Wireless space, however, each solution comes with it's unique set of opportunities and challenges and one needs to be diligent enough to do the right thing at the right time.

As a firm believer in Open Source and Open Standard I absolutely support to make SyncML (possibly through Funambol) happen. This was one of the projects that was somehow delayed, postponed and got into some issues through the Scalix 11 launch and the current acquisition situation. We're currently looking into how to get that traction back on the ground and will see what we can do here. The connector currently needs to be tested, documented, integrated and possibly updated to cover the latest Funambol release and we'll see how we can fit this into our release schedule and updated roadmap that we should be able to start talking about pretty soon (in fact, we'll have a meeting on just that end of this month). Other Wireless opportunities and solutions will also emerge and I believe some of Xandros' existing and upcoming partnerships will create wider opportunity here.

I'll stop now. There will be some feedback to this thread, assume it might be controversial, but I firmly believe that a) Scalix is a very viable solution as it is today and many of our customers confirm that to me on an almost daily basis, and b) the recent changes will actually fuel and help drive to move this to the next level.

Cheers,
Florian.

Florian,

You are way too fast for me...and sorry, I didn't mean to monopolize your time in that way!

I should state that I'd very much like to see Scalix succeed, and my sense is that leveraging the resources of Xandros may help make Scalix into what it can and *should* be.

As for documentation and support in the forums, I meant that the support's common resolutions or tricks should be made more readily available. Even as a paying customer, I'd still prefer to fix a problem myself if the tools and solutions are forthcoming, for speed if no other reason. I'd even be okay with some portion of the support forums being restricted to paying customers only (or perhaps only allowing posting rights for paying users). Also, I want to point out that I think the training is excellent too--it was just the written/printed materials that I had trouble with.

As for the non-public bug issue, understood. Too bad there's not an easy way to show that a query matched some restricted bugs, and accordingly, to allow description viewing only--or even just a title.

Paid chat? Absolutely I'd pay. It might also make sense to host Scalix-attended, regular chat meetings once or twice a week, say for an hour or so for the community. Better yet, mini-training webinars about diagnosing certain problems. And/or create a space for users to upload their own "here's-how-I-did-it" films!

For the wireless issue, I'll leave it at this: Choice is obviously a good thing.

Again, Florian, thanks for your thoughtful and exceedingly rapid response (two usually contradictory qualities). I certainly recognize that many of the difficulties for the first half of 2007 were due to a large number of stability issues with the 11 release. In the process, however, it put enormous strain on Scalix's ability to support its customers. I think most of my suggestions are ultimately aimed at distributing Scalix's expertise with its own product more widely, to better defend against those sorts of events in the future.

Regards,
Aaron

This is a great thread - thank you for it!

I would love to see an IRC channel! I think that is an excellent idea and something that would be beneficial to everyone here on the forums.

Whatever we can do to make it possible - lets work towards doing it.

Thank you

Hi,

I would be interested in a Scalix mailing list. I don't always have time to browse a forum, and work don't really like users viewing forums, however, I regularly respond to mailing lists on my work account, and some other users may have this also.

Thanks.
Andrew.

I'll second the absolute disaster that is the multitude of configuration and log files.

I have spent literally more than 50% of my time hunting the right configuration and log files down in my (so far vain) month-long attempt at getting scalix -- outlook connector and webmail included -- to work.

*fume*

redthree wrote:I'll second the absolute disaster that is the multitude of configuration and log files.

I have spent literally more than 50% of my time hunting the right configuration and log files down in my (so far vain) month-long attempt at getting scalix -- outlook connector and webmail included -- to work.

*fume*

my biggest gripe is the documentation. Whenever there is a problem I try the documentation, try the wiki, the google search and usually find it in about 5 posts deep on the community forum.

even the online help with each binary is inadequate. There isn't generally any examples of the particular thing I am trying to do. (please don't ask me for an example right now :-) everything's working)

Unfortunately there are so many binaries you need to execute to do relatively easy tasks that a quick cheat sheet would be really handy.

Most of the commands are logically structured, so that if you know what you want to do, you can easily find the command.

1) Most commands start with om (sx for newer add-ons)
2) What do you want to achieve (modify, add, delete)
3) What do you want to do it with (user, pdl)

Then put the above together. To add a user, you use omaddu (om - add - user), to modify a user you use ommodu, to delete a user you use omdelu.

The arguments are likewise structured (-o for old user details, -n for single/new user details, -m for mailnode, etc)

Sometimes a list is used where you may expect a show, but otherwise I've found the above as a good starting point to figuring out the command I need.

Have a look at the man page for scalix-server, it lists all the commands and the type of function they apply to.