Re: OGo Donation

On 27.10.2003, at 22:16, [email protected] wrote:
> I'm currently investigating for a GroupWare software for one of the
> Universities in Stuttgart, Germany.

BTW: there is also discuss-de in German language ;-)

> Without installing and testing the software myself I have some doubts
> on OGO because:
>         1) there are daily reports that some obvious function suddenly 
> do no work.

Yes, this is because OGo packages only come in the form of nightly 
builds. If you need stable and QA'ed packages, you can buy SKYRiX 5 
(basically OGo as a maintained product), like you would(/usually 
*must*) buy maintainance at some other vendor.
OGo unlike the "others" has no associated license costs.

Notably the quality of the update packages of some closed-source 
competitors barely succeeds the quality of the OGo nightly builds ...

>         2) there is no clear release / version concept.

For OGo?
But if you are comparing to Groupwise and others, you should compare 
against SKYRiX 5, which *has* a release/version process. And I think we 
do extremely well here, given that continous release process we started 
several years ago with SKYRiX 3. Never artificially bumping release 
numbers, never doing incompatible changes to the database schema, never 
_replacing_ existing UIs with "better" ones,  etc.
OGo automatically inherits a lot of that which IMHO also results in a 
much better "outlook" for OGo as a solution.

>         3) there is no clear and controlled process to select and add 
> new functionallity.

There is. But it is driven internally by SKYRIX AG for SKYRiX 5, not by 
the OGo community in the moment, simply because (almost) no one else is 
committing so far (not surprising, with OGo being a pretty complex 
project with an age of less than half a year - I expect that to change 
in the midterm future).

>         4) Installation seams not to work right-out-of-the-box on 
> typical systems.

If you need tested and easier to install packages, buy SKYRiX 5. 
Otherwise I would suggest to go with Debian which usually works best 
due to being a well defined target and having an excellent package 
management system.

Anyway, since OGo packages rarely break something critical, having a 
cheap second system for trying out the nightly packages basically 
always allows you to work around the traps. This is required in 
practice for most commercial system updates as well.
I wrote some mail on that issue some days ago in the users-de list.

> Helge, I understand that you are busy to fix all problems and add 
> functionality
> as required.

Hm, there seems to be a common misconception that it is just me who is 
fixing and adding functionality. This is not the case, OGo is the 
development base of SKYRiX 5 and therefore the whole SKYRIX AG support 
and development stuff is working on OGo, fixing bugs, adding features, 
maintaining the infrastructure.

> I thinks Quality should be at the first place for all future 
> development decisions, next Reliability, then Maintanebility.
> Then: Improve Installation and documentation,
> Then: Create a stable release (after some Betas), giving each 
> component a unique numbering.

Unfortunately we currently miss enough volunteers to do that on a free 
basis and SKYRiX staff does exactly that for SKYRiX 5.

> Then, only then: add new functionality while maintaining 
> compatibility.   DB changes are a NO-NO !!.

We are doing *NO* incompatible DB changes for at least five years. Eg 
you can still run a SKYRiX 3.5 side-by-side with OGo or SKYRiX 5 on the 
very same database!

Yet we are *adding* fields for new functionality. And those DB changes 
are automatically upgraded by the SKYRiX 5 installers.

Of course you can also automate this task for OGo by always running the 
pg-update schema script after each automatic package update.

We really take a *LOT* of care on the database schema (not only in 
schema stability but also in cross-database stability). Actually we see 
it as one of the most important assets of OGo to have a consistent and 
open database schema - since after all the data stored in a mission 
critical system is the most important aspect.
Eg unlike some competitors we do not use an obfuscated database schema, 
well actually a lot of competitors actually use a proprietary database 
anyway (read: database corrupted, data lost).

> BTW: I want to thank Helge for his tremendous effort.

That thanks should go to the whole SKYRIX team. Consider that this 
somewhat works like a band, I'm more or less the lead singer (and 
therefore most visible to the public), but without the drummer that 
isn't worth a lot either ;-) And we have a pretty big band (you 
wouldn't get that mail if Frank wouldn't maintain the mail server 
installation of OGo to give an example ;-).

> I hope SKYRIX will pay him for the next years.

Well, I guess we all know that this mainly depends on the success of 
SKYRiX 5 ;-)

regards,
   Helge
-- 
OpenGroupware.org
http://www.opengroupware.org/

-- 
OpenGroupware.org Discussion [email protected]
http://mail.opengroupware.org/mailman/listinfo/discuss