Added by Cameron Shorter, last edited by Cameron Shorter on Jan 20, 2008  (view change)

Labels:

Enter labels to add to this page:
Wait Image 
Looking for a label? Just start typing.

Purpose: Specify Mapbuilder long term Goals and outline roadmap for achieving them.

  1. Introduction
  2. Criteria for a successful project
  3. Metrics
    1. Download Metrics
    2. Email Traffic Metrics
    3. Subversion Commit Metrics
  4. Requested Improvements
    1. Speed up downloads
    2. Simplify user setup
    3. Improve look and feel
    4. Improve Google Search ranking
    5. Access Google maps
  5. Roadmap
    1. Regular Stable Releases
    2. Integrate with similar projects
    3. OSGeo and Marketing
    4. Project Management Structure
    5. Documentation
    6. Fast demo site
  6. Previous Strategic Direction Papers

Introduction

This document summarises the state of the Mapbuilder project and it's relationship with projects around it, identify upcoming features and opportunities, and suggest where to focus future effort and funding to maximise Mapbuilder's potential.

Mapbuilder downloads doubled in the month after OSGeo was created with Mapbuilder as one of the founding projects. We need to continue with these marketing efforts. To facilitate this, we should encourage users to join the Project Steering Committee.

Mapbuilder has lots of great features in the trunk which have not been released yet. This is reducing the uptake of Mapbuilder. We need to put out releases again.

There are a number of AJAX Web Mapping clients and not all of them will thrive. In particular, OpenLayers is addressing the simple mapping use cases and is cutting into Mapbuilder's potential user base. We should set our development path toward merging with OpenLayers.

Criteria for a successful project

Refraction's State of Open Source GIS provides an excellent checklist for evaluating open source projects.
The more of these questions which are answered in the positive, the healthier the OSS project under examination is.

  • Is the software modular?
    (This criterion is more applicable to some projects than others, depending on design constraints.) Is there a clear method to add functionality to the project that does not involve re-working the internals? Is this method documented clearly with examples? Is there a library of already-contributed enhancements maintained by the wider user / developer community?
    • Mapbuilder is modular and extendable from the ground up.
  • Is the development team transparent?
    Is it clear who the core development team is? Is the development team mailing list public? Is the current development version of the code available online? Is membership in the team attainable via a merit-based process?
    • Yes, Mapbuilder has a strong transparent management team.
  • Is the project well documented?
    Does the web presence provide direct access to both the source code and documentation about the internals of the code? Is there tutorial level documentation for all three user categories (user, administrator, programmer) to get people up and working with the software quickly?
    • Mapbuilder's documentation is passable, but effort spent on documentation could greatly improve our users experience.
  • How wide is the development community?
    Are multiple organizations represented in the core development team? Are core team members financially supported in their work by sponsoring organizations? Is the development community national or international? How large is the user mailing list? How large is the developer mailing list?
    • Mapbuilder has between 5 and 10 developers at any one time, and the developers come from around the globe and from many different organisations. This is a strong core, but it would be nice to see the developer community double.
  • How wide is the user community?
    (This criterion is basically a standard COTS criterion more installations imply wider acceptance and testing.) What organizations have deployed the
    software? What experiences have they had?
    • Up to Feb 2006, Mapbuilder downloads steadilly increased to 500 downloads/month. After that, downloads doubled and have remained steady at around 1100 downloads/month.
    • It is good to see this steady growth, however it would be nicer to see the download figures increase by an order of magnitude. I suspect that Mapbuilder has lost market share of simple mapping applications to OpenLayers, GoogleMaps, MSN and Yahoo maps.

Metrics

Download Metrics

This graph shows a steady growth in interest since the start of the project, with a doubling of downloads when the OSGeo Foundation was founded (with Mapbuilder a founding project) in March 2006.


