[OGo-Discuss] Re: Some impressions and comments about OGo

[Mark Pavlichuk]

> VALID - 
> (1) The OGo packaging is rough and some packages don't enforce their own
> prerequisites / dependencies.<snip>

  Suggested fixes for the Debian packaging :

1)  In Debian Etch the Apache and Postgres virtual packages will install
legacy versions by default (to enable graceful upgrade from Debian Woody)
unless the current Apache and Postgres packages are already installed.
OGo depends on these virtual packages.  The Debian OGo packages should
warn about this so the user can abort the install and pre-install Apache2
and Postgres 8.1 if desired.  There may be similar issues with
libapache-mod-ngobjweb and libapache2-mod-ngobjweb.

2)  The rewrite and include modules need to be enabled in Apache.  This
MAY happen for Apache (don't know), but it certainly doesn't for Apache2.

3)  OGo should be enabled in the appropriate runlevels (at the users
discretion).

  Even if this is too much trouble, a README.Debian text file in
/usr/share/doc/opengroupware (as per Debian tradition) explaining these
issues would be appreciated.  Would have saved me quite a bit of time.

> INVALID -
> (1) OGo is a complex package,  people trying to install it without
> **FIRST** reading the documentation should expect to have problems.
> Nobody whips out an M$-Exchange CD pops it in the drive,  double clicks
> install.exe, and then charges through the installing merrily clicking
> random options.

  Perhaps I'm just weird, but this is exactly how I learn...  I install a
package and play, and then go back to a manual if/when I need to.  It's
a lot easier for me to efficiently read a manual if I've first played
with the software and can put the information into context.  The brick
walls I ran into installing OGo annoyed the hell out of me.  :)

> Script magic can only
> do so much to provide that - administrators should *EXPECT* to have
> to setup these services.  If the current configuration differs from the
> default or the distribution has done something torturous in packaging
> the service there isn't any solution except reading the documentation
> and setting up the service appropriately.  How to setup the services
> manually is very specifically described in WMOGAG.

  Many IT people are LAZY (not a bad thing) and/or have limited time.
Making it easier to get a working (though untuned) config is a goal worth
achieving IMHO.  (The moans from the Sunbird Devel list asking for
"someone else" to set up an OGo test server helped me understand this).

  Surely a script automating OGo + Postfix + CyrusIMAP isn't a bad thing.
I would be open to donating mine to the deb package.  Such things go in
/usr/share/doc/opengroupware.org/examples as per Debian tradition. I'm
only a novice scripter, but I guess something is better than nothing.
Dire warnings for end users might be appropriate however.

  I also plan to write another few scripts for the CTI stuff, Funambol and
perhaps SpamAssassin/Amavis/ClamAV once I can actually make it all
work manually.

>>/ I understand CalDAV is horribly complex, but the 
/>>/ first server to connect to a CalDAV/GroupDAV client reliably will 
/>>/ collect a HUGE number of users. 
/>
> Agree.  But that won't happen magickally, and OGo is an Open Source
> project....  

  I'm no developer, but I've emailed the Sunbird list and have spoken to
Bruno Browning (the Sunbird CalDAV guy).  It seems that noone from their
side is interested in implementing GroupDAV as CalDAV is the priority
right now.  He suggested either making OpenGroupware CalDAV compliant
(which he understood would be a big task), or implementing a GroupDAV
plugin for Sunbird.  I'm beginning to understand that neither of these
things will probably happen in the near future, and I don't have the
skills to do anything about that problem myself.

>>/  GroupDAV probably won't be implemented 
/>>/ on a client before CalDAV is, so if OpenGroupware waits for a GroupDAV 
/>
> You are implying that you found CalDAV/GroupDAV not to work?

  I've tried Sunbird, Mulberry and Chandler...  Sunbird was most
acceptable, but still had issues with alarm notifications creating
duplicate events.  I found a patch for Sunbird 0.5, but then I discovered
another bug quite quickly, and from experience and discussions I now
know that Sunbird is becoming less likely to work correctly against OGo
as time passes because its CalDAV implementation is becoming more complex
and is implementing CalDAV features OGo does not support.

> No, GroupDAV is not a subset of CalDAV.   CalDAV is specific to
> calendering.  GroupDAV provides for contact information.

  It was my understanding that both provide similar features, but GroupDAV
was created as a subset of the CalDAV spec because of the complexity of
CalDAV, and the fear that CalDAV would become another IMAP (ie. a complex
spec with many slightly incompatible implementations).  Perhaps I got the
wrong impression?

> What do you think WMOGAG is?
> http://docs.opengroupware.org/Members/whitemice/wmogag/file_view
> I don't sell it, but no customer in their right mind is going to deploy
> and pour information into a server for which there isn't a manual.  

  Perhaps you should find a printer who can bind one-off copies so you
can offer a hardcopy of your manual to the world for a price that is
worth your while (which is probably much more than you would EVER pay
yourself).  You may get bites or you may not, but it's partially about
marketing.  Selling manuals gives your legitimacy a boost as a
commercial entity, and would do the same for Skyrix.

  I've got marketing people in my family and they've helped me
understand the unfortunate truth that keeping an eye towards image is
often essential.  I guess that's why I would like to see training
materials, lesson plans and manuals for sale.  They are probably
written already, so they might as well go up for sale at a price that
would justify one-off printing.  (It's understood that rare manuals
sell at a HEFTY price).  If they sell well and turn a nice profit
that's even better.  Even Richard Stallman was surprised that people
bought tapes of stuff that they could download for free in the early
days of GNU.  Give it a go...  you've got nothing to lose!

  Same goes for WebUI customisation.  It looks good for your company
ie. gives customers the impression that your company has another
revenue stream, and that they are buying into a product they can
extend later (even if they never do).  Putting on my
evil-financial-controller-with-no-IT-knowledge hat the Skyrix web
page looked a little spartan to me, and there isn't enough to buy
for me to feel completely reassured that they are a dependable
company.

-Mark