Why does the Domino community have a "Domino or nothing" mentaility?

January 31 2012

The above thought has been on my mind since the middle of December but I have not figured out how to blog about it until recently. Let's start with a public comment from Ed Brill's blog:

14  Erik Brooks  | 1/26/2012 11:46:38 AM

@Ed - I actually *did* know. I'd still like to hear the reasons why this direction was chosen, because it's eyebrow-raising.

My apologies to Erik (didn't go out of my way to call you out Mr. Brooks, your comment was just the easiest one to find) but this is exactly what I mean when I ask 'Why does the Domino community have a "Domino or nothing" mentality?

First off, I get why people love Domino so much. Hell, I am one of those people. It's easy to install, easy to administer, and in basic use is easy to maintain. You can ramp Domino up to enterprise levels with clustering and lots of other great features. You can turn on DAOS and get incredible results of disk saving. You can install Traveler, which folks like Andrew Pollack call one of the best Domino feature ever. "It just works" is a saying that makes us all proud because it invokes thoughts of other amazing technology.

But for everyone of those features above, I read about how we want to pick it apart. When DAOS was first announced, people wanted to know how to use the C API to get access to the attachments on disk. The statement of 'you don't need to worry about the attachments, we just abstract it and it looks like ODS and NSF to you' was pushed for more info. The fact that Traveler is using the Apache Derby database (what Erik is referencing above) to provide a killer solution makes us all cringe and want to know what the conspiracy is. Yes, we all want a clustered version of Traveler, but should we really care how they do it?

I compare this to the other technology teams at PSC. Our Microsoft team covers SharePoint and .NET development. Of course, they are strong proponents of Microsoft technology, but when they get a new version of Microsoft tech, they really don't worry about if this version changes the tech underneath unless it effects our customer and their projects. Our enterprise team is even more flexible. Move from PHP to Python? Sure. Be flexible in JavaScript toolkits from sencha to jquery to dojo? Why not. Even our mobile developers move from iOS to Android to Windows Phone OS with very little issue or comment.

I remember the comments at Meet the Developers this year at Lotusphere 2012 where Domino was used as the standard that WebSphere installation and administration should strive to achieve. I get that. I agree. But I think that the Domino community can also be far more open minded to letting IBM use technology to extend the Domino product line as long as it within the awesome model we have today. Embracing new technology is not a bad thing. WebSphere is not a bad thing. Having some great technology like Apache Derby used in Domino to make a kick ass product like Traveler should be embraced and encouraged and should not lead to eyebrow-raising.

8 Responses to “Why does the Domino community have a "Domino or nothing" mentaility?”

  1. 1) Flemming Riis says:

    Its not a domino thing its a state of mind going across all platforms no matter what brand.

    dedication is fine, but at some point it just gets to risky , betting your skills / job / business on a horse you have no control over is not very sane.

    If vendor kills / changes producy xyz you have lost , if you are that dedicated to one product or vendor you need to go work there instead.

  2. 2) David Hablewitz says:

    Perhaps after having spent so much time defending Domino against other technologies intended to supplant it, it has become a defensive reflex? It becomes difficult to distinguish friend from foe. "The doors of the mind cannot be open to change if it is under attack."

    Personally, I think the diversity is an advantage. It is harder to dismiss a suite of software than a single product.

    But don't laud your MS team too much. They are accustomed to the pain of having to install all kinds of modules, add-ons, plugins and apps to do what the Lotus team does in one place.

  3. 3) Henning Heinz says:

    Many modern platforms are database agnostic. In some you can even switch from SQL to NoSQL and vice versa without much code change. With Domino this seem to be different. If Domino can't handle what a free Open Source low footprint Java SQL engine can (where the compiled jar file is less than 1MB last time I looked) then isn't it fair to ask why!?

    I can understand that Domino won't scale to DB/2 or Oracle or even MS SQL Server but DERBY !?

    Maybe the use case isn't well suited for a NoSQL database. I would have bought this until I saw a MongoDb instance in action last week at a LUG (with the L for Linux). The db had one million records and (it was the 64Bit version) and performed amazingly well. And the queries looked quite similar to SQL. Maybe there are many points where nsf beats MongoDb. I don't know.

    Probably Traveler started with a SQL backend and IBM hasn't changed it just because it worked. Again accepted but now that clustering is required I can hardly understand why nsf isn't good enough. Maybe it would help if nsf had a generic jdbc interface.

    It is how it is. I have no problems with using Derby for Traveler. But although I might repeat myself. If you can't use Domino to handle Domino data then don't be surprised if you customers won't either.

    No big problem for PSC. If I understand correctly you have experts in all areas.

  4. 4) Nathan T. Freeman says:

    I'm really kind of amazed this has to be spelled out...

    Because building the solution on non-Domino 1) increases TCO for the customer; and 2) means that infrastructural and testing resources at IBM are further fragmented.

    Item 1 means customer interest is reduced (unless it's expensive enough to get the "strategic" label, and then the conversation can elevate to the top.) Item 2 means that IBM reliable rate of innovation is slower.

    If Traveler had used NSF for storage, the clustering support would have taken 15 minutes and probably could be implemented entirely by partners and customers. But because it uses Derby, it now takes an unknown amount of time and will be a major version release and probably take an additional two points releases to stabilize.

  5. 5) Erik Brooks says:

    Sounds like everybody here has echoed my thoughts.

    Customer TCO will go up, reliability goes down, and it is likely more expensive for IBM to maintain.

    My first impression is that it's a really bone-headed move on IBM's part. But there may be a very good technical reason for it, hence why I asked. We'll see what IBM says (if anything.)

  6. 6) Darren Duke says:

    I think John's question is a tad overly incendiary (and that is coming from me!). I also think the question is backwards....

    Why does IBM have an "Anything BUT Domino mentality?"

    I'm all for saying Domino is not good for everything, but if the NSF is not up to being the back-end of Traveler, then fix the fricken issue in the NSF for the benefit of all (and maybe even add some mongo style query language). But no, IBM immediately jump to something even more esoteric than even Domino because this is probable a lab research project and all they know is Java and RDBMS (this is complete conjecture on my part by the way). And don't me started on backup strategies for Derby.....

    In the land of unintended consequences IBM get bitten trying to provide HA and failover on a platform where to enable HA on Domino it is nothing more than a picklist to set up. Trees apparently do a good job of hiding woods.

  7. 7) Chris Whisonant says:

    I will be the first to use the technology that is necessary. LAMP, Domino, DB2, WAS, etc... Just so everyone knows I'm not trying to be an NSF bigot here. :)

    So Derby was chosen initially, OK. I believe it's what the backend was when Traveler was ported from the old Workplace product. It works ok. But the long-term strategy from IBM for Traveler HA is to get rid of the Derby backend and require DB2 as the backend for HA. This is because Domino NSF clustering will not be up to the task of ensuring that the state database is atomically in sync due to ActiveSync. If an ActiveSync device hits a version of the db (i.e. on a Domino clustermate) that is even milliseconds different from the last sync time, then a full re-sync is done. I have a good many thoughts on this, but mostly that this isn't going to be beneficial for SMB. Especially if you want to have HA for that DB2 server.

  8. 8) Brendan Long says:

    I'm all for using the right tool for the job, but there is also an element of IBM not being prepared to eat their own cooking, so to speak.

    As a lazy geek who doesn't put enough time into researching alternative technologies, it was always comforting to know that IBM thought enough of their platform to build things like quickr, sametime etc on that platform. Now, I'm left with the nagging suspicion that the hours I'm currently putting into improving my xpages knowledge might be wasted on something that smarter, better, more knowledgeable developers at IBM wouldn't touch with a barge pole.

    The community shouldn't have a "Domino or nothing" mentality, but it would be comforting if IBM didn't seem to have an "Anything but Domino" mentality, as Darren puts it.

    That said, if Traveler (which is great), or any other IBM product for that matter, is as easy to install and administer as Domino and I never have to look under the covers at the underlying technology, I'll forgive them and I'll be happy to stay blissfully ignorant of things like Derby.

Leave a Reply