FORUM PLAN UPDATE: Date revision: This forum will remain open to new posts and responses until December 1, 2018. (After that date, you will still be able to view and search the forum.) Also, we're taking a second look at the best place to host future conversation. For now, keep using this forum, and stay tuned for more news.
RE: Fitness for a particular purpose Nathan T. Freeman 10.Dec.02 10:52 AM a Web browser Notes Client 6.0Linux - RedHat, Linux - SuSE
Yes, but you have to admit that the combined desktop marketshare of all
UNIX combined was much lower than the one of Linux now.
I don't have to admit any such thing. Show me numbers, because I don't think
that's true at ALL on the desktop.
There were a LOT of Solaris machines in the V3 era. Everyone in engineering
used them. HP-UX, AIX and SCO were also pretty broadly deployed in scientific
and academic markets.
And the presence of
Linux on the desktop keeps growing (next year will probably be very important
in this area as every major Linux distributor plans to release a Desktop-only
I have no doubt it's a growth market. But Lotus has been burned before in this
area. And remember that there are as many individual desktops flavors in Linux
as there ever were on other platforms. Gnome, KDE, Enlightenment... there's
not just a "Linux Desktop." That's wishful thinking right now. There are a
MINIMUM of three platforms.
Rich text fields (ok, you can have them on a browser, but they are a joke
compared to Notes' native Rich text field).
I said functionality. You can bold, italicize, underline, do basic tables,
include images, attach, spell-check, link and change font, color and size. You
lose buttons, collapsable sections, highlighting and a few of the more esoteric
I said functionality. You lose client-side encryption. That's it.
Validations with @formulas (you can use them, but you know you won't
the way they work on the web).
I said functionality. There's nothing important I can do with @functions that
can manage even that.
The ability to attach files to a rich text file (the ability to attach
then one file with just one field!!!)
Functionality. I have a reusable attachment handling capability for n
attachments. So does iNotes. This can be done.
In general, creating a web app that is almost as good as a native
Notes app takes quite longer than a Notes version.
I said nothing about development time. I said functionality. It's certainly
the case that it takes more time to build solutions for dumber clients than
smarter ones. But with D6, it's also faster than ever before.
How many KDE laptops are out there?
At least three at my office, I don't know about others.
Let's say there's a hundred thousand offices like yours. (That's *VERY*
generous.) That means the GLOBAL market is 300,000 users. At $30 a license,
can you see that even coming close to paying the development, QA, and marketing
costs associated with a KDE version? If that number grows by a factor of five,
maybe it'll pay to do it.
Nathan, understand our frustration in this area.
I understand it completely. I've been asking Lotus to resolve the
schizophrenia for 5 years now. I understand, too, why it's hard to do. See
OpenNTF.org for my most serious suggestions on how to do it.
On one hand, in the last year
we've had a lot of clients considering leaving Windows, but we've been unable
to take on this market because of the lack of a Notes Client for Linux.
Clients who are serious about leaving Windows should be saving enough money to
pay for conversion of native Notes apps to web apps, in which case the lack of
a client shouldn't matter.
installation of these apps usually involved installing lots of computers with
just Notes installed and using Linux would have lowered costs a lot.
How many machines are we really talking here? The incremental cost of Win2K on
a desktop is, what, $100? That's less than 10% of TCO for those boxes. Are
you SURE it would have been cheaper going with Linux? That's the same logic
that says Outlook is cheaper than Notes, because the license cost is lower.
You have to look deeper than that.
not mention the fact that we would sell Lotus Domino on Linux to all our
clients if it wasn't for the fact that most Domino "add-ons" (Domino.Doc,
Quickplace, Sametime, are not available on Linux).
Here, I agree completely. There is no server add-on product that shouldn't be
available for Linux. If the *server* is on a platform, then the add-ons should
be on that platform, too.
Understand, I want Linux on the desktop to be successful with all my heart.
But Lotus is right that it's not a mature enough market right now.
Do you want to see it be successful? Then the major Linux distributors -- the
ones you talk about above who are doing desktop-only distros next year --
should be courting IBM to do Linux ports by bringing them license commitments.
Where are they? Are they out there? *Those* guys are the ones that should be
pushing it, along with hardware vendors who know that they could snag a bigger
percentage of revenues for themselves on Linux-based desktop sales.
In the last years, it's been the end of the dot.com fever, it's been the
all the migrations and updates for the year 2000, it's been the end of the
migration to the Euro here in Europe. Unless we offer something new to our
clients, they are not interested on spending money on software. Linux is
something, and most of them are interested, if only for the blurb that
surrounds it, but we always step on the lack of a Notes client.
What's the business advantage in that? If that's your offer, it's not the lack
of a Notes client that's holding you back. It's the lack of a meaningful
business value to your proposal. If all you're doing is the *same* think in
Linux that you did in Windows, it'll take you 5 years of ROI to get back the
migration expense in cut license fees. Hardly a good proposition at this point.
We might get a
Notes client, we might not, but you can be sure we won't stop asking for
You can and should keep asking. But if you want to be taken even remotely
seriously, you should be coming with license commitments. Lots of them.
Otherwise it's just blowing smoke.