OK, probably time to wrap up.
1. For us, it's about minimum order size and complexity. Minimum order matters because there is a certain per-customer overhead that can't be avoided. In the EU, e.g., we are required to provide some level of support/warranty with an initial purchase. Even if we limit this to 1 incident, this has cost associated with it, so on a, say, 100 EUR product, given the relative complexity of even that ONE support question, we'd be losing money. That's the this post will be deleted truth. Can't do. We could probably go somewhat lower than SBE-20 is today, but there is a limit. The accounting and transaction cost is also not purely virtual. Furthermore, if you open the door to purchases very small and very flexible (say: by-user!), in a mail server solution you end up having to offer the same for additional users, only that then transaction sizes would get even smaller. In the SBE range, we'd talk about selling a single add-on user for, say, 20 or 30 dollar or Euro. That doesn't fly. And, unlike a larger software vendor like Microsoft, we don't have a huge set of products to cross-subsidize to draw from. I am pretty certain that they lose money on some products, in the bigger picture of things they can afford this much easier than we do.
2. The channel (resellers, distributors) is important to us, in different ways in different markets. The main reason is that many Scalix implementations, even relatively small ones, have deployment scenarios associated with them, espeically when it comes to migrations and integrations. We rely on VARs to provide such services. Once one is committed to do just that, one needs to stick with such a model (it's really an either-or decision, per market), as otherwise you'd be basically eating the icing of their cake by taking all the very easy business yourself and only giving the complex "brick" projects to these folks. That's called "The Channel Conflict" and every vendor has to face that decision. We decided to be a good player with the channel, at least for most markets, and fundamentally only selling through them with very, very few exceptions is the logical consequence of that. That alone, however, doesn't make new and smaller products impossible per-se, it's just something that needs to be put into consideration.
Sure, but still they'd have to pay the same as a 20-User company (or even 60-User company if standard users play a role).
Charging the same for a 3-User company than for a 60-User company just doesn't seem fair to me.
Fairness is a very relative concept. A 3 user company, for Scalix SBE, would, based on SBE-20 and the minimum pack of 5 ActiveSync CALs, no AntiSpam/AntiVirus, pay about $130 per user per year for Scalix over a 3 year period, assuming they are using a no-cost operating system like CentOS. While this sounds like "a big number" initially, given the same people would pay their carrier about $600 per year for their iPhone subscriptions, I'd think that this cost created through the use of Scalix is very reasonable compared to what you get, with all our features. And if your company grows and you add a 4th and 5th employee, your carrier-side cost goes up linearly while your Scalix cost stays the same, up until when you hit the 20-user point. I think that's very, very fair play, actually. And it seems that we make it easier for companies to decide for hiring people, so we're good for the labour market as well.
Then again I don't know anyone offering hosted Scalix and your Website (especially the german one which has been down for a long time now) doesn't really help me find one, at least not at first glance
Please get in touch with our sales team if you need a hosted offering; we'll put you in touch with one of our resellers or hosters that provided hosted Scalix services.
Sure, that may be competitive with Microsoft SBS - but your main competitor in this space is not Microsoft but non-consumption and workaround things like Syncing.NET.
With all respect, not true. I've been in this market for more than five years now, and with the exception of the odd Linux-based competitor that shows up at times, and now sometimes Google Apps, people typically decide between us and Exchange, simply because of the functionality footprint and Outlook support. Built-in ActiveSync support and some further announcements we're going to make over the next couple months will actually further support this situation.
And to come back to your supermarket example: Here is another (silly but true) supermarket example: I don't buy butter because I only seldom use it and if I buy one package at least two thirds of it will go bad before I need it. This sucks, both for me (I have no butter even though I want it once in a while) and for the butter industry (they sell less butter even though I would like one).
Well, it's a cost/benefit calculation and one of diminishing returns for the butter industry; I'm fairly certain that they've optimized their packaging. I noticed that you live in Germany, like me; we've also seen smaller packagings coming up than the traditional 250g (1 German pound) brick. Now, to solve this one, here's a learning from my late Grandmother: Butter doesn't really go bad just because it looks a bit yellowish. It lasts a couple months longer than you think. And if you really want to avoid any remains of "bad" taste (for most applications I personally don't care
), just cut off a bit at the edges - it doesn't go through, there is nothing poisonous about it and you'll be fine.
Problem solved. The Scalix Forums Butter Thread. That's a first.
Since it uses statistical patters Commtouch will not be able to make a yes/no decision and does not prevent a single spam message this way! It only pre-sorts them, but due to the possibility of false-positives you have to look at the spam anyway to check for false-positives!
Well have you tried it? Here's my result after a year of experience (and I receive about 50K Email messages against my account every year).
- 2 spam levels, confirmed spam, likely spam
- we don't deliver "confirmed spam" to our users; we have, for a year now, kept them and not rejected them, for analysis. Not a single false positive in those. We'll stop the keeping and switch to rejecting.
- we do tag and deliver "likely spam" to our users; they sort them with rules. For me: about 10 false positives in a year in that category, and all of them were "mass emails", i.e. stuff coming semi-unsolicited from people sending (legal) advertisement because they had acquired my email address from some legal source. No single false positive in personal messages.
- about 50 false negatives (not recognized as either) for me over a whole year.
- no training, no white/blacklisting, zero (and I mean zero) admin for our over 200 users. none.
I must say... I've used many solutions for AntiSpam, but on balance it couldn't get much better than that, for me and for us as a company. Not trying to sell this here, I know there are other solutions out there that work as well, but I am very, very happy with it.
Florian.
I second that... 