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. 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
