How Rigorous is OSGeo Software Incubation?

It pains me to have to continue to write about what I consider to be faults of the new OSGeo Foundation, but as an unaffiliated developer of open source geospatial software, it's the only influence I have. I want these faults to be addressed. OSGeo must succeed, if only because its failure would wreck the wider open source geospatial domain. I've got friends who are deeply involved, and I'd like success for their sakes. I'm also worried that in this early stage, before it really finds its feet, our gentle OSGeo giant is going to stumble around and break things, or tread on worthy, but less ambitious software projects.

Comments

As Rigorous as we want it to be :-)

Author: Jody Garnett

For the first round of projects we are setting our own benchmarks and taking stock of the result. Some projects like GeoTools are raising their own bar fairly high resulting in a marked improvement. So far on our list is: - (C) to OSGEO (to pack IP check) - User Documentation with complete Coverage (something we have not had in 10 years) And I expect many more requirements will surface as we look at what these initial projects accomplish: - marketing materials - documented release cycle

Re: How Rigorous is OSGeo Software Incubation?

Author: Frank Warmerdam

Sean, You raise some interesting points. I was a bit surprised to read "but as an unaffiliated developer of open source geospatial software, it's the only influence I have." You were on the committee, and could have stayed there, and veto'ed graduation till you felt reasonable steps had been taken. I would claim that OSGeo is a do-ocracy, and you could have had a direct influence if you had wanted to. Second, the Mapbender PSC does have a functioning, albeit lightly used Sourceforge bug tracker. In a Mapbender PSC meeting they discussed it and agreed to encourage use of the bug tracker in the future. I'll agree this isn't quite the same as demonstrating a culture of using the bug tracker, but we made a call that this was a reasonable step in the right direction. Third, while two of the GDAL's PSC have subcontracted to me in the past, I don't think they are terribly dependent on me. However, I did select the initial PSC I did based in part on them being folks I felt were comfortable with how the project works, and I could work with fairly well. In the past I have described this as "packing the PSC with my cronies". In the Apache process they stress the need to take "ability to cooperate effectively" as an important criteria for their equivelent of PSC membership. In other venues I think I might deliberately try and include a wide diversity of views in a democratic group, but I don't feel especially constrained to do so for software projects PSCs which need to have quite a degree of mutual trust and respect to operate effectively (IMHO). I do feel that each of the members brings experience and a unique view point even if they aren't dramatically divergent. And they have all been willing to beat me into more progressive approaches in the past. Best regards,