Date Downloads
Apr-04 0
May-04 31
Jun-04 173
Jul-04 115
Aug-04 69
Sep-04 38
Oct-04 40
Nov-04 32
Dec-04 26
Jan-05 54
Feb-05 88
Mar-05 127
Apr-05 160
May-05 213
Jun-05 280
Jul-05 230
Aug-05 221
Sep-05 235
Oct-05 319
Nov-05 332
Dec-05 420
Jan-06 469
Feb-06 536
Mar-06 1,141
Apr-06 1,029
May-06 1,040
Jun-06 1,206
Jul-06 1,213
Aug-06 1,153
Sep-06 1,059
Oct-06 1,346
Nov-06 1,008
Dec-06 869
Jan-07 1,351
Feb-07 1,359

Data Source: http://sourceforge.net/project/stats/detail.php?group_id=35246&ugn=mapbuilder&type=prdownload&mode=alltime&package_id=116388

Email Traffic Metrics

This shows the monthly number of emails for Developer and User email lists. The fact that User emails is less than Developer emails suggests that Mapbuilder is too difficult for users to download and get working and we should focus more on user needs.

A drop in developer activity over the last couple of months is probably due to:

  1. Some time being focused toward incorporating Mapbuilder in OSGeo.
  2. Some corresponding focus on documentation.
  3. Some key developers focusing on applying Mapbuilder to applications rather than extending Mapbuilder.
    Date Devel User Total
    May-03 2   2
    Jun-03 20   20
    Jul-03 24   24
    Aug-03 38   38
    Sep-03 23   23
    Oct-03     0
    Nov-03 10   10
    Dec-03 24   24
    Jan-04 88   88
    Feb-04 200   200
    Mar-04 114   114
    Apr-04 85   85
    May-04 85   85
    Jun-04 191   191
    Jul-04 60   60
    Aug-04 75   75
    Sep-04 53   53
    Oct-04 47   47
    Nov-04 103   103
    Dec-04 72   72
    Jan-05 57   57
    Feb-05 71   71
    Mar-05 153 2 155
    Apr-05 79 15 94
    May-05 121 1 122
    Jun-05 153 14 167
    Jul-05 147   147
    Aug-05 203 3 206
    Sep-05 417 8 425
    Oct-05 267 37 304
    Nov-05 182 14 196
    Dec-05 211 42 253
    Jan-06 363 148 511
    Feb-06 338 108 446
    Mar-06 369 104 473
    Apr-06 128 84 212
    May-06 150 133 283
    Jun-06 128 66 194
    Jul-06 96 82 178
    Aug-06 63 34 97
    Sep-06 71 86 157
    Oct-06 107 59 166
    Nov-06 145 83 228
    Dec-06 182 45 227
    Jan-07 119 75 194
    Feb-07 72 60 132

    Data source: http://sourceforge.net/mailarchive/forum.php?forum_id=44559 and http://sourceforge.net/mailarchive/forum.php?forum_id=475

Subversion Commit Metrics

This graph tracks the number of lines of code in the Mapbuilder repository. The graph shows a that mapbuilder has been steadilly growing since December 2003.

Source data: http://fisheye.codehaus.org/browse/~br=trunk/mapbuilder/trunk/mapbuilder/mapbuilder/lib

Requested Improvements

Speed up downloads

Mapbuilder has numerous Javascript files which are dynamically downloaded at startup. It would be around 80% faster to merge the files into one.

We need a fast demo site. We should look to OSGeo to provide this.

Simplify user setup

  • Mapbuilder requires users to build a config.xml file. This doesn't seem to be intuative for users. A better interface seems to be a Javascript API. We should be our API on the OpenLayers/webmap.js API in order to be consistant and make it easier for users to migrate between projects.
  • To setup OpenLayers/Google/... all you need is a snippet of HTML and a pointer to javascript on the OpenLayers/Google website. We should explain in a simple tutorial how to do this with Mapbuilder. At the moment it seems you need to download Mapbuilder onto the users local machine first.
    We should provide our own WMS server of the world. That way we can collect metrics about the number of users Mapbuilder has and we can ensure that our Mapserver remains stable and doesn't change.

Improve look and feel

Google, Yahoo, OpenLayers have all done good work on usability. We should copy that. In particular:

  • Provide zoom in/out via the mouse wheel.
  • Insert colapsable transparent popups over the main mapPane for various widgets, eg results from WFS Queries, Legends, etc.

