So last week, I made a
survey for you lot to fill and we got back 74 responses. Thank you to all who participated.
In hindsight, there were some important questions I forgot to include in this survey, but I didn't want to risk screwing up the incoming stream of responses, so I guess we'll put that in another survey in the future.
So prepare for a very long post with lots of charts and graphs with some interesting stats and some uncomfortable truths. Just remember the sample size of these results (74) when reading my analysis or when making your own conclusions about the state of where MapGuide is currently at.
About the MapGuide user base
Let's get some things straight. I'm not a GIS user (
Map Projections? That's just a black box where point goes in and another point goes out right?). I'm a software developer who happens to be in a GIS/Geospatial heavy field. The purpose of the questions below was to gauge how many of you are basically in my type of situation.
Turns out, there's a sizable percentage of people like me.
I also wanted to gauge the general programming skill level. Turns out there is a good balanced spread.
Most programmers I know of would've at least heard of sites like
Stack Overflow and its related sites on the
Stack Exchange network (there's a
GIS one too). So this next result was a bit surprising.
We encourage users to keep content on the mapguide-users mailing list as MapGuide-specific as possible because general programming and technical questions are easily answered by these others sites. Telling users to Google the answer to your general programming/technical question is somewhat superfluous because the first result is generally a post on Stack Overflow / Stack Exchange.
On that same vein, I was also interested in how many of you follow blogs of a technical nature as I believe blogs are an excellent medium for spreading knowledge.
It's good to see most of you are indeed switched on to the technical blogosphere.
About your Programming skill set
The MapGuide platform and ecosystem consists of code written in various languages and utilizing many different technologies and concepts. So I wanted to gauge how many of these things specific to MapGuide you are familiar with.
First off, programming languages
MapGuide (and its component technologies, FDO and CS-Map) are primarily written in C/C++. So this graph does illustrate the difficult barrier-of-entry to contributing bug fixes and feature enhancements.
Then there's the technologies involved
Sadly like the chart above, the polling results on the lower end of the spectrum just happen to be the ones with greatest emphasis in the MapGuide Server code-base, imposing another set of technological barriers to external contribution.
There are
many interesting things we can do with HTML5 and it is good to know that at least half the respondents were familiar with HTML5 as this is the path that I think we should take our viewer technologies in.
Your knowledge of Linux
MapGuide is not a windows-only piece of software. It works on Linux as well, and so I wanted to gauge how familiar you people are with this Operating System.
NOTE: It seems I either fumbled the form design or Google Docs completely disregarded my form settings because the page containing the Linux-specific questions was supposed to be optional, so this data may have been fudged by the "no" and "other" responses.
The next question was an important one because I wanted to know if we are targeting the right distros for our Linux builds.
It turns out we were pretty much on the money providing builds for Ubuntu and CentOS. Whatever build resources spent on doing Linux builds would've been wasted if we had targeted the wrong distros.
Building MapGuide on Linux is a very complex and technical affair (just looking at the various out-of-date build instructions for $LINUX_DISTRO can attest to that!), so I wanted to know how many of you at compiled some code at least once on the predominant compiler toolchain for Linux.
How you install MapGuide
So the first important question here was what version of MapGuide you are currently using.
It is comforting to know that most of you are either on the latest stable release (2.2) or the soon to be final 2.4. Our go-to answers for most technical issues is "use the latest stable version" or "try the latest development version". We don't say this out of laziness (ok maybe a little), but because it helps us reduce our window for reproducing defects, because we simply do not have the resources to support X older versions of MapGuide.
Judging by the next result, it seems that 4GB of addressable memory may still be enough for everybody for a bit longer.
This next one makes for disheartening reading
Maybe it is because of this?
I have no problems admitting that I too share the same sentiments right now about the state of Linux support in MapGuide. I'm sure there's many things we can do to improve the Linux side of the MapGuide equation but the main problem I see is just the lack of knowledge more than anything else.
gcc/automake is such a radical departure from those weaned on the Visual Studio style of development/coding (those evil Microsoft drug dealers and their super addictive developer tools!), that it makes understanding and solving MapGuide problems from a Linux context quite difficult. I only just recently mastered the art of comprehending gcc/make build errors to finally be able to put out matching
Ubuntu and CentOS builds of MapGuide 2.4. Don't even get me started on the lack of 64-bit Linux support. I'm still taking baby steps with this thing.
If the person who started these
development and
debugging guides for Linux actually finished them, I'm sure this situation might have looked better (at least for me). We're real knowledge-poor about Linux support at the moment. Things are where they are because nobody knows a better way.
These next set of numbers are pretty much what I expected.
Given the majority of you answered "Windows", it makes sense that users would favor the Microsoft-specific configuration as they are the ones that integrate best with Microsoft technologies (obviously). Java may have a low representation here, but it's significant enough of a language/platform in the server/enterprise space that it would be crazy to drop support for it.
I don't hold much of a high opinion about PHP as a programming language, but the ubiquity is understandable given the ease of setting up new PHP applications in IIS and Apache and that the PHP environment is always installed regardless of configuration options (as it is required by Fusion and the MapGuide Site Administrator).
I would've also been interested in what kind of associated tooling you people use for PHP/Java (.net is obviously Visual Studio), but again it's one of those questions I realized I
should've added after publishing the survey. Oh well, leave that for next time.
How you knew about MapGuide
I was interested in knowing how and when you became acquainted with the MapGuide Open Source
That first graph pretty much correlates with my perception of Autodesk's involvement with MapGuide Open Source. Lots of mailing list activity and various presentations about MapGuide in the early years (2005-2008), winding down to mainly code contributions and -internals mailing list discussions in the present day.
Speaking of which ...
Your relationship with Autodesk (or lack thereof)
With these following questions, I wanted to test the notion of whether Autodesk has provided enough value in its commercial offering of MapGuide to justify owning one or more commercial licenses, despite the zero-dollar value of using the open source equivalent. Judging by the results below:
I'd say that is indeed the case.
Having used and beta tested the really early commercial releases of MapGuide (2007-2009), I was somewhat dubious about the value of the extra features that were included:
- Production quality raster provider. Not much use if you are serving only vector data
- Production quality SQL Server provider (for 2000 and 2005). Not much use if you don't use said version of SQL Server. Also it's been long supplanted by the Open Source provider for SQL Server Spatial.
- Production quality Oracle provider. Not much use if you are not using Oracle. Also has a suitable Open Source alternative in the King.Oracle provider
But as of the 2013 release, Autodesk Infrastructure Map Server truly has a unique commercial advantage in terms of features:
- The product formerly known as Topobase now integrated.
- A native FDO provider for DWG files. The killer feature that was 6 years waiting. No more export/translation/publish to dumb DWF!
- A specialized viewer for mobile devices.
- Integrated GeoREST
These are real features of value that's well worth the price of a commercial license. And it seems most of you agree based on the above numbers.
Or could it be that AIMS is part of the many suites that Autodesk is so keen on selling now days? Or maybe you have an existing investment in Autodesk geospatial products that you want to leverage with AIMS?
Or maybe many were previous customers of Autodesk MapGuide 6.5?
How you customize and work with MapGuide
In terms of viewer-ship, the AJAX viewer is still king, but Fusion is closing the gap. I hope our Fusion
enhancement work for 2.4 can close this gap further. There's still plenty of room for improvement in Fusion, but I think there is will always be a minimum modern browser requirement for Fusion while IE 6,7,8 are still in prominent use. There is only so much javascript wizardry we can do for IE 6,7,8 before we hit the limitations of their crappy javascript engines.
In terms of API usage, the choice of API obviously correlates with the installation configuration in the previous chart. It's nice to see some respondents understanding the capabilities that the mapagent http interface offers, of which the
MaestroAPI is basically a .net object-oriented wrapper around and is the backbone of the
Maestro authoring application.
Speaking of Maestro
Sort of expected these numbers (not tooting my own horn here. really :)), given that Maestro is the only available authoring option for MapGuide Open Source and Autodesk Infrastructure Studio is only included with the commercial version. I'm interested in what the "other" option could possibly be.
As a web developer, this chart below pleases me
A good distribution of modern web browsers (I even classify IE9 as a half-modern browser). IE7 and IE8 are borderline tolerable. My condolences and sympathies to the 5 respondents who still have to deal with IE6.
On the data front, it gets a bit interesting
Despite its storage and technical limitations, the ever ubiquitous SHP file still seems to be the preferred flat-file of choice for spatial data. I guess it's the format most users are provided the data in, because if I had a choice of format for my spatial data files, there's no way in hell I'd ever choose SHP unless I needed to share such files with other GIS applications. I'm surprised that SDF is still going strong over SQLite as it surpasses SDF in so many different areas:
- Read performance. SQLite is the fastest format of the lot, bar none.
- Tooling support. You can open SQLite files with any SQLite db admin tools, and there's tons of them out there. Important when you need to access such data through non-FDO tools.
- Greater capabilities. The SQLite FDO provider is a first-class provider that gets all the new FDO API toys. You can use views, indexes and all other assorted DBMS goodies that is completely independent of MapGuide/FDO in most cases.
- Ease of integration with thirdparty applications. SQLite data access through MapGuide/FDO is completely opt-in. You are free to use alternate means (eg. ADO.net) for data access through these files, as long as you properly maintain the required FDO metadata tables when doing structural changes with non-FDO tools. The only small integration issue is with writing/updating geometries as they are internally stored as FDO geometry BLOBs, but you would probably be already using MapGuide/FDO for that.
I lumped relational databases into a single category, because if you're using a relational database:
- You care about ACID-ity and referential integrity of your data.
- You are integrating with an existing system or application
- You get to exploit the full capabilities of your DBMS for optimal performance.
And all the supported RDBMSes that FDO can access provide these qualities in one shape or another.
In terms of customizations, most respondents fell within the default extension points provided by MapGuide
I guess the hardcore stuff like
mg-desktop fulfills a niche that the average MapGuide developer probably doesn't need or require. But it does goes to show that the MapGuide Server code-base does have utility outside of being a Web Mapping Server which was so concisely demonstrated in
that AU presentation 3 years ago.
MapGuide Documentation and Learning
This set of questions was made to gauge the quality of the documentation and samples that currently exist out there. We asked about your current perceived knowledge of MapGuide
It appears the majority of you know comfortably enough about MapGuide and its APIs to build your specific applications and customizations which is a good thing. The small number of true experts (besides myself), does limit our ability somewhat to fix and improve the software outside of Autodesk. If some of these respondents are Autodesk developers themselves (the survey *is* anonymous after all), it just exemplifies this problem even further.
As to how you acquired this knowledge, mostly through the expected channels.
Now as to the quality of the documentation and samples themselves
The numbers aren't exactly flattering, and I can definitely see some areas where documentation can be definitely improved. Some of the samples could definitely do with a makeover to reflect modern patterns of software development.
Take .net for example. The .net viewer sample is still inline aspx (yuck!). Anyone versed in the current way of developing ASP.net web applications will undoubtedly scratch their heads looking at this. We could probably do with one done in the style of
ASP.net MVC, or maybe some examples with the new fancy
ASP.net Web API.
We have a section in the MapGuide wiki dedicated to
code samples that could do with some love.
The mapguide-users mailing list
Besides sample code and documentation, the mapguide-users mailing list is the other primary place for discussing all things related to MapGuide Open Source, so it helps to get some statistics about that too.
Firstly, I was interested in how you use this mailing list. Gotta say, there's a lot of lurkers we've got here (if you were to extrapolate these results)
Then there's the frequency of usage. I see a fair chunk of you follow my daily ritual of firing up the
nabble front-end to mapguide-users in your web browser the moment you fire up your work computer :)
Then the important one, the quality of the content on the mailing list and it seems it is fulfilling its purposes in helping with your MapGuide-specific problems on an average basis.
In terms of the quality of content, I tend to agree with the majority here. Most of the chaff you could probably categorize into the following:
1. Posts with lack of specific details. A one sentence question saying something "doesn't work" doesn't really help us in trying to assist you solving your problem. There are many other factors we normally need to know about like:
- System Specs
- MapGuide Install Configuration
- Steps to reproduce
- etc, etc.
These are the stock pieces of information that any software support personnel would require in order to provide help. Yet we are somehow expected to magically read your minds to understand the exact environment you are running MapGuide on.
2. Coding/Programming problems that can be easily answered by a Google search or
Stack Overflow or any related
Stack Exchange site (it's why I posed this question in the survey, just to make sure you're aware of such sites). Or posts containing pages and pages of unformatted source code, ending with "how can I fix this? Plz help me, it's urgent". Or people who follow up your answers with "It doesn't work" because they probably copy/pasted your sample code verbatim without fully understanding the context of the answers given. These type of posts reek of pure laziness on the part of the OP.
3. English not being the OP's primary language. I don't think we can't do much about this one. Whether we like it or not, English is the de-facto language we are expecting questions and answers to be written in on the mailing list.
So once again, not surprised about the perceived quality of questions asked on the mailing list.
Your MapGuide pain points
We asked whether MapGuide as a whole does what you (or your users) require
For the majority of you, it seems that MapGuide ticks most of your boxes, so I was interested to know if the software/tools that help you tick the remaining boxes were competing products
So in terms of actual un-ticked boxes, I basically took my own wishlist and added in things that people never seem to stop complaining about :)
Given that "other" polled last, it seems my pain points echoes yours as most of the items in question polled with evenly spread numbers. So given these pain points, I wanted to know if you could "put your money where your mouth is" so to speak.
I'm guessing for those that responded "yes", your specific pain points must've been all different because otherwise one of the pain points I commonly hear on the mailing list (GDAL provider stability/performance) would've
already been solved.
A small group of you expressed concern about MapGuide's future, which is the reason why I formulated this survey in the first place, so you can see the results here and form your own conclusions.
MapGuide's standing as an OSGeo project
MapGuide is just one piece of software under the umbrella that is OSGeo. So it was of interest to me to see if you used any other software/tools in the OSGeo stack besides MapGuide/FDO/CS-Map/Fusion
As expected, the major players (OpenLayers, QGIS, GDAL, PostGIS) have major representation. One thing I would see MapGuide do is be better friends with its fellow OSGeo software. Off the top of my head, some QGIS-MapGuide-FDO integration would be really interesting.
All OSGeo projects have an integrated issue tracker and wiki powered by
Trac. So it was interesting to find out how many of you actually use the MapGuide/FDO/CS-Map/Fusion ones.
For those that do use the MapGuide/FDO/CS-Map/Fusion trac, it seems the wiki gets a good mileage, but there isn't that many that keep this wiki content fresh and relevant.
I guess this sorts of ties in to our quality problem with samples/documentation. We have the means to improve them, we just need to do it in a proactive way through blogs, wiki content and documentation updates instead of reactively through mailing list answers.
The next one is a bit disappointing and ties into the general theme of there being very few non-Autodesk contributors.
I guess this could be the result of:
- The general non-Autodesk brain drain.
- Lack of knowledge about source control and applying patches. I sure hope this isn't the case. Using source control is so important in software development it should be the next thing taught after writing "hello world". Learning subversion isn't rocket science and using a graphical SVN front-end make this dead easy.
Other things that cannot be quantified into pretty charts and graphs
I couldn't determine the suitable set of pre-defined responses for the following questions, so I left them open-ended, making quantification in the form of charts and graphs impossible, but there left here for completeness.
Conclusion
So what can we conclude from all this? Here's a few of mine:
- You all aren't freeloaders :) There is enough value in the commercial version of MapGuide for most of you to own a commercial license, and you are knowledgeable enough about the differences to know whether the commerical or open source version is more suitable.
- On that same subject, there is a sizable interest to donate/fund for any improvements. I'm guessing there just isn't a unified consensus as to what should be improved. It certainly doesn't look like GDAL raster performance/stability is one of them.
- We are strained in the technical knowledge department. We definitely could do with more non-Autodesk active developers/maintainers. The non-Autodesk bus factor is dangerously low.
We seem to have a healthy group of "power users", we just need some of these users to upgrade to the next level and start becoming involved in actual development/maintenance. That's all an open source project needs to stay alive isn't it? A core group of passionate users.
- Linux support is bad because we just don't know any better. Sad but true. If there's a better way then we're all ears.
- Documentation/Samples definitely can be improved a lot. We seem to be more reactive (mailing list answers) than proactive (wiki/blogs/etc) when it comes to this however.
- The 2.2 to 2.4 gap was just too long. We need to release more early and release more often.
But these are just my thoughts, you can draw your own conclusions.
Posts
