Hobu, Inc.

Attempt #1 - Try to install it on OSX Server’s JBoss (45 minutes)

My machine meets all of the requirements of the Install Mac OSX document on the site. I tried following the scant document, even interpolating some necessary things like changing file permissions and ownership when needed, but I was never able to get it working this way.

Attempt #2 - Try to install it directly in a fresh Tomcat (45 minutes)

Next, I thought it my be prudent to try install in a fresh Tomcat instance, as this would likely be the most common configuration and installation of Tomcat. I got Tomcat working and I grabbed the geoserver.war file and dumped it into webapps. Restarted Tomcat and went to ./geoserver and got nothing.

Attempt #3 - Try to install the packaged binaries (geoserver-bin) (1 hour)

After converting the linefeeds of the startup scripts (dos linefeeds in a shell script that supposedly starts the server is inexcuseable) and following the documents for setting, java finally dies with a bunch of java.lang.NullPointerExceptions.

Update: After some more tweaks, pops, and pokes and synthesizing the Geoserver wiki into my neural network I was able to get this approach to work.

My Failures

• I’m impatient and I don’t like to read documents. Geoserver caters to me because there isn’t that much to read.
• I’m running OSX, which evidently isn’t a common configuration. Java’s java, and it is supposed to run everywhere though, right?
• I’m not a java developer, so I don’t have the experience to weather common trip-ups that a developer would have.

Geoserver’s Failures

• Wikis are horrible for project documentation. They are by nature divergent and the result is conflicting information. I would much rather have a single document that is precisely wrong once than four or five documents that are imprecisely wrong in different ways. As a naive user, I have no way to descriminate between the various bits of information and determine which are right, which are wrong, and which are current.
• Geoserver’s (this is probably just java in general) packaging is very spartan. It and the documentation assume I actually know what I am doing. The common use case of dumping things on a windows box appears be covered though, so maybe that covers 99% of the users, and I’m just in a very small minority.

You could argue that I’m an impatient, no-documentation-reading, know-nothing user who hasn’t spent enough time with the project and you would be right. These attributes still should prevent me from getting something going and seeing what it is about. Good packaging is hard. Good documentation is hard. Do people have exactly these same frustrations when they start out blind, naked, and dumb with MapServer too?

Update #2 I maybe just didn’t spend enough time and was too impatient, because after three or four hours I was able to get things to work. The problem of not having sexy or straight-forward enough documentation and packaging for open source software can make the barrier quite high. I know that most of the open source GIS projects I’m involved with continue to have this problem as well (my rhetorical question about MapServer notwithstanding). Starting again with an unfamiliar project with fresh eyes highlighted how frustrating this can be. I have no suggestions how to fix it though, as writing documentation, packaging software, and maintaining project websites is not egoboo-generating work. Maybe someday the firehose will point at these projects and these issues will all just go away

The terms “Open Source” and “Free Software” almost always describe the licensing state of a piece of software. For the software projects that they are attached to, they describe a crucial attribute — your rights as a software developer and user to read, modify, build on, and use the source code of a project for your uses. “Open Source” and “Free Software” are also implicitly attached to the concept of an open development process — the software is worked on, improved, and distributed by a self-selected group of developers to the benefit of all — but this is not always the case. This article will describe and discuss the development processes of four projects that I am familiar with in the Open Source GIS domain and will describe the role that I think that OSGeo should provide in ensuring open development for its member projects.

Karl Fogel’s “Producing Open Source Software” is *the* book to read on this topic. It is the handbook of open development, describes the attributes of successful open source project that is openly developed, and it even covers sticky topics like how to work through issues like money entering the project, forking, and governance. If you get a chance, I highly recommend you read through it, if to only become familiar with the attributes of open source projects with respect to development and cues to help you evaluate them.

ERMapper’s ECW

During the summer of 2005, ERMapper released the software to their wavelet compression/decompression engine called ECW. While the source code is technically open, the licensing terms do not meet any of the requirements of any of the mainstream open/free software licenses, and by all accounts, the development process of ECW is anything but open.

My opinion is that ERMapper is in limbo with respect to opening ECW. They want outside contribution, especially with respect to building and deploying the software and fixing bugs, but they are concerned about their format and its possible divergence from the tons of data already out there in ECW format. The possible licenses you can assume and fall under reflect this ambiguity, and each variant of the license reflects what you as a *user* can do with the software.

As a developer, your only real option at this point is to not bother. According to Fogel’s criteria, ECW meets hardly any of the attributes of a successful open source project:

• There is no common public source code repository.
• There is no development mailing list.
• There is no public bug tracking.
• There is no public history of development — why the software is the way it is.

I think a project like ECW (or even MrSID) has the potential to be a highly impactful open source project that can reach beyond the geospatial domain. Wavelet compression is becoming an important topic, and participation in a project that utilizes this has the potential to catalyze and seed many other development efforts. Hopefully, ERMapper will see that their worries about format divergence will actually be mitigated by a truly open development effort. Time will tell on this one…

Refractions’ GEOS

GEOS has an interesting history. It started as a port of JTS to the C++ platform by Refractions. It is the geometry engine underneath PostGIS, and it is used by many other open source projects in the ‘C’ camp of open source GIS to provide topology and geometric algebra operations. Licensing-wise, it meets the criteria of open source software, and it is licensed under the LGPL (there is no explicit LICENSE.txt in the source code, but each source file is described as “licensed under the LGPL”).

Here are the attributes of Open Development that GEOS has:

• A source code repository
• A public bug tracker
• Development list
• Website

GEOS meets most of the criteria listed in Fogel’s book, but in my opinion it is missing couple of key components to truly qualify as open development (disclaimer: I am a source code committer on the GEOS project). First, it really has no community-oriented governance model. The project leader is ostensibly a maintainer that is paid by Refractions to organize and push forward GEOS’ development. Major developments must be vetted by Refractions (and frequently funded through Refractions) before they can be undertaken. Releases are made to serve Refractions’ business needs (PostGIS or client-funded improvements). These attributes make GEOS risky from the perspective of an individual, independent developer because your investment in GEOS as a developer may be thwarted if it is not in line with the interests of the company that “owns” the project.

A quote from Fogel’s money chapter illustrates this point more elegantly than I can:

However, funding also brings a perception of control. If not handled carefully, money can divide a project into in-group and out-group developers. If the unpaid volunteers get the feeling that design decisions or feature additions are simply available to the highest bidder, they’ll head off to a project that seems more like a meritocracy and less like unpaid labor for someone else’s benefit. They may never complain overtly on the mailing lists. Instead, there will simply be less and less noise from external sources, as the volunteers gradually stop trying to be taken seriously. The buzz of small-scale activity will continue, in the form of bug reports and occasional small fixes. But there won’t be any large code contributions or outside participation in design discussions. People sense what’s expected of them, and live up (or down) to those expectations.

The second, and more important divergence in my opinion, is that the head of GEOS is disconnected from its body. Definition of *how* the software is supposed to work — design and architectural decisions — actually comes from JTS. Strict adherence to the “C++ port of a Java library” mindset, and GEOS’ insistence on following JTS to the letter instead of in spirit means that technological advantages that C++ could provide can’t really be taken. There’s no feedback loop so that possible improvements made in GEOS make their way back to JTS. GEOS is the way it is because JTS is that way, and JTS defines what GEOS is. As a developer, only small improvements and changes can be made, as long as the parallelism between GEOS and JTS is not broken and the changes are in line with Refractions’ interests, and these restraints, in my opinion, causes internal forking efforts to happen and retard the development of GEOS in what it aspires to be — a fast, correct, C++-based open source library for geometry and topological operations.

Frank Warmerdam’s GDAL

GDAL meets most of Fogel’s criteria for an open development project (disclosure: I am a committer and PSC member on the GDAL project). It has a source code repository with history going back almost to the first day that Frank checked code into the project. It has a bug tracker with thousands of bugs (most of which are labeled as “fixed”). It has a very active user community, a documentation website, and an IRC channel.

GDAL has historically followed the Linux model, where most changes go through Frank, and lieutenants are left to be in charge of certain areas of the software. From an open development and governance standpoint, GDAL is currently in transition. While we all believe that Frank has a time stopping machine hidden up in the deep Canadian woods with him that allows him to be so prolific, there are limits to what one person can do, and GDAL is increasingly approaching them.

The move to OSGeo for GDAL has brought about the emergence of a Project Steering Committee, and Frank has relinquished outright dictatorial control of the project to it. The release process is slowly moving to a more community-oriented affair, and members of the GDAL development community are stepping forward to take care of maintenance of larger areas of the software. Sweeping technological changes and addition of features now go through a proposal and committee process to ensure that everyone can be made aware of such developments. Explicit communication (and the implicit history this creates) about these things ensures that developers on the project are roughly moving in the same direction.

UMN’s MapServer

In my opinion, MapServer meets Fogel’s criteria for an open development project (disclosure: I am also a committer and PSC member on the MapServer project). Unlike the other three projects that I described which are targeted almost exclusively toward other application developers, MapServer’s audience is both user-oriented web developers and some standard GIS-type application development. This diversity manifests itself throughout the project, most notably in the governance structure and developer community, which I have already described MapServer’s in a previous post. It also contributes to MapServer’s creeping featuritis that is both its blessing and its curse.

Frank’s MS RFC-1 has become one of the prominent models for project governance in OSGeo, and many of the member projects have copied or modified it to fit their culture and needs. MapServer has a ring (or two) of businesses that use it to their competitive advantage. Funding opportunities that arise from this ring feeds back into the software in the form of new features, general maintenance, documentation, and maillist support. Many of the businesses in the ring are represented in the PSC of MapServer. The project soldiers on, despite individual developers coming and going, and it still sees significant growth release over release as measured by software downloads, maillist posts, and bug submissions.

I think that MapServer is a very functional, but slightly imperfect model of open development. There are things described in Fogel’s book we aren’t doing yet, or aren’t so good at, but we’re open to suggestions and highly motivated individuals can have a lot of impact on the project. Technologically, the MapServer project is fairly conservative, and its not prone to withstand or put up with large refactorings. Its governance body is not elected by the community in an effort to sidestep the sticky issue of determining *who* the community is and if they have a right to vote on such things. Its diverse audience and diverse developer base pulls the project in many directions at once, and its focus, as defined by “MapServer is not a GIS!” leaves an awful lot of room to define what it actually is.

How OSGeo can play a role in ensuring Open Development

Hop on the bus, Gus

An important part of a project’s migration to OSGeo and its incubation is the codification of its governance culture. One goal of this governance is to increase what Sean calls the “bus number,” or the number of developers (or entities) a bus would need to run over to kill the project. I think it is important to make a fine distinction between the bus number of the project and the bus number of the software because they might not always be the same. OSGeo should aspire to ensure that the bus number of its member projects is much greater than one entity or person. In fact, I think this should be a requirement that must be met for incubation — if a project can’t satisfy it, it should be clear that there isn’t enough community support for the project to keep it viable. The problem, of course, is actually measuring the bus number of a project is a rather messy endeavor

Mo’ money, mo’ problems

Money coming into a project, as Fogel devotes an entire chapter to, can create significant tension within a project. In my opinion, an overriding incentive to form OSGeo by its initial member projects was money — in the form of direct support for the projects through some kind of collective pass-through funding, money for visibility and marketing and the leverage that an organization like OSGeo can provide, and money in the form of member projects sharing infrastructure that is common to all and commonly replicated. OSGeo must be clear, explicit, and careful about how money is distributed (if there is any to distribute). Perception is reality in this instance, and any shady stuff will probably be met with significant backlash.

Insight, foresight, more sight

Another role of OSGeo is to provide infrastructure to mitigate disputes and provide a neutral home for the project that is agnostic with respect to a specific entity. OSGeo could act as the grown-up in the case of intra-project disputes like Apache has done in the past. It aspires to act as the facilitator, in hope of congealing its member projects into a mass of non-overlapping, useful, and integrated technology. Finally, it can act as an educator, introducing the technology of its member projects and providing buoyancy in a way that a single project by itself could not do.

Conclusion

Some final thoughts for those of you who’ve actually read this far. Open source projects, even in the GIS domain, vary widely with respect to their development practices and how open or closed they are. As an open source developer, volunteer, and user, I’m attracted to projects that are openly developed. I will not invest much effort in something where my stake, in effort, is not recognized and respected. Finally, a significant measure of OSGeo’s success or non-success in my mind is how good of a job it does at fostering and ensuring open development of its member projects.

Update:

Please head to SlashGeo if you’re interested in commenting on this article. Still haven’t found a good solution to comment spam for my weblog yet.

Dear ESRI,

Please listen to us. We’re your cold, poor, hungry, and sometimes taken advantage of third party developer community. We don’t get to sell $56 million of services and software to the federal government each year. We live with much smaller budgets, much shorter timelines, and much higher expectations. Like those of any software company, you have some products that are fantastic, some of them that are mediocre, and some of them should have never been sold to the public. One of the products that I think is really fantastic is a piece of spatial database middleware you bought a while back called ArcSDE. Lots of your customers use this product to do lots of really neat things. And I would like to use it to do allow my customers to do some really neat things with the software they bought from you.

I’m part of a group of developers of an open source library called GDAL (Geospatial Data Abstraction Library). I like to call it the libc/libc++ of geospatial software. It’s used everywhere, it takes care of the dirty job of raster data translation, and it allows people to write fantastic software.

I would like to write a driver for GDAL that can read ArcSDE raster data so people can do fantastic things with the petabytes of raster data that is stored in ArcSDE throughout the world. To use this driver, people would still have to purchase an ArcSDE license from you. In fact, the ability to use ArcSDE raster data from GDAL might allow you to sell ArcSDE licenses you might not otherwise have sold.

With a shortage of funds and no shortage of id, I set to writing a proposal for implementing the driver for my client. I had heard about the EDN program last summer, and it was my understanding that I would be able to get a temporary (one year) license to be able to use ArcSDE for this type of development. After some investigation, I came across some show-stopping issues with the EDN license that cause a lot of concern.

The first part of the license (which for some reason has PDF copy protection and doesn’t allow me to copy-paste out of it) says:

Licensee shall not reverse engineer, decompile, or disassemble the Software, Data, Web Services, or Documentation, except to the extent that such activity is expressly permitted by applicable law notwithstanding this restriction.

The license doesn’t say if I’m ever released from this restriction. If I sign this agreement, does it mean that I can not ever participate in reverse engineering any ESRI software in perpetuity? A lot of my problem with this restriction is that it depends on what’s being called “reverse engineering,” and in my experience a good portion of software development *is* reverse engineering in the sense that you are trying to figure out what another developer did, why a piece of software works the way it does, and how you as a developer can work with, around, and through it.

The second part of the license, the EDN-specific part, has a few things that cause me to pause:

Licensee may grant access to server applications developed using the EDN Software Library to Licensee’s customers and internal users for acceptance testing purposes only; provided that Licensee’s customers and internal users will not perform any debugging, configuration, or maintenance.

…

Publicly disclose results of benchmark testing except with prior written permission of ESRI.

What does this first part mean? For something like the ArcSDE raster driver, my client is other software developers. The only way they can reliably do acceptance testing *is* to jump in and debug what it is doing. I understand not using EDN software for configuration and maintenance (well, maybe), because you don’t want folks using the cut-rate EDN software to do “real work.” My problem with a restriction like this is that it appears to prevent someone like me from using EDN to do *any* work.

With respect to benchmark testing, why are you afraid to have unabashed results of how your software performs out in public?

Broad, complicated (I had to spend an inordinate amount of time tracing through multiple layers of footnotes) licensing agreements like the ESRI general and ESRI EDN ones scare your developers away. Third party developers provide you with value, momentum, and a pool of potential talent to poach from. A large wall of legalese causes casual folks to not bother. If you’re ever looking to garner the momentum, energy, and hype of the GYM neogeographers and masheruppers, you’ll never get it by making them sign to twelve pages of stuff like this. It won’t matter if your software is fantastic or not.

Hopefully, someone from your company will stumble across this weblog post and be able to answer a question for me. I don’t have any licensing or maintenance agreements with you, but there is some financial incentive for you to do so because, like most of your third-party products, I think an ArcSDE raster driver for GDAL will sell you more licenses of your software.

As an independent developer, is it possible for me to use an EDN seat to develop a raster driver for GDAL?

Sincerely,

Howard Butler,

Hobu, Inc.

See you at FOSS4G

Adena linked to an article this morning that highlighted a web mapping application that was developed by ZedX for the USDA to track Soybean Rust infestation. Soybean Rust is a fungal disease that has had a significant economic impact in South America, and worries of it disrupting US soybean production have prompted many monitoring activities and efforts. Web maps are an excellent way to communicate these monitoring efforts. The article stated that $2.5 million were provided to fund this specific project, and although I’m positive all of that funding didn’t go to ZedX for the development of the website, a significant portion surely did.

The article is typical press release-like fanfare except for the interesting bit about MapServer:

”
The soybean rust system is an open-source, Linux system. Other than the
open-source code and the MapServer GIS mapping applications, ZedX has
written the code, Russo said.”

A search through the MapServer maillist archives (by the way, the MapServer project really needs to fix our archives, they’re atrocious) showed a few posts by ZedX folks asking normal technical questions about compilation or usage of software features. I couldn’t find or I can’t recall ZedX funding any specific MapServer enhancements or contributing developer/documenter time (if anyone knows of any activities that were supported by ZedX, please let me know and I’ll update this article).

I think it’s great that a company like ZedX can use MapServer to provide them with a significant competitive advantage. I also think that stating that MapServer is their secret sauce is great visibility, and articles like that contribute to the project in a roundabout way. I just find it disheartening that for a 2.5 million dollar project, nothing (no direct funding, contributed time, or contributed documentation) found its way back to the software that was an integral component in making it tick.

$5000 to certain software companies gives you a license to run the software and maybe a couple of phone calls to ask why it doesn’t work. $5000 to an open source project like MapServer gives you specific rendering improvements you might like, possibly a data driver to read specific data you need (that the other software tool can use either), streamlining of not-so-fun-to-develop-on components of the software, or even completely new features that the software didn’t have before. $5000 of contributed time can get you documents of poorly documented features, funds the addition of your own specific features, or anything else you might need. These contributions not only benefit you the contributor, but also benefit anyone using the software and directly supports the developer(s) who work on the project — perpetuating development and contributing to its vitality.

It is my hope that OSGeo will be able to provide a clearinghouse for contributions to its member projects and solves the issue of “great, I have some money/time/resources to contribute, who do I give it to?” Also, the ability to pool contributions together for larger efforts is something that is sorely needed. Those efforts are just getting off the ground though, and time will tell if that approach will be any more successful than individual-to-individual or individual-to-project contributions.

In a lot of areas, open source software is about leverage… leveraging collective knowledge, leveraging resources, and leveraging effort. Contributing to an open source project that is an integral component of your development strategy gives you and the project leverage — all for frequently less than the cost of a seat of some commercial tools.

When I first started working with GDAL, MrSID images were all about, and it looked like it was becoming the emergent standard for wavelet compressed geospatial imagery. I railed and complained rather loudly when I found out that I couldn’t just download the DSDK and start working with the imagery. Eventually (I don’t know if my squawking actually had any impact), LizardTech made the DSDK available for free download (requiring registration and EULA reading), but the DSDK had some somewhat onerous clauses in its license that prevented packages like FWTools, MS4W, QGIS, and GRASS from distributing the DSDK libraries. This left users in a tough spot and placed extra burden on developers to repackage software in such a way that “plugin” approaches could be used (individual users had to download the DSDK themselves and set some magic switches).

Michael Gerlek of LizardTech sat next to myself and Frank Warmerdam at the Februrary 4th bootstrapping meeting of OSGeo. We took the opportunity to describe some of the issues we had with the DSDK license and how it caused hang-ups for purveyors of binary builds. Later, as LizardTech was preparing for the latest release of the DSDK, Michael contacted Frank and I so we could describe the issues we had.

• Allow the redistribution of DLLs, .so’s, .libs, and include files so things like the “buildkit” can be distributed with the DSDK. The MapServer Buildkit allows users to build MapServer/GDAL on Windows with MSVC 2003 by providing most things pre-compiled/configured so folks can tweak the options that they need in MapServer/GDAL.
• Focus sections about promoting and branding MrSID to be specific about the browser plugin, not the entire DSDK.

Expect to see the MrSID DSDK distributed widely with your favorite Open Source GIS tools in the coming months….

Head to http://developer.lizardtech.com to get a copy if your interested.

PS. LizardTech, please ship the source code to the DSDK so we can compile it for all sorts of weird platforms and give you bug reports

Mac OSX (and all? BSDs) provide a kernel event notification mechanism called kqueue. Other operating systems provide a similar sort of notification system, but OSX’s is the only one I am interested at this time. I did find a rather interesting cross-platform notification library called libevent-python, which attempts to provide a unified API, but it appears to be geared toward network communication and not toward file system notification.

Here’s a BSD-licensed class that can be used to watch a directory. It requires the PyKQueue from hpio.

import osimport kqueueimport sets

class DirectoryChangedException(Exception):    pass

class Watch(object):    def __init__(self, directory):        self.directory = directory        self.dirfd = os.open(self.directory, os.O_RDONLY)        self.filter = kqueue.EV_ADD|kqueue.EV_CLEAR|kqueue.EV_ENABLE        self.event = kqueue.Event(self.dirfd,                                  kqueue.EVFILT_VNODE,                                  self.filter,                                  fflags=kqueue.NOTE_WRITE|\                                         kqueue.NOTE_DELETE|\                                         kqueue.NOTE_EXTEND,                                  data=self.dirfd)        self.kq = kqueue.kqueue()

    def watch(self):        self.files = sets.Set(os.listdir(self.directory))        self.adds = None; self.deletes=None; self.changed=None         while 1:            events = kqueue.kevent(self.kq, [self.event], 10, None)            if events:                new_files = sets.Set(os.listdir(self.directory))                self.deletes = list(self.files.difference(new_files))                self.adds = list(new_files.difference(self.files))                self.files = new_files                raise DirectoryChangedException, \                      “Directory %s changed…” % self.directory    def __del__(self):        os.close(self.dirfd)

One way to use it is as so:

import watchw = watch.Watch('/Users/hobu/foo')

while 1:    try:        w.watch()    except watch.DirectoryChangedException:        adds = w.adds        deletes = w.deletes        print "added files: ", adds        print "deleted files: ", deletes

It seems my post caused a bit of a stir. Andrew Hallam has the most complete linklog of the discussion. Here’s an update on what’s currently going on:

• The copyright/spec licensing issue is gone. This was an oversight, not malice.
• In private email, I was assured that by playing within the OGC, GeoRSS would not be “locked out” in the sense that individuals who cannot join OGC cannot participate in the standard development. We’ve yet to see details on how exactly this would work given that it is incongruent with the way OGC currently operates, but nonetheless this is encouraging.
• The mechanics and details of how exactly the “edge”, as Ed Parsons puts it, is supposed to interact and collaborate with OGC still make me a bit nervous.
• I still think that GeoRSS is/was being used as an OGC membership marketing opportunity for places like Where 2.0.

I can appreciate that GeoRSS would be somewhat new ground for OGC, especially given that it is one of a number of geo standards that was mostly developed outside the direct realm of influence of the OGC. I’ll also gladly give OGC credit for having a mostly positive influence on the industry, but I would state that the job isn’t done yet. Interoperating down in the trenches with member’s implementations is still a rough, unforgiving, and frequently frustrating experience.

Maybe whether or not OGC shepherds GeoRSS will have no impact on how it is implemented, but for me, as a developer, a member’s self-proclamation of “OGC support” can often mean an incomplete, inconsistent, and unfulfilling experience. The simplicity of GeoRSS makes it brain-dead simple to avoid repeating that experience. In that sense, GeoRSS going into the meat grinder of OGC still makes me a bit nervous that there is the potential for what goes in might not be the same thing as what comes out.

Errata

Ugh, Plone gave me fits this weekend as I was updating to a new version. I ended up re-publishing all of my entries again, causing a very public spamming of Planet GeoSpatial. I think things are mostly in order now. If you find something drop me an email.