Improve Google Search ranking

We should aim to get our website returned as the first site in Google when looking for "Mapbuilder" instead of getting a Google mashup site.
We can improve things by changing the title of Mapbuilder's homepage to include "Mapbuilder in the title".

Access Google maps

Most users now want access to Google basemaps. We can provide this by tapping into the webmap.js application about to be built.

Roadmap

Regular Stable Releases

Since version 1.0, there have been a significant number of features added to the mapbuilder baseline:

  • Support for OWSContext and multiple layer types
  • Tiling
  • Google Map Layers
  • Vector rendering using SVG and VML
  • SLD editor
  • Geobliki
  • (probably more I can't think of)

Users ask about the new features, but continue to use the latest stable release due to the need for stability and I've seen some users turned away due to the lack of a recent release.

The trunk version of Mapbuilder is reasonably stable, but there has only been limited testing of the new code.

We need to put out a new release so that we can demonstrate our latest functionality. I suggest we call this release 2.0rc1 due to all the extra functionality added.

Integrate with similar projects

There are a number of web mapping clients doing similar things to Mapbuilder or with features that Mapbuilder would like to copy. We could attempt to compete against these projects and try to be bigger, better, faster. Eventually one of our projects is likely to come out the winner and all the rest will quietly slip away into the historical archieves.

However, a friendlier and more powerful solution would be for us to join forces with similar projects and focus on one great product instead of lots of good products.

There has been a move toward a cross webmapping project discussed at the FOSS4G conference. Notes on webmap-discuss email list (I can't find the archieve) and something similar at http://wiki.osgeo.org/index.php/FOSS4G_2006_Tiling_BOF.

In particular, we should start by using OpenLayers as our Rendering Engine which is relatively easy to implement. This would cause a software stack like the following:

Mapbuilder
OpenLayers
WMS WFS GoogleMaps YahooMaps MNSMaps kaMap etc

We need to be aware that the stack could be seen as a threat to OpenLayers as Mapbuilder will be placed in the prefered position of being at the top of the stack (and closest to the customer). To alley OpenLayer's potential fears, we need to work with OpenLayers toward a merging of the projects (where we can both be at the top of the stack).

Between the webmapping applications, we need to help users identify which application to use and when. Mapbuilder should target feature rich applications. (Open layers is targeting simple, fast use cases).

We should work with the other projects do define a common API so that users can easilly migrate from one application to another as their requirements change.

Mission Statement

We need to revisit our mission statement and ensure it is inline with the direction we are now taking.
Eg: Mapbuilder is powerful, standards compliant, tailorable, extensible, webmapping client based on AJAX.
AJAX.

OSGeo and Marketing

After becoming part of OSGeo, Mapbuilder downloads doubled. So the extra marketing is obviously good for us.

Mapbuilder has completed all the graduation criteria for Mapbuilder, so we should make sure we continue to finish the graduation process.

We should also look at other forms of marketing. OSGeo is calling for this and we should work in conjunction with OSGeo.

  1. A short promotional video explaining Mapbuilder
  2. Ensure Mapbuilder is represented at OS GIS conferences.
  3. Create a OS GIS distribution and ensure Mapbuilder is part of the distribution.
  4. Mapbuilder is distributed with Geoserver. We need to ensure this continues.
  5. We should consider bundling Mapbuilder with UDig and QGIS to provide a heavy/light client solution.
  6. Mapbuilder has been used in OGC testbeds. This will add credability but probably won't increase the reach of Mapbuilder significantly.
  7. What else?

Project Management Structure

Mapbuilder has a Project Steering Committee of 4 developers. This has ensured that we have developed a fully functional robust application, but we are probably not as responsive to user needs as we should be.

This could be addressed by inviting more user and marketing type people into the Management structure of Mapbuilder to help drive future priorities.

Documentation

Documentation has improved since the last release, thanks to a drive by Peter Miller, but we can still focus on improving the docs and making things simple.

Previous Strategic Direction Papers

  1. Strategic Direction - February 2008 (Doubling as Mapbuilder's OSGeo 2007 Annual Report).
  2. September 2006
  3. April 2006
  4. June 2005