MS RFC 46: Migrate Website to OSGeo

Author:Howard Butler at


Developers and users have expressed dissatisfaction with the current MapServer site, the site rather poorly serves the needs of the project in many instances, and its maintenance and upkeep is limited to a single system administrator (Howard Butler). This RFC will aspire to replace the current MapServer website with a hybrid setup that is similar to the infrastructure that the OpenLayers currently maintains.

Failures of the Current Website

The current MapServer website could be considered the 2.0 version of the MapServer project’s web presence. The 1.0 version of the website was a completely static. The current version of the website looked to allow through-the-web editing to lessen the burden for documenters. Over three years into the effort, it is pretty clear that the website has not had the desired effect with respect to documentation, and it is getting in the way of the project doing other business.

Administrative Failures

Our uptime has been ok, but one effect of the current setup is that no one except Howard Butler takes responsibility for our web infrastructure. Part of the reason for this is there are no other Plone admins that have volunteered time in the MapServer community in the three plus years the site has existed, and part of the reason is that Howard bootstrapped the 2.0 version of the site and it was easy to leave it in his hands. Howard doesn’t have the time to be able to keep things up at anything over a subsistence level, and administration of MapServer’s web presence must be distributed if we are to achieve any progress.


A survey that hoped to determine if the community had any feelings about how the site is currently serving the community was rather inconclusive. While generally positive about the site, the self-selected sample size of eighteen dwarfs the nearly three thousand mailing list subscribers, and I am uncertain what was expressed captures the general sentiment.


Here are some goals that the 3.0 version of the MapServer website should achieve:

  • Make it easy for folks to find the docs
  • Stay out of developers’ way
  • Allow documenters to get their job done
  • Allow limited user-contributed information in the form of wiki pages
  • Have a gallery that works better
  • Move off of UMN computing and integrate within OSGeo’s infrastructure

Make it easy for folks to find the docs

Some people have complained that it is difficult to find documents on the website unless you know the exact place in the hierarchy. Because our mind-reading webpage finding software isn’t quite up to snuff, the new website should make it easy enough for documenters to organize and reorganize information in logical and interlinked ways. It seems the strictly-enforced hierarchy causes more problems than it solves in this regard.

Stay the out of developers’ way

The current website is quite slow. Slow to edit, slow to view, and slow to change. There’s lots of pointing and clicking involved to do the simplest tasks. So much so, that folks will only update the website when they absolutely have to. Developers have subversion access by definition of being developers. They should be able to edit the website through text files in subversion and have the website be updated automatically.

Allow documenters to get their job done

The website fails documenters in a number of ways, but the most important failure is the inability to tie documents to specific MapServer versions. A new iteration of the MapServer website must allow this to happen. Luckily, we already have tools to version documents (our source code repository), so we should just leverage that to accomplish this goal.

Allow limited user-contributed information in the form of wiki pages

From time to time, users do contribute significant documentation describing how to accomplish a particular task with MapServer. Our new infrastructure must still allow this to happen without too much friction. MapServer’s Trac instance already provides this capability (along with single-signon), and we can take advantage of it to accomplish this goal.

Move off of UMN computing and integrate within OSGeo’s infrastructure

Just recently (Sept 15th – Sept 16th, 2008), the server that houses the site was having power supply unit issues (they have been resolved), but it is a fact that the site is running on a very old Solaris machine that could be decommissioned at any point without much of a head’s up. MapServer no longer brings grant monies to the UMN, and while they have been gracious to continue hosting us, we need to move somewhere where we have more control over our destiny. Reasons like this are exactly why OSGeo exists, there are resources there for us to use, and we should move the website there at the same time.


We are going to unabashedly rip off OpenLayers’ web infrastructure. This includes the gallery, static website, and Trac integration. OpenLayers’ web infrastructure meets a lot of the goals above, it stays out of the way of the developers and does a good job of serving the users’ documentation needs. The mechanics of how this transition will take place are described below:

  1. Migrate everything in to Trac and add redirects of /development to a landing page on the Trac wiki.
  2. Migrate everything in to Trac and add redirects of /community to a landing page on the Trac wiki.
  3. Migrate everything in to Trac and add redirects of /download to a landing page on the Trac wiki.
  4. Stand up an Apache instance for MapServer on OSGeo infrastructure. Howard will coordinate with OSGeo’s System Administration Committee to get this done. Our new URL will be
  5. Stand up an instance of the OpenLayers Gallery at and port over our existing gallery entries. Any culling of these entries must be done by some volunteer effort.
  6. Migrate existing documents (notice of when to be given) in /docs to Subversion All subsequent editing on major MapServer documents from that point forward should happen in svn, and the documents on the Plone website will be considered frozen.
  7. Stand up a cron process that takes the docs in Subversion and generates a static HTML website from them. This website will be what exists at