Jody Garnett wrote:
Try for a couple of the metrics you use when evaluating open source
projects
If a project or F/OSS developer has been around for a while,
there are bound to be online metrics about it/him/her, for
instance on Ohloh. Some examples:
http://www.ohloh.net/projects/305
Just a word of warning; those sites get tripped up; you can see the
history for geotools is missing because we just cleaned up our
subversion repository a bit.
Jody
Bruno Lowagie wrote:
Jody Garnett wrote:
Try for a couple of the metrics you use when evaluating open source
projects
If a
The following one is also useful:
- http://cia.vc/stats/project/geotools
For projects going through incubation these tools are a valuable
resource in figuring out who changed what when.
Jody
Jody Garnett wrote:
Try for a couple of the metrics you use when evaluating open source
projects
Jody Garnett wrote:
Just a word of warning; those sites get tripped up; you can see the
history for geotools is missing because we just cleaned up our
subversion repository a bit.
True: in my personal history, it's as if I have been inactive for
years, but in reality all the CVS data
IMO:
An issue has come up recently on the OSGeo-AustNZ list that I'd appreciate
some feedback from our wider OSGeo Community.
The context of this issue is that we are exploring ways to support
development of the GeoNetwork ANZLIC Profile.
In particular, we're looking at options that allow
IMO:
Thanks for the comments Puneet,
Actually, a variation on the above may be the best metric -- create
feature X that we need in our organization and that works for us.
That would allow your organization to determine what is meaningful for
your organization first and for open source
On 5/28/08, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
IMO:
An issue has come up recently on the OSGeo-AustNZ list that I'd appreciate
some feedback from our wider OSGeo Community.
The context of this issue is that we are exploring ways to support
development of the GeoNetwork ANZLIC
On 5/28/08, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
IMO:
Thanks for the comments Puneet,
Actually, a variation on the above may be the best metric -- create
feature X that we need in our organization and that works for us.
That would allow your organization to determine what
Hmmm, I tend to strongly disagree here. Forking indeed can prevent a
lock-in if that is becoming a serious issue in the project. Otherwise
it just causes lots of duplication of efforts and dilution of energy
into different forked versions.
It also does not help the average user much in
On 5/28/08, Jeroen Ticheler [EMAIL PROTECTED] wrote:
Hmmm, I tend to strongly disagree here. Forking indeed can prevent a lock-in
if that is becoming a serious issue in the project. Otherwise it just causes
lots of duplication of efforts and dilution of energy into different forked
versions.
.
Landon
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Wednesday, May 28, 2008 12:00 AM
To: discuss@lists.osgeo.org
Cc: Aust-NZ OSGeo
Subject: [OSGeo-Discuss] Open Source development metrics
IMO:
An issue has come
that
'honest effort'? ;-)
Miguel
De: [EMAIL PROTECTED] en nombre de Landon Blake
Enviado el: mié 28/05/2008 16:27
Para: OSGeo Discussions
Asunto: RE: [OSGeo-Discuss] Open Source development metrics
Bruce,
I agree with Puneet. In this scenario it would make more
IMO:
Thanks Landon and Puneet,
In this case, I tend to agree with Jeroen.
There is a community developing GeoNetwork (and other projects) with
ongoing work occuring.
This would be occurring concurrently with our development work on a fork.
We would want to be able to take advantage of the
Discussions
Subject: RE: [OSGeo-Discuss] Open Source development metrics
Landon,
on the other hand, following that logic, if forking is advisable, it will keep
on growing, with new forks, new forks-of-the-fork, and so on. The energy needed
to keep all that project forkhood somehow synchronized
14 matches
Mail list logo
