[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gforge-devel] Architecture, LGPL
From: |
Ryan T. Sammartino |
Subject: |
Re: [Gforge-devel] Architecture, LGPL |
Date: |
Mon, 10 Feb 2003 10:59:10 -0800 |
User-agent: |
Mutt/1.4i |
On Mon, Feb 10, 2003 at 02:30:36PM +0100, Christian BAYLE wrote:
> Ryan T. Sammartino a écrit:
>
> Roland's plugin allows also to easily hook in, do you have some idea on
> how different are
> phpgroupware concepts?
Concepts are pretty much the same. Some critical differences that in no
way reflect poorly on Roland's work:
- phpgroupware was designed from the ground up with this sort of
architecture in mind. I hate to second-guess after the fact, but I
don't think SourceForge/Savannah/GForge was.
- their system is already proven: I see how new modules hook in and it
all works. I haven't seen a GForge plugin using Roland's work yet.
- their system is much more complete, featuring things like module
dependencies.
>
> My idea of the use of add-on is modularity allowing e.g. to choose one
> tracker or an other
Aye.
> I think this is a bad choice to bet on proprietary add-ons though I
> don't deny anybody the
> right or the freedom to do it.
I'm not betting on it.
> -My reason are:
> You can't correct bug.
> You can't translate
> You can't benefit of the experience of the programmed code
> You can't enhance/modify code to fit your needs
>
We're all familiar with why proprietary is inferior to free/open. That
isn't the real issue. The real issue is our target audience and
acceptance: our target audience is going to be small to medium (to
large?) mostly proprietary software houses that work on many projects
and want to coordinate activity.
> Adding to this it may conflict with GPL, and finnaly be a licence nightmare.
Which is why the core API would be LGPLed, mitigating those nightmares.
--
Ryan T. Sammartino
http://members.shaw.ca/ryants/
pain, n.:
One thing, at least it proves that you're alive!