Also, I do not allow comments and trackbacks on this weblog because I’ve no patience for dealing with the spam. Everyone has a weblog these days, right?

One area where the OGC model of standards development miserably fails is in the world of geohackers, enthusiasts, masher-uppers, and open source developers (see this Directions Magazine article for more background on OGC’s sometimes conflicting roles in the GIS industry). OGC is a membership organization, and even though they might have a lot to contribute to the discussion, individuals don’t generate any revenue for OGC and aren’t allowed to join. But the geohackers don’t really need the overhead of OGC either. They have the tools they need to develop a standard at their fingertips — an email list, a spirit of cooperation, a text editor, enthusiasm, and example applications. Raj Singh, Josh Lieberman and Allan Doyle demonstrated this by leading and coalescing the development of GeoRSS through EOGEO maillists.

The OGC is a faith-based initiative. The OGC is an industry-based organization that agrees upon GIS standards behind closed doors, releases (some of) those standards to the world, and hopes that members (and third parties) implement those standards to the specification. There is a certification process where an organization can buy a stamp of OGC approval for their application or implementation. Not every application or organization that participates in OGC has the official stamp, however. The implementation of OGC specs for the large GIS vendors historically has been uneven at best, with bits and bytes dangling about — giving the hope and appearance of interoperability but ultimately failing to deliver on the promise. In fact, in many ways it has been the small vendors and open source implementations like MapServer and GeoServer that have carried the torch of true OGC interoperability.

Yesterday, Carl Reed of OGC stated that he had posted the contents of most of the GeoRSS website as a white paper for specification consideration within the OGC. This is problematic for more than a couple of reasons, as Allan outlined in his response. First, I don’t think that GeoRSS ever asked to be an OGC standard. Second, the OGC white paper completely disregarded the Creative Commons license and claimed “Copyright © 2006 Open Geospatial Consortium, Inc. All Rights Reserved.” on a document where most of the contents were generated by the participants of the GeoRSS list and website. Third, even if there was popular interest by the members of the GeoRSS list to have GeoRSS be an OGC standard, a significant portion of them would be locked out of the development process because individuals can’t be members of OGC.

This move by OGC is very troubling. It appears the OGC leadership are trying to take the GeoRSS standard, which the members of georss.org developed out in the open, and stick it behind the OGC firewall in an attempt to gain membership revenues and derivative revenues (if there ever are any, ala Dave Winer and the sale weblogs.com to Network Solutions) from GeoRSS. Maybe they are trying to get on the Web 2.0/Where 2.0 bandwagon, but I don’t think shooting the driver (georss.org) and holding the wagon ransom (buy an OGC membership and you’ll get to participate) is an even remotely reasonable way to go about it.

Hopefully, I’ve got the story completely wrong and the old saw about “never attribute to malice that which can be explained by incompetence” applies in this case. Either way, the situation stinks.

After our initial Feb 4th meeting, things have been happening quickly. In fact, I think one of our biggest hurdles is that we are running up against Brook’s Law, ie communication costs increase with the square of the number of participants. Many folks are talking about many things all at once. The amount of brain and network bandwidth required to follow everything has been pretty daunting. An daily inbox with a 100+ messages related to OSGeo is a significant commitment just by itself.

One concern that I have is organizationally whether or not OSGeo has the potential to wither under the weight of the communication load. A corporation has the nice advantage of being hierarchical, for better or worse. OSGeo is a “by consensus” organization, but democracy is expensive from a communcation perspective. In the intial bootstrapping, lots of communication cost is placed on the board and many consensus decisions must be made by it.

Getting there (wherever we define “there” to be) is going to be challenging and a lot of work for the board. The board is working to delegate to various committees within OSGeo, but geometric growth of committees only increases the number of things clammoring for their attention. Add in many projects individually chirping for attention, and things can start to get out of hand.

It is my hope that after the mad rush, things start to settle down into a less hectic mode. Part of this rush is finding out what organizational structure works the best for us, as we are attempting something that hasn’t really been done before (take a bunch of open source software projects under different licenses and bring them under one tent). We’re learning though. Openly.