Ed Brill

Post a Comment

1. 1  Charles Robinson http://cubert-codepoet.blogspot.com | 10/31/2006 10:25:18 AM

   I'm going to get back on my soapbox here, Ed. You keep saying that the majority of Notes sales are to the SMB segment but here you reference "large Notes customers". Do you understand (yet) why some of us think IBM's focus is on the bigger fish? </rant>

   Now that I have that off my chest... How on Earth would I know what cool new features didn't make it into a release since (as far as I know) there is no public discussion of what features are being considered? Maybe that's directed toward the BP/consulting crowd and more discussion happens in the private BP forums.

   Anyway, I don't delay updates waiting for a specific feature. If I did I'd still be on 5.0 waiting for a supported formula debugger. ;-) I read the release notes, install it, see what new features it has that aren't listed in the release notes, and decide whether it's worth my while to upgrade. We maintain a Passport Advantage contract (that I have to defend) so it's not a matter of cost, and our corporate policy is to just give users new software without training (not my decision), so it's an issue of time to roll out and how much time I'll spend on the phone explaining the new features individually to 150 - 200 people.

   One thing that would make my life easier is more comprehensive coverage of new features in the release notes, a specific section for regressions that were fixed, and better attention to detail on getting the help updated to match the new features. Generally I would say to stay the course, just provide more/better/consistent documentation so we have a better idea of what is being offered.

1. 2  Felix Binsack http://www.timetoact.de | 10/31/2006 11:03:08 AM

   Consistency in optimization (performance tuning, bugfixing, standards adoption)is of great value to the installed base. Sometimes even more than new features. Lotus has been doing a good job here, but as always, there is room for improvement (32k Limits, XHTML Support, HTML Rendering, GZip Compression, RTF / MIME Handling, SMTP Conversion, Servlet Support etc.)

1. 3  Nathan T. Freeman http://www.openntf.org/nathan/escape.nsf | 10/31/2006 11:21:03 AM

   Please keep shipping features as fast as you can, no matter what the version. What you need to do is just highlight the new features better in the UI. Maybe a running list of version numbers, and when you expand each one, you show a list of what's new in that version. That's a LITTLE like the release notes, but I'm thinking here of something on the Welcome Page. Then allow policy control over displaying such a list.

   I suggested to Alan the other day that his blog should have a sidebar with a "last 12 months" list of Lotus features/products that have shipped in the last year. I think that would send a really powerful message of "this is what we're delivering constantly." I mean, should we have waited for 7.1 for Nomad or the SAP integration? Of course not. Should the version have been named 7.1 because those things were included? Maybe, but they were template and installation script updates, which aren't core code updates, which means they should be considered low-test maintenance releases.

   It's a pickle. And you're right about the Web 2.0 models not really caring. Even releasing a Notes-client platform in South Africa, we'd have stretches where I would literally ship a maintenace update EVERYDAY because we did it via replication. If you learn to make that part of your development culture (as places like gmail often do) it's a lot easier.

1. 4  John Head http://www.johndavidhead.com | 10/31/2006 11:27:21 AM

   @3 Nathan - the moment you call something 7.1 vs 7.0.2, you change the ball game ... many customers who are willing to move to a MR will not move to a point release. It also changes the testing requirements and all that. I have no problem with MRs having features.

   The different audiences will also take a new version or MR differently. The SMB world will upgrade to a new release of a product faster than a large enterprise.

   The benefits of most Web 2.0 applications is that the entire software core is some place they control, vs a product like Notes and Office that is installed on desktops and laptops. They upgrade the source once, and everyone gets it. Too bad those products can not touch the features I get in Office or Notes :)

1. 5  Henry Ferlauto http://www.geniusinside.com | 10/31/2006 11:36:36 AM

   As suggested in @3, Lotus needs to make better use of their version numbers.

   More attention needs to be placed to the "tenths" decimal place in the version number. Lotus has historically buried everything in maintenance releases.

   R5 is the best example. I think it got all the way to r5.0.14 before it was retired. At some point there was probably enough enhancement to warrant a "5.1" (r5.1.0) or a "5.5" (r5.5.0) release?

   The "little" enhancements need to be better grouped and released en masse. This way IBM/Lotus marketing get to the opportunity write press releases a little more often.

1. 6  Axel Janssen  | 10/31/2006 11:46:27 AM

   user base which upgrades slowly is a sign of

   - users lack skills or confidence. They fear to not being able help themselves in case of errors start popping up.

   - software is very complex

   - software is used for mission critical tasks, so temporary outage is costly.

   - though testing procedures of the vendor clearly are supernatural, they could be made even more supernatural.

   In RL its allways a mix of all those factors.

