[Kroupware] build & install script for Kolab 1.0

[Jean Dumont]

Le  Sun, Jul 27, 2003 at 02:31:32PM +0200, Martin Konold a tapoté:
> Hi Jean,

Hello everybody, (I definitely must learn to behave)
> 
> > compile apache (it's defined as no in the spec file)
> 
> Changed in the QIM

my mistake, didn't check before posting
> 
> Kolab is intended to provide additional features to OSS not available 
> elsewhere. Providing packaging is courtesy of the involved companies and was 
> not contracted. Please don't mix the packaging with the product.

I don't, but I suppose the goal is to distribute the product to as much people
as possible, so the packaging is important as well as the first impression,
and having a difficult to install product due to bad documentation will in the
end reflect badly on the product itself (which is quite good)

> > (as a mail server). I'm afraid my answer would have to be no at the moment.
> 
> Why? 

Because in order to persuade those people to switch away from Exchange (which
is _perceived_ as easy to install and maintain), the alternative must be
credible.
Let me elaborate a bit, the local administrations here (in Belgium) don't have
much money so they are looking for ways to cut their cost and Opensource
Software seems a good way to do it (don't lure yourself with Open Standard
and so on, at the political level, all they care about is how much it costs). 
But their service provider (most don't have a IT infrastructure, they
outsource everything) keeps telling them that there is no life beyond
Microsoft (those provider are more or less Microsoft'affiliates) so an
alternative has to be better than Exchange (which I think Kolab is, at least
as a mailserver) but when the installation is so convoluted that I have
problems to do it (and I'm quite experienced with Linux and Unix at 41 and
with 15+ years working with HP-UX, Solaris and Linux), I say this is
something which will hinder the acceptance of an otherwise great product.

> For special purpose tweaking we currently only provide the template files for 
> manual editing with a text editor. Later versions of Kolab will provide GUI 
> support for advanced features like multi-domain, mulit-location,....
 
Great I look forward to it

> You can speed up this development by contracting the respective companies 
> though ;-)

I think this would be difficult, but if there was some way to donate part of
the money (through a foundation or something), maybe I could find a way to
persuade my boss.  

> > file db which is quite strange for ldap.
> 
> Please elaborate more.

Everything is at the root of the tree, there does not seem to be a concept of
group which is nice to have if you have a lot of users, also the passwords are
stored unencrypted which is a security risk (especially when the manager
password is stored clear text in the slapd.conf file). In fact I encrypted
this password (with slappasswd) but nothing works anymore. And if you include
some character in the password (can't remember if it was a quote, a double
quote or a parenthesis), the parser seems to choke on it. 
 
> Yes, polish is always nice. But please be aware of the fact that we emphasized 
> on the architecture not on the polishing in order to create a sound 
> foundation to build our future efforts upon. IMHO this is the better approach 
> compared to polishing in a too early stage.
 
I totally agree and as I was not involved in the architectural design, I will
not comment on it.

I would like to finish on a positive note, Kolab is a much needed product and
even if in it's present state it still has a few rough edges (most notably on
the configuration side), I think this is a great step toward attracting new
users to the free software world.

Great job

-- 
Jean Dumont