Re: OGo/Plone integration

Alessandro Amici <[email protected]>
Newsgroups gmane.comp.cms.opengroupware.discuss.general
Message-ID <[email protected]>
Helge,

On Friday 04 June 2004 20:31, Helge Hess wrote:
> ... leaving out most of the things you mentioned - this was discussed a 
> _lot_ in the users list (just check the archives).

i will check the archives ASAP.

> On Jun 4, 2004, at 20:07, Alessandro Amici wrote:
> > i'm just curious about the fact that skyrix is pushing a really
> > exciting open source project without considering interesting what is
> > claimed to be the first
> > advantage of the open source development model (and, at least in the
> > case of
> > the linux kernel it actually _is_ a really big advantage).
>
> If you take a _close_ look at OpenSource projects you'll realize that
> most of the successful projects are driven by a very small set of
> developers. OGo is no different in that.
> Eg I would be surprised if the Linux kernel has a much higher
> developer/codeline ratio. 

(oh my! i think in codelines/developer ;)

my feeling (i'm a programmer, i contributed code to an open source linux 
kernel module for about a year and i currently follow daily both lkml and 
various ogo lists) is that the codelines/developer is actually much lower for 
the kernel. this is mainly due to the presence of tons of small almost 
independent drivers that live in the linux source, but the kernel development 
model is structurally different from the cathedral-proprietary one.

but, let real numbers speak for me.

according to "David A. Wheeler's 'SLOCCount'" the ogo snapshot currently in 
debian (20040502) is 445,899 physical source lines of code in various 
languages (94% objc). this includes libobjc, libfoundation, sope and ogo 
proper.
a very rough estimate of the number of contributors comes from counting the 
email addresses in the source tree:
$ grep -iroh "[a-z0-9][a-z0-9-_]*@[a-z0-9-]*\.[.a-z0-9-]*" . | \
	sort | uniq | wc
    146     173    3788
from which we have to subtract 9 binary file matches, at least 12 duplicates 
of [email protected] (!) and a bunch of other obvious dupes. so let's say 
100.

the codelines/developer ratio is:  4,459.
which doesn't strike me as totally unrealistic, but i bet you can correct it 
up (not down).

again according to sloccount, the linux-2.6.6 source tree is 4,014,163 sloc 
(95% ansic).
the same grepping for email addresses gives:
   3516    3516   71938
with some amount of obvious duplications. let's say 3000.

the codelines/developer ratio is:  1,338 (approx one regulat .c file)

it is worth noting that this looks like a gross over estimate, among other 
things due to the fact that big corporations (IBM, Intel, SGI) don't keep 
track of the (many) internal contributors inside the source (i.e. the whole 
JFS directory contains no email at all).

so yes, i still argue that the linux kernel development model is profoundly 
different from the cathedral-proprietary one and that this very difference is 
one of the key ingredients in the amazing pace of the kernel development. :-)

> You also need to take into account that 
> groupware servers are used/required by much less people than say a
> kernel or a text processor. So if you expect that a GW attracts as much
> as a momentum as for example Apache or Linux, this is unrealistic ;-)

sure, the "raw number" is another important ingredient.

> Anyway, if you assume that OGo is not interested in patches contributed
> by other people, this is completely wrong (and proven different in
> practice).

no, i didn't assume that (for example i see how much you support sebastian in 
his debian packaging), i was just surprised that you (as skyrix) are not 
interested in "open source development out-sourcing" ;)

BTW: what is the company policy? are you going to accept a (technically sound) 
patch that also add "Portions Copyright (c) 2004 Joe Hacker released under 
the GPL"

cheers,
alessandro
-- 
OpenGroupware.org Discussion [email protected]
http://mail.opengroupware.org/mailman/listinfo/discuss
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.