1. 7  Axel Janssen  | 10/31/2006 11:51:19 AM

   With update sites in Eclipse, Java Webstart, Netbeans you have a Web2.0 like upgrade mechanism as the code of the new version comes over http. I guess that there is a similar deployment mechanism with desktop clients in .NET.

1. 8  Villi Helgason  | 10/31/2006 12:01:34 PM

   I read somewhere that Hollywood sequels, with a name, instead of a number, are viewed more positively by the public.

   Version numbers are for IT people and should be hidden from the customer. Call it "Domino: Hannover", "Domino: Collaboration", "Notes 2" or "Domino does Dallas" :) Just drop the version number (except for IT people to keep track of what codebase is deployed).

1. 9  Stuart McIntyre http://macsfacts.vox.com | 10/31/2006 12:10:14 PM

   @8: I hope your tongue was firmly in cheek!

   I'm with the regular small updates, but with better documentation please.

1. 10  Wild Bill http://www.billbuchan.com | 10/31/2006 12:33:11 PM

   What I see when I visit customers is a huge reluctance to upgrade the desktop client itself. This is (correctly) perceived as a HUGE task. For instance, even the smartupgrade stuff only just added a "Run As" feature for locked down PC's - and locked down PC's is the norm in the environments I tend to work in.

   Secondly, Notes is perceived as something that just keeps running. Customers who are on passport always seem to find things that are more urgent, and push the notes upgrades further and further back. For instance, I know of a 10k user bank who are JUST in the process of moving from R5 clients to R7 clients. Why ? They tried to incorporate the upgrade into a windows XP SP2 upgrade also, and because that had "issues", delayed things by a year or so.

   How to make the client easier to ugprade ? In a no-touch, centralised manner ? I know there are excellent tools - such as Wolcotts ADT - but getting customers to even consider third party addins is *hard*. (I know, I try and sell one myself!)

   I sincerely hope that one of the design goals for Hannover in this respect is some form of easy client upgrade path - perhaps using smartupgrade or some other executable tool that could be sent out as a mail message. (

   I'm not suggesting sending out hundreds of megabytes of installer via Mail (now that would be *insane*) - just some form of "stub" code that *could* perform the ugprade of a notes client from any version to any version. Sort of a stub-version disconnected (separate executable file) version of smartupgrade ?

   Its a thought I guess, and one that the major Notes customers must already be discussing with yourselves.

   Solve this and I suspect the client base will keep itself far far more up to date.

   ---* Bill

1. 11  Keith Brooks http://www.kbmsg.blogspot.com/ | 10/31/2006 12:39:15 PM

   For sure the .x or .xx releases have been inconsistent.

   Nathan has the right thought about a 12 month rolling "What's new" bar.

   Most times people will move to the latest(after testing) to install. The problem is if my network and environment is stable, why upgrade?

   If the templates were available seperately or defined by a point release .x then core code could be updated in a point xx release.

   Some of us just want the new templates to fix quirks and try new things(like the blog template) but don't want to install everything just for that one piece.

   Maybe this makes it more detailed or difficult not sure but I have always tried to update based on core code or templates/additions depending on situation.

1. 12  Giuseppe Grasso http://www.dominopoint.it | 10/31/2006 12:45:29 PM

   I agree in full with @2: release often and always optimize, smaller touches in UI (as in 7.0.2) are welcome.

   I always test on the lab before upgrades, but we apply sub-releases as fast as we can if we see even smaller benefits, downward compatibility is also of great value and... please please please: keep version numbers, i don't want make vowe rich selling t-shirts like this: { Link }

1. 13  Gregg Eldred http://www.ns-tech.com/blog/geldred.nsf | 10/31/2006 12:48:44 PM

   With Passport Advantage, I would hope that the customers realize that there is value there - Lotus WILL ship upgrades during the year. Echoing Bill (@10), with a lot of customers locking down the workstations from their users, upgrading the clients becomes more of an issue than the server. That part, alone, now takes more of my time as I work with SmartUpgrade, SMS, or any number of other tools and Network Administrators.

1. 14  Ben Rose http://None | 10/31/2006 1:03:01 PM

   I personally this is was all a bit clearer way back when where we had numbers of letters.

   4.6 was a new version with new features.

   4.6a was a fix pack for 4.6

   4.6.1 added some stuff to 4.6

   4.6.1a fixed some stuff.

   4.6.1b fixed some more stuff.

   4.6.1c broke the indexer.

   etc. etc.

   We implemented a b c to fix problems we may have, nothing was added.

   We implemented 1,2 3 to add functionality we wanted.

   I know we still have FP1 etc, but it's just not as clear any more.

   Food for thought - Do client and server versions need to be in line and the same number. Shipping fixes for the server or features for the client independently could make life easier for development at times...maybe.

1. 15  Flemming Riis  | 10/31/2006 1:19:31 PM

   @10

   making a group policy and a proper msi file will go a long way

1. 16  Ken Yee http://www.keysolutions.com/blogs/kenyee.nsf | 10/31/2006 4:21:53 PM

   I'd echo the sentiment about listing non-trivial changes between versions.

   E.g.:

   7.02:

   - added blog template

   - added TNEF support

   etc.

   What would be even more clever is to have the Notes client contact some sort of "status" site that lists the number of bugs logged against each of these features so we know how stable the new feature (add a graphical temp from green to yellow to red to show how flaky it is) is so we don't have to do the "wait until next version to roll out, but play with it in the first release" rule ;-)

1. 17  Bob Congdon http://www.bobcongdon.net/blog | 10/31/2006 5:09:09 PM

   @14: Releasing client and servers on separate schedules was tried at least once and didn't work. Remember R4.7? No? That's because it never shipped. 4.6 was originally going to be a short-term client-only release, a competitive response to Outlook. No server changes. 4.7 would be a server refresh. Eventually the two were merged together as their schedules overlapped and it became clear that 4.6 would need server changes. That's not to say that you could never have a client-only release, but given that there's a tremendous amount of code overlap, it would have to be nearly all cosmetic.

1. 18  Richard Schwartz http://www.rhs.com/poweroftheschwartz | 10/31/2006 7:10:30 PM

   IMHO, the major issue in recent years (since R4) is that IBM has mis-used the middle digit. IBM has not used it, actually, except for 6.5 -- and that was a mis-use.

   Architectural changes, major re-writes of significant code, ODS changes, etc., are the stuff of changing the first digit. IBM has done a pretty good job of staying consistent on that. Hannover clearly deserves it.

   There seem to be three reasons, historically, why IBM has used the middle digit: added features, added/changed platform support, and extended support lifecycle. Sometimes it has just been one of the three, but usually (lately) it is two or three of them combining to justify using that middle digit. It may be the case that the extended support lifecycle is just a side-effect of the fact that IBM recognizes that new features or platforms justify it, but I think it is a a big one for customer, not to be underestimated in importance. 6.5 support goes beyond the end of life for 6.0x. Will 7.0.2 do that for 7.x customers? If not, does that explain why the Mac support will be 7.0.2 rather than following the pattern that added platform support should make it 7.1?

   (In the R3 days, by the way, the Mac client was -- if I remember correctly -- 3.0b; but most of the other added platforms in the R3 series were in .1, .2, or .3. I think NT might have been 3.15, but that's really stretching the neurons past capacity.)

   Anyhow, IBM should use the middle digit more often.

1. 19  Ian Randall http://www.emsoft.com.au | 10/31/2006 7:13:08 PM

   I don't think that there is any problem with the current method that Lotus us employing with product releases or numbering.

   However, many of my largest customers are waiting years between releases and its not uncommon for some of them to have jumped directly from Notes R5 to R7. Sometimes the only thing that forces their hand is when Lotus discontinues support for the old release.

   Lotus Notes is used by a broad range of customers varying in size from huge multi-national implementations to SMEs with a handfull of users. Some regardless of size update regularly and others are painfully slow.

   So Lotus is stuck with introducing new features as quickly as possible for the fast implementers, holding back some features to give each major releases some additional impact and rushing other features out due to competitive pressure.

   Many large sites also seem chug along with multiple Domino versions on different servers for many years without major headaches.

   I have even seen some end users continuing to use their R5 Mail template on an R7 server and client imstallation, go figure!

   The amazing strength of Lotus Notes and the effort that Lotus make on backward and mixed version compatibility is that it all seems to work.

1. 20  Andy Dempster http://www.cbrands.eu.com | 11/1/2006 5:44:49 AM

   As an ex-BP we continued with 4.6 long after R5 came out. As a developer I don't care when you release stuff, just as long as it works. 6.5.5 being my main issue at the moment and the error that crept in that means I am unable to recompile my database if it has a script library (which means all of them). The cycle of fixing some issues and breaking existing functions HAS to STOP! Separate the Domino Server and the Notes client, make the marketing difference count and give us a stable platform to evangelise about. That is the biggest inconsistency.

1. 21  Keith Brooks http://www.kbmsg.blogspot.com/ | 11/1/2006 9:30:19 AM

   @18, I thought IBM did use the middle digit enough :-)

   or is that just when they consider smb's to be under 5,000 users.

1. 22  Charles Robinson http://cubert-codepoet.blogspot.com | 11/1/2006 9:40:29 AM

   @20 - I agree that the regressions are getting ridiculous. I'd love to see something in the release notes that specifically lists regressions that were corrected in the release. Even better would be an entry in Notes.Net when a regression is discovered. I can understand that Lotus might not like calling attention to them, but from where I sit it sure would be awesome to not have to dig through the SPR database -- which doesn't flag regressions at all, you have to read the descriptions to figure that out.

   @21 - Good one. :-D

1. 23  Bob Brodsky  | 11/1/2006 11:17:06 AM

   @18 I completely agree...and that is scary

   Why try to hide new stuff and kidd ourselves/our employers

   -----------------------------------------------------------

   First digit-changes to core code

   Second digit-any new stuff with same core code

   Third digit-fixing things that are broken

   For shops that will only implement fixes and not upgrades it is clearer. For shops that have varying implementation/testing procedures for fixes and upgrades it is clearer. For shops that always run on the latest thing it is clearer.

   If IBM wants to have more than a one digit increment in the second digit for "Lots of New Stuff" (eg 4.5,6.5) it is clearer.

   Save any further digits for "Hot Fixes" not normal maintenance releases.

   Keep server and client code in synch for all the above reasons as well as it is just easier to understand.

   HTH,

   Bob

1. 24  Nathan T. Freeman http://www.openntf.org/nathan/escape.nsf | 11/1/2006 10:44:35 PM

   @23 - Only problem is that the second-digit (meaning no changes to CORE codes) is still considered something that has to be subjected to upgrade testing by customers. Look back up at 4) - if it had been 7.1, which would make more SENSE as a version number with the additional features, you'd have every customer with more than 1000 clients planning 6 months of testing to rollout something that was almost nothing but template and installer changes. By calling it 7.0.2, it actually GETS ROLLED OUT to 7.x shops.

   The problem is that IBM's QE is generally too good. (Andy's & Charles' respectable concerns notwithstanding.) Customers can't deal with trusting it. Witness the reaction on this blog to one administrator bragging about upgrading his systems to 7.0.2 in 15 minutes: "WHAT NO TESTING!??!?!?! IDIOT!" Right... I guess these guys would run an .NTF update and a .MSI change through a 12-step verification sequence. (Yes, I picked that number on purpose.)

1. 25  Charles Robinson http://cubert-codepoet.blogspot.com | 11/2/2006 10:07:51 AM

   @24 - If I'm the Charles you're referring to, I'm not sure what concerns you're referring to. Is it the problems I had with incremental installers?

1. 26  Nathan T. Freeman http://www.openntf.org/nathan/escape.nsf | 11/2/2006 2:57:19 PM

   @25 - Yes. Your comment about regressions. Nobody likes regression bugs, of course, but I'm absolutely convinced that Notes has a very LOW impact history of regression bugs. People like you and me tend to push the envelope and find those problems more problematic, but I think the market in general uses the product in a way that most of those problems don't really prevent them from rolling out a version.

1. 27  keith brooks http://kbmsg.blogspot.com | 11/2/2006 4:41:41 PM

   Regressions happen. QE has good days and bad days. I know because I sat on the critical situation team for emea. The R5 int'l english problem was a prime example of bad days. But in general its good.

1. 28  Bob Brodsky  | 11/2/2006 8:48:26 PM

   @24 Nathan

   Welcome to Atlanta - hope to see you at a quarterly ALUG meet

   So, you really think we can kid ourselves/employers with version numbering subterfuge? My point is that the numbering scheme shoud be just another thing making Notes/Domino easier to deal with.

   I agree that template changes might not warrent a point release, but look at what happened to pubnames.ntf of all things in 7.0.1: bug introduced in the Group document that was fixed in 7.0.2. That Hide-when bug was not found in our testing and probably not in many others either. I'd say that the TNEF features of 7.0.2 alone do warrent a point release.

   Numbering is not the most importent thing. It's just another thing.

   Bob

1. 29  Lars Olufsen  | 11/3/2006 4:28:07 AM

   Here's another "vote" for the regression bugs.

   The risk of re-introducing errors mean that we need to test things thoroughly before implementing even simple patches.

   Thorough testing means investing time and money, and it is very little benefit the end user gets from patch releases.

   We do them IF, and ONLY IF, we have a definate problem that we HAVE to fix, and that we KNOW is fixed in the later release.

   When that happens, we try to get as far forward as possible, so that we aren't too far behind at any point.

   If IBM could ensure the single code-stream. Remove the risk of regression bugs. Then I'm fairly sure, we'd just do the patches as they come out.

1. 30  Charles Robinson http://cubert-codepoet.blogspot.com | 11/3/2006 11:13:34 AM

   @26 - Okay, I wasn't sure if that comment was in reference to my comments on Ed's posting about Gavin's upgrade process that you mentioned. I found three regression bugs this week so I'm a little hypersensitive to it at the moment. :-P