Re: [OSGeo-Discuss] Open Source development metrics
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 disappeared when we switched from CVS to SVN. br, Bruno ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Open Source development metrics
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 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 http://www.ohloh.net/accounts/blowagie Sure, this is just an indication based on an algorithm that takes many parameters into account, but indications such as "increasing year-over-year development activity" and "maturity" can't be faked. br, Bruno ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Open Source development metrics
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 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 http://www.ohloh.net/accounts/blowagie Sure, this is just an indication based on an algorithm that takes many parameters into account, but indications such as "increasing year-over-year development activity" and "maturity" can't be faked. br, Bruno ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Open Source development metrics
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 http://www.ohloh.net/accounts/blowagie Sure, this is just an indication based on an algorithm that takes many parameters into account, but indications such as "increasing year-over-year development activity" and "maturity" can't be faked. br, Bruno ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
RE: [OSGeo-Discuss] Open Source development metrics
I think I should clarify what I mean by a fork. There is the very public, conflict-driven version of a fork, and then there is an often private, cooperative version of a fork. Imagine this scenario: The company "Who's Wet Now Inc." is using OpenJUMP internally to produce flood maps of urban areas in the United States. They have several features that they would like to add to OpenJUMP, but need to integrate the features more quickly than is normally possible in the OpenJUMP community. As a result, they maintain a private fork of the main OpenJUMP code base in their own SVN repository. This allows them to integrate there new features quickly, without waiting for discussion and approval by the larger OpenJUMP community. The private build of OpenJUMP is distributed to all their employees. The most commonly used features are then moved by Who's Wet Now into the main OpenJUMP code base after community discussion and approval. Any patches for bugs found during the Who's Wet Now development process are also migrated back to the main OpenJUMP code base. In a scenario like this I think a fork may be acceptable, and even a beneficial thing. I think any of the following reasons would be valid reasons for maintaining this type of "cooperative fork": [1] New features that an organization wants to integrate into the program are very specialized and would not be utilized by most of the community. [2] Changes an organization wants to make to a program are controversial or experimental. [3] An organization needs to move development ahead at a pace that is faster than the larger community of developers is comfortable with. As long as the organization maintaining the private fork does [1] a good job of tracking their modifications compared to the parent code base, and [2] actively participates in moving the benefits of their fork development back to the parent code base when appropriate, I don't see any problem with the fork. This is based on my own limited experience with OpenJUMP, which is just one program among many. If the organization creating the fork is not a "good citizen" of the community then I recognize that a fork can be a very bad thing. Landon From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Miguel Montesinos Sent: Wednesday, May 28, 2008 3:09 PM To: OSGeo 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 is not only honest, but discouraging and efectiveless. I don't see neither how a user can simply make a proper decission among a fork-hood. Not everybody is expert enough to understand differences, or has enough time to download several forks and compare them (continously in time). Are really all the differences among forks impossible to reconcile, using 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 sense for the organization to maintain their own fork of the code to which improvements can be made. This really doesn't cause problems for the parent of the fork as long as there is an established process and some honest effort made to integrate the best of the improvements back into the parent code base. This is actually how OpenJUMP works. There are only a handful of developers that actually work on the parent code base. Most of our contributors maintain their own fork, but siphon back improvements to the parent. 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 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 permanent staff to contribute to ongoing OS development work outside of normal Project based development with its well defined deliverables and timeframes. In Australia within the public sector and also in many larger private organisations there is a Human Resources process in place that is based on Performance Management. This process allows either staff or managers to initiate discussions that allow for goal based work to be undertaken. In principal both parties agree to a set of goals. I
[OSGeo-Discuss] No news on the election?
Hi, A few days ago [1] Jo announced here the Election 2008 has started. Today, nomination closes and during next 5 days charter members will vote. So, we are in the middle of quite important event for the foundation but it hasn't been announced on the osgeo.org news. Shouldn't we make some noise about the voting soon? [1] http://lists.osgeo.org/pipermail/discuss/2008-May/003658.html -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [Aust-NZ] Re: [OSGeo-Discuss] Open Source development metrics
IMO: Thank you for the insights Jody. You have made some excellent suggestions that we as an OSGeo-AustNZ / ANZLIC community can build on. Bruce Jody Garnett <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 29/05/2008 08:15 AM To OSGeo Discussions cc Aust-NZ OSGeo <[EMAIL PROTECTED]> Subject [Aust-NZ] Re: [OSGeo-Discuss] Open Source development metrics [EMAIL PROTECTED] wrote: > However this is probably unrealistic as to do this the developer will > have to have existing credibility within the community and there may > be good reasons why the community does not want to have 'product X' > included. So start slow with some metrics reflecting getting involved in the community and making contacts. > Does anyone have any examples that they use or thoughts on the above? > I do understand that metrics can be abused, may be meaningless and may > not be the best way to handle this, however we have to start somewhere. What a hard question ... Try for a couple of the metrics you use when evaluating open source projects: - open development; what is their level of involvement on a scale of learning, helping, submitting patches, commit access, responsibility, responsibility - documentation and help (assume number of pages written/edited; or number of questions answered on the user list) - quality assurance: number of test cases produced - number of patches submitted, or number of bugs depending on level of involvement... consider putting this on a scale so long standing bugs are worth more :-) - frequency of release (number of releases the employee assisted with via either tagging and packaging, testing; announcing etc...) - etc... I recommend approaching the specific communities you wish to be involved in and asking where help is needed. > We have a window of opportunity to get some more developers working on > OS projects as the Performance Planning cycle re-starts shortly and > I'd like to help our developers get some constructive ideas to take > into their sessions. Cheers, Jody ___ Aust-NZ mailing list [EMAIL PROTECTED] http://lists.osgeo.org/mailman/listinfo/aust-nz Notice: This email and any attachments may contain information that is personal, confidential, legally privileged and/or copyright.No part of it should be reproduced, adapted or communicated without the prior written consent of the copyright owner. It is the responsibility of the recipient to check for and remove viruses. If you have received this email in error, please notify the sender by return email, delete it from your system and destroy any copies. You are not authorised to use, communicate or rely on the information contained in this email. Please consider the environment before printing this email. ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
RE: [OSGeo-Discuss] Open Source development metrics
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 new developments that others make to the parent project, without having to refactor our 'fork' each time, or conversly, the additional work of refactoring our customisations, or part there of back to the parent project. We (the Australian ANZLIC community) have tried this approach already with the GeoNetwork ANZLIC Profile, and it is clearly not working (despite might I add the outstanding efforts of the main developer). I think that the only sane approach is to work within the parent project's community as peer participants. I do agree with Puneet that the *ability* to fork a project is critical to the success of open source projects, however I think that it should really only be used as a last resort if a situation is clearly unsalvagable. There is too much dilution of effort otherwise. Bruce Bannerman > Bruce, > > I agree with Puneet. In this scenario it would make more sense for > the organization to maintain their own fork of the code to which > improvements can be made. This really doesn’t cause problems for the > parent of the fork as long as there is an established process and > some honest effort made to integrate the best of the improvements > back into the parent code base. > > This is actually how OpenJUMP works. There are only a handful of > developers that actually work on the parent code base. Most of our > contributors maintain their own fork, but siphon back improvements > to the parent. > > Landon > ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Open Source development metrics
[EMAIL PROTECTED] wrote: However this is probably unrealistic as to do this the developer will have to have existing credibility within the community and there may be good reasons why the community does not want to have 'product X' included. So start slow with some metrics reflecting getting involved in the community and making contacts. Does anyone have any examples that they use or thoughts on the above? I do understand that metrics can be abused, may be meaningless and may not be the best way to handle this, however we have to start somewhere. What a hard question ... Try for a couple of the metrics you use when evaluating open source projects: - open development; what is their level of involvement on a scale of learning, helping, submitting patches, commit access, responsibility, responsibility - documentation and help (assume number of pages written/edited; or number of questions answered on the user list) - quality assurance: number of test cases produced - number of patches submitted, or number of bugs depending on level of involvement... consider putting this on a scale so long standing bugs are worth more :-) - frequency of release (number of releases the employee assisted with via either tagging and packaging, testing; announcing etc...) - etc... I recommend approaching the specific communities you wish to be involved in and asking where help is needed. We have a window of opportunity to get some more developers working on OS projects as the Performance Planning cycle re-starts shortly and I'd like to help our developers get some constructive ideas to take into their sessions. Cheers, Jody ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
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 is not only honest, but discouraging and efectiveless. I don't see neither how a user can simply make a proper decission among a fork-hood. Not everybody is expert enough to understand differences, or has enough time to download several forks and compare them (continously in time). Are really all the differences among forks impossible to reconcile, using 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 sense for the organization to maintain their own fork of the code to which improvements can be made. This really doesn't cause problems for the parent of the fork as long as there is an established process and some honest effort made to integrate the best of the improvements back into the parent code base. This is actually how OpenJUMP works. There are only a handful of developers that actually work on the parent code base. Most of our contributors maintain their own fork, but siphon back improvements to the parent. 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 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 permanent staff to contribute to ongoing OS development work outside of normal Project based development with its well defined deliverables and timeframes. In Australia within the public sector and also in many larger private organisations there is a Human Resources process in place that is based on Performance Management. This process allows either staff or managers to initiate discussions that allow for goal based work to be undertaken. In principal both parties agree to a set of goals. If the goals are met, it contributes to the employee's remuneration review. What I'm trying to find are some examples of generic metrics that are meaninful to Open Source development methodologies. They must be specific, meaningful and measurable. For example, we could look at measures such as: "Get feature X accepted into the trunk of GeoNetwork by June 2009" However this is probably unrealistic as to do this the developer will have to have existing credibility within the community and there may be good reasons why the community does not want to have 'product X' included. Does anyone have any examples that they use or thoughts on the above? I do understand that metrics can be abused, may be meaningless and may not be the best way to handle this, however we have to start somewhere. We have a window of opportunity to get some more developers working on OS projects as the Performance Planning cycle re-starts shortly and I'd like to help our developers get some constructive ideas to take into their sessions. Bruce Bannerman Notice: This email and any attachments may contain information that is personal, confidential, legally privileged and/or copyright. No part of it should be reproduced, adapted or communicated without the prior written consent of the copyright owner. It is the responsibility of the recipient to check for and remove viruses. If you have received this email in error, please notify the sender by return email, delete it from your system and destroy any copies. You are not authorised to use, communicate or rely on the information contained in this email. Please consider the environment before printing this email. Warning: Information provided via electronic media is not guaranteed against defects including translation and transmission errors. If the reader is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this information in error, please notify the sender immediately. <>___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
[OSGeo-Discuss] open source GIS event in the Netherlands (17-6)
Hi list, a small announcement for the people based in The Netherlands (and nearby), 17 june there is a full-day open source GIS event in Delft, with (among other things) workshops on OpenLayers and PostGIS. For more info: http://www.osgeo.nl/ Best regards, Bart -- Bart van den Eijnden OSGIS, Open Source GIS [EMAIL PROTECTED] http://www.osgis.nl ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
[OSGeo-Discuss] Wiki Category: OSGeo Member
Folks, I'd like to remind about Arnulf's initiative of the Category: OSGeo Member. Details available at: http://wiki.osgeo.org/wiki/Category:OSGeo_Member I'd like to encourage all of you who haven't updated their profile, to take a minute and add yourself as an OSGeo Member. -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
RE: [OSGeo-Discuss] Open Source development metrics
Bruce, I agree with Puneet. In this scenario it would make more sense for the organization to maintain their own fork of the code to which improvements can be made. This really doesn't cause problems for the parent of the fork as long as there is an established process and some honest effort made to integrate the best of the improvements back into the parent code base. This is actually how OpenJUMP works. There are only a handful of developers that actually work on the parent code base. Most of our contributors maintain their own fork, but siphon back improvements to the parent. 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 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 permanent staff to contribute to ongoing OS development work outside of normal Project based development with its well defined deliverables and timeframes. In Australia within the public sector and also in many larger private organisations there is a Human Resources process in place that is based on Performance Management. This process allows either staff or managers to initiate discussions that allow for goal based work to be undertaken. In principal both parties agree to a set of goals. If the goals are met, it contributes to the employee's remuneration review. What I'm trying to find are some examples of generic metrics that are meaninful to Open Source development methodologies. They must be specific, meaningful and measurable. For example, we could look at measures such as: "Get feature X accepted into the trunk of GeoNetwork by June 2009" However this is probably unrealistic as to do this the developer will have to have existing credibility within the community and there may be good reasons why the community does not want to have 'product X' included. Does anyone have any examples that they use or thoughts on the above? I do understand that metrics can be abused, may be meaningless and may not be the best way to handle this, however we have to start somewhere. We have a window of opportunity to get some more developers working on OS projects as the Performance Planning cycle re-starts shortly and I'd like to help our developers get some constructive ideas to take into their sessions. Bruce Bannerman Notice: This email and any attachments may contain information that is personal, confidential, legally privileged and/or copyright. No part of it should be reproduced, adapted or communicated without the prior written consent of the copyright owner. It is the responsibility of the recipient to check for and remove viruses. If you have received this email in error, please notify the sender by return email, delete it from your system and destroy any copies. You are not authorised to use, communicate or rely on the information contained in this email. Please consider the environment before printing this email. Warning: Information provided via electronic media is not guaranteed against defects including translation and transmission errors. If the reader is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this information in error, please notify the sender immediately.___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Open Source development metrics
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. I think you agreed with me above. Forking for the heck of it is bad. Having the ability to fork, when forking becomes necessary, can be heaven-sent. I am not advocating to go make your own version of the beast. I am saying -- look, don't treat open source any different. Make it mainstream. Use it to solve your own specific problem. Trying to create open source to solve the world's problem is a sure recipe for failure. Of course, it just might happen that your own problem might also be the problem for many others in the world. In which case, donate your work back to open source so others may benefit. And, don't worry about forking. Given that most problems faced by most folks are likely to be mostly similar, your solution would likely work for someone else as well. Very Darwinian, no? > > It also does not help the average user much in selecting what's good for > him/her. I think that Ubuntu as a popular release is one of the proofs that > too much choice does not help to reach the large crowd. By limiting the > installed default software packages they quickly reached a huge user group. > > My 2 cents, ciao, > Jeroen > > On May 28, 2008, at 12:01 PM, P Kishor wrote: > > > > Forking is not a bad thing. I have no idea why it is viewed as such. > > Forking is one of the beauties of open source, brings diversity in the > > code base, and even ensures longevity. The ability to fork is what > > ensures that in open source there will not be any lock-in. > > > > The beauty of this approach is the open source is not treated as > > something special. It becomes as normal as non-open source software. > > .. -- Puneet Kishor http://punkish.eidesis.org/ Nelson Institute for Environmental Studies http://www.nelson.wisc.edu/ Open Source Geospatial Foundation (OSGeo) http://www.osgeo.org/ ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Open Source development metrics
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 selecting what's good for him/her. I think that Ubuntu as a popular release is one of the proofs that too much choice does not help to reach the large crowd. By limiting the installed default software packages they quickly reached a huge user group. My 2 cents, ciao, Jeroen On May 28, 2008, at 12:01 PM, P Kishor wrote: Forking is not a bad thing. I have no idea why it is viewed as such. Forking is one of the beauties of open source, brings diversity in the code base, and even ensures longevity. The ability to fork is what ensures that in open source there will not be any lock-in. The beauty of this approach is the open source is not treated as something special. It becomes as normal as non-open source software. .. -- Puneet Kishor http://punkish.eidesis.org/ Nelson Institute for Environmental Studies http://www.nelson.wisc.edu/ Open Source Geospatial Foundation (OSGeo) http://www.osgeo.org/ ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Open Source development metrics
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 is meaningful for > > your organization first and for open source second. In other words, > > you would treat open source development no different from non-open > > source development. Open source would simply become a "normal" > > activity. > > > > Once feature X works for you, you could consider "donating" it to the > > open source community by whatever process that particular open source > > project has. > > > > Other metrics such as SLOC (source lines of code) or "feature in SVN > > trunk" are not only subject to abuse, they are also mostly > > meaningless. > > > > > We want to avoid anything that could result in an isolated fork or branch. > > This is a danger with this approach. Quite the contrary -- don't fixate on "forking as a bad thing." Do what is good for your own organization. If it is of sufficient general interest, and if enough folks find it of use to them, it will get absorbed in the main branch anyway. Else, it will either die off (in which case it still served your own organization's purpose) or develop as a specialized branch. Very Darwinian. Forking is not a bad thing. I have no idea why it is viewed as such. Forking is one of the beauties of open source, brings diversity in the code base, and even ensures longevity. The ability to fork is what ensures that in open source there will not be any lock-in. The beauty of this approach is the open source is not treated as something special. It becomes as normal as non-open source software. > > > However, it has merit in that it would allow a developer to meet their > performance > criteria and concentrate on getting the customisation into the trunk in > their > own time. > > > Bruce > > > > > > .. -- Puneet Kishor http://punkish.eidesis.org/ Nelson Institute for Environmental Studies http://www.nelson.wisc.edu/ Open Source Geospatial Foundation (OSGeo) http://www.osgeo.org/ ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Open Source development metrics
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 second. In other words, > you would treat open source development no different from non-open > source development. Open source would simply become a "normal" > activity. > > Once feature X works for you, you could consider "donating" it to the > open source community by whatever process that particular open source > project has. > > Other metrics such as SLOC (source lines of code) or "feature in SVN > trunk" are not only subject to abuse, they are also mostly > meaningless. > We want to avoid anything that could result in an isolated fork or branch. This is a danger with this approach. However, it has merit in that it would allow a developer to meet their performance criteria and concentrate on getting the customisation into the trunk in their own time. Bruce Notice: This email and any attachments may contain information that is personal, confidential, legally privileged and/or copyright.No part of it should be reproduced, adapted or communicated without the prior written consent of the copyright owner. It is the responsibility of the recipient to check for and remove viruses. If you have received this email in error, please notify the sender by return email, delete it from your system and destroy any copies. You are not authorised to use, communicate or rely on the information contained in this email. Please consider the environment before printing this email. ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Open Source development metrics
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 Profile. > > In particular, we're looking at options that allow permanent staff to > contribute to ongoing OS development work outside of normal Project based > development with its well defined deliverables and timeframes. > > > > In Australia within the public sector and also in many larger private > organisations there is a Human Resources process in place that is based on > Performance Management. This process allows either staff or managers to > initiate discussions that allow for goal based work to be undertaken. > > In principal both parties agree to a set of goals. If the goals are met, it > contributes to the employee's remuneration review. > > > What I'm trying to find are some examples of generic metrics that are > meaninful to Open Source development methodologies. They must be > specific, meaningful and measurable. > > > For example, we could look at measures such as: > > > "Get feature X accepted into the trunk of GeoNetwork by June 2009" > > > However this is probably unrealistic as to do this the developer will have > to have existing credibility within the community and there may be good > reasons why the community does not want to have 'product X' included. > 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 second. In other words, you would treat open source development no different from non-open source development. Open source would simply become a "normal" activity. Once feature X works for you, you could consider "donating" it to the open source community by whatever process that particular open source project has. Other metrics such as SLOC (source lines of code) or "feature in SVN trunk" are not only subject to abuse, they are also mostly meaningless. > > Does anyone have any examples that they use or thoughts on the above? > > > I do understand that metrics can be abused, may be meaningless and may not > be the best way to handle this, however we have to start somewhere. > > > > We have a window of opportunity to get some more developers working on OS > projects as the Performance Planning cycle re-starts shortly and I'd like to > help our developers get some constructive ideas to take into their sessions. > > > > > Bruce Bannerman > > > > > > Notice: > This email and any attachments may contain information that is personal, > confidential, > legally privileged and/or copyright. No part of it should be reproduced, > adapted or communicated without the prior written consent of the copyright > owner. > > It is the responsibility of the recipient to check for and remove viruses. > > If you have received this email in error, please notify the sender by return > email, delete it from your system and destroy any copies. You are not > authorised to use, communicate or rely on the information contained in this > email. > > Please consider the environment before printing this email. > > > > > > > ___ > Discuss mailing list > Discuss@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/discuss > > -- Puneet Kishor http://punkish.eidesis.org/ Nelson Institute for Environmental Studies http://www.nelson.wisc.edu/ Open Source Geospatial Foundation (OSGeo) http://www.osgeo.org/ ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] on Google Code and export restrictions
P Kishor wrote: On 5/27/08, Chris Puttick <[EMAIL PROTECTED]> wrote: - "Frank Warmerdam" <[EMAIL PROTECTED]> wrote: > Dave Patton wrote: > > Frank Warmerdam wrote: > > > >> I agree that we ought to consider developing a similar policy to > >> Apache's. I'll add an agenda item for the next board meeting to > >> start digging into this. > > > > One item for discussion would be what takes place > > when a project enters incubation. Do they "opt in" > > to the OSGeo policy? If they don't, are they then > > excluded from being an OSGeo project? Can they > > "opt in", and yet maintain their own project > > infrastructure (website, svn, download links, etc.) > > on servers in another country, and have access > > to that infrastructure be subject to policies that > > may conflict with the OSGeo policy? > > Dave, > > Projects going through incubation are allowed to maintain their own > distinct infrastructure, wherever they want for the most part. But > they are still board as a project to follow OSGeo policy and obey > applicable US laws even if their download server (for instance) is > not in the US. > > Best regards, > -- > ---+-- > I set the clouds in motion - turn up | Frank Warmerdam, > [EMAIL PROTECTED] > light and sound - activate the windows | http://pobox.com/~warmerdam > and watch the world go round - Rush| President OSGeo, > http://osgeo.org > > ___ > Discuss mailing list > Discuss@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/discuss Then I respectfully suggest, insofar as some recent US laws are at a level of paranoia that might prevent some open source software from actually being open. that OSGeo should consider reconstituting itself in a country that is less totalitarian in its attitudes. Easy now. Prefixing "respectfully" to assertions of "paranoia" and "totalitarian" to a country whose funding and work gave rise to MapServer is not a good strategy. In fact, it would be difficult to conceive of open source itself without the contributions of this "totalitarian" and "paranoid" country. National-level security-related policy decisions are not usually made with consideration of their impact on every conceivable issue. The key is to constructively find a way around it, which many on this list are trying to do. I am sure OSGeo is not the first group to face this situation. For starters, I am asking around with my policy-contacts to see what light they can shed on this. Regards Chris I seem to recall other projects dealing with this in the past too. Like there were 2 different netscape downloads one for in the US and one for outside the US possibly with the ssl library removed due to restrictions on encryption tool export. Alex ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
