On May 6, 2008, at 3:10 PM, [EMAIL PROTECTED] wrote:
In the past i've heard it suggested that really successful open source projects now need serious organisational backing. They can't be built by a network of partly-funded enthusiast contributors alone.
I think really successful open source projects are successful because of serious organization, not necessarily a fire hose of funding. By serious organization, I don't mean a rickety scaffolding of bureaucracy. OSGeo's incubation process prescribes a bureaucracy (project steering committees) onto projects to be accepted as part of incubation. Some projects within OSGeo embrace this whole heartedly, while others continue their lieutenants' model or dictatorship due to those being active ending up making the decisions -- with the checks and balances the PSC approach hopes to achieve (no project as far as I know has had such a knock-down, drag out to actually test this assumption). The incubation process tries to prescribe the PSC model because it desires that incoming projects "be organized" in such a way as to be able to keep its own house in order in the event of problems that affect its open development. I think development organization is what sets apart one blob of source code from another where both might do the same thing. I think OSGeo wants projects that are thriving communities for a number of reasons, but I'll leave it up to others to decide if we actually meet that bar with all of our projects.
Serious organization requires infrastructure -- something that's easy enough to get these days (SourceForge, Google dev, even OSGeo if you can jump through the hoops) -- but more importantly, it requires *use* of that infrastructure. One thing that I have found out recently when developing on a small open source project (http://liblas.org) is that Brook's notion about geometric communication load applies. With a one or two person project, does it make sense to file every notable change into a bug tracking system, ensure that changesets only deal with one specific issue, and avoid communicating about design and code organization in forums that do not log things for posterity? The overhead to do that stuff is fixed, and quite expensive especially considering that you only have one or two folks writing the software hoping to get it to a functional point. Without it, however, interested parties have no real way to empower themselves into becoming active contributors to the project without drawing significant load from the active developers. Because developers come and go to a project, this process repeats itself unless the project itself makes it possible for people to bootstrap themselves -- a long term investment unlikely to pay off at all in the short term.
If a project has a given amount of momentum, marketing resources applied to it, a contributing user community; is there any sense in "competing" by building something new with a lot of conceptual overlap? If there isn't, don't de facto monopolies start to develop inside FOSS as much as they do in proprietary software systems?
There sure is a reason to compete -- to build (or aspire to build) a better product. MapServer, for example, has Mapnik. I think Artem's quest to show us how wrong we were has had a positive impact on both projects (speaking as a MapServer dev). Each software does different things better, and both projects have driven innovation in the other. I would say that Mapnik still doesn't have all of the inertia that MapServer enjoys, and I think it suffers from some of the organizational challenges I described above (MapServer too), but from my perspective it has been steadily gaining steam and meets any definition of open source success. It hasn't needed OSGeo to have an impact.
MapServer and Mapnik overlap in a lot of conceptual areas, and there's plenty of room for both. What there isn't plenty of is C/C++ developers who wish to develop open source GIS rendering software for web applications. I would argue that if there are any monopolies to be gained in open source software development that they are monopolies of developers' attention, not monopolies of software products.
Howard _______________________________________________ Discuss mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/discuss
