IBM join OpenOffice.org

El Reg is reporting that IBM have thrown their hat in with the OpenOffice.org development community.

Initially they are contributing some Lotus Notes code. But it sounds like they intend to fully participate in the ongoing effort. Maybe some 123 stuff will find its way into Calc. How positive you see this move will, I guess, depend on your view of IBM/Lotus products. I’ve used Notes recently and I am not a great fan. Its a long time since I used 123 though so I have no idea how good or bad that is. Do you?

I think I’m right in saying one key missing component of OO is an email client/calendar thing, this move may plug that gap.

I find it rather surprising that in many areas the only credible alternatives to Microsoft are free/open source projects.

  • Would you agree with that?
  • Why is that the case? or not?

The key point for me is the business potential, and with more and more household names backing OO that looks better and better. Jobserve however always seems quiet on the OO front.

It really seems like OO is developing some momentum so it will be interesting to see how things pan out over the next few years. I suspect the increased competition will bring out the best in MS so maybe Office 14 will be a ‘must have’ version.

cheers

Simon

Advertisements

5 Responses to “IBM join OpenOffice.org”

  1. Harlan Grove Says:

    Few people have much say whether they use Notes or not. If you work for a company with a Notes infrastructure, you use Notes, like it or not. But it’s not bad, and Notes and SmartSuite applications provided very tightly coupled functionality a decade ago, e.g., 123 workbooks could be embedded into Notes forms in such a way that the 123 workbook effectively became the Notes form. And certain named ranges in embedded workbooks would be form-level fields, so accessible through queries via NotesSQL. I may be missing some details (or be completely wrong), but my impression is that MSFT is just catching up to this with SharePoint.

    As for building some 123-like functionality into OOo Calc, it’d be nice to have 123’s 3D @INDEX (i.e., 4th arg to INDEX being the worksheet index into 3D ranges, but that may require a separate function if OOo Calc supports Excel-like multiple area ranges). 123’s @XINDEX (using labels as row and column indices into top row and leftmost column) would also be nice. But nicest of all would be 123’s database functionality/@D functions, which have been, are, and very likely will continue to be MILES ahead of Excel’s 123 Release 2 (mid 1980s) equivalent functionality. E.g., 123 from at least Release 5 (mid 1990s) provided a way of defining names that referred to external database tables (or objects that could be treated like tables), so it was possible to write @VLOOKUP formulas using such external tables as 2nd arg; and 123’s @D functions, e.g., @DSUM, can use criteria EXPRESSIONS as 3rd args rather than range references, AND it was possible to join different tables in 123 @D function calls.

    Excel’s SQL.REQUEST add-in function provide comparable (if not greater) functionality, but wither SQL.REQUEST which wasn’t included with Excel 2003 and presumably not with Excel 2007?

    MSFT may provide decent, possibly better, tools at VBA or XLL/DLL add-in level for Excel, but they’ve never come close to providing 123’s database query functionality in worksheets. If IBM adds this to Excel, and they expand the OOo Calc grid by doubling the number of columns and rows, they just might make OOo Calc a very serious competitor to Excel. It’d certainly be far more attractive on a price/performance basis.

  2. Harlan Grove Says:

    Oops! Make that ‘If IBM adds this to OOo Calc . . .’

  3. Biggus Dickus Says:

    harlan:

    “and 123’s @D functions, e.g., @DSUM, can use criteria EXPRESSIONS as 3rd args rather than range references, AND it was possible to join different tables in 123 @D function calls.”

    And the @D’s were actually FAST and useful.

    I frankly believe that 1-2-3’s 3D model was more robust that Excel’s in many ways (formula creation, etc.) BUT the advantages of separate Print ranges for each Worksheet, the availability of Page-Specific Names (thus allowing multiple instances of the same name in a Spreadsheet), and generally being able to consider a Worksheet as if it was a separate file within a file while STILL allowing 3D formulae when necessary makes me more a fan of Excel’s 3D on balance than 1-2-3’s.

    I agree that later versions of 1-2-3 DID have an interesting Databse story happening. Although Excel is getting better at Databases it doesn’t really integrate external Database data as seemlessly as I’d like to this day. Maybe next time ;-)

    Dick

  4. Marcus Says:

    And then there’s the simple things…
    – Having the currency formatter one click away (pop-up at bottom left
    of the status bar).
    – Being able to synchronise worksheets (positions)
    – Being able to ‘unselect’ cells in a range while you’ve got you’re CTRL
    key down.
    – Being able to copy a range (via dragging) horizontally and vertically
    in one move. In Excel you first copy down and then copy across in
    two separate movements.
    – I also found (and it could just be me) than LotusScript executed faster
    in 1-2-3 than VBA in Excel.

    Cheers – Marcus

  5. Harlan Grove Says:

    I’m hoping IBM would be ADDING to OOo Calc rather than making it more like 123. As in 123’s 3D functionality (3D references ARE ranges), and OOo Calc already provides relative and absolute WORKSHEET addressing, so the formula =Sheet1.A2+A1 in Sheet2.A2 copied and pasted into Sheet3.A2 would become =Sheet2.A2+A1, while the original formula =$Sheet1.A2+A1 pasted into Sheet3 would have remained the same). So the ideal would be worksheet-level as well as workbook-level defined names, 3D *ranges* rather than just (nebulous) references, and relative and absolute worksheet portions of any references that include worksheet.

    As for LotusScript, I used it as little as possible. The LotusScript Editor IDE stunk, the debugging facilities were nowhere near as useful as the VBE’s. And 123’s object model really, Really, REALLY stunk! Example: 123’s OM provided no equivalent of Excel’s Application.EnableEvents = False, but 123’s OM did provide Calculate event handlers. While it was possible to disable Open (or ) macros/event handlers in 123, it wasn’t possible to disable the other event handlers, so all a virus writer would have needed was a single cell containing the formula @NOW or @RAND and they’d trigger recalc as soon as a workbook finished opening, and at that point NOTHING could prevent 123 from running malicious Calculate event handler code. In this regard, it’s a good thing Lotus SmartSuite 97 and subsequent were market failures.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: