I'm wary of starting a debate based on opinion, so I lifted my title from this question which seems to be doing fine. I'm also worried about offending MapGuide enthusiasts so please understand I am simply trying to avoid unwise strategic decisions.
When I try to install, use, develop with, ask questions about, or otherwise entertain MapGuide OS I get the feeling that starting a new project with MapGuide is too risky:
- API documentation has not been updated for years and developers are asked to use 2.0 docs for the 2.2 and 2.4 product
- It took several months from the time 2.2.0 was released for http://mapguide.osgeo.org/ to recognise that 2.1.0 was not the latest stable release, suggesting that no one is actively maintaining the site
- Install documentation is spread wide and thin. I recently spent the best part of a week trying to install on 64-bit linux for use with Oracle and ultimately had to give up (then installed GeoServer in less than one hour)
- Forum threads regularly end unanswered or stumble along with hopeful suggestions only to end with an unanswered question from the OP
- I personally have never managed to get a .NET map viewer up and running due to compile errors that others have reported but had no luck fixing
- It seems like a lot of the effort that goes into MapGuide comes from a very small number of people (especially Jackie Ng) which doesn't bode well should they ever get too busy or lose interest in the project.
Someone recently asked a similar question on the MapGuide forum but it took a decidedly ambiguous tone and ended with no clear answer.
I appreciate that a lot of work has gone into the project, and also that it provides functionality I can't find elsewhere (this is a big part of the problem I have), as it can provide a complete viewer experience in short order. However in addition to the list above I have other issues:
- Dependency on stateful sessions and associated load balancing considerations
- Requirement for a configuration tool or web service to create opaque configuration files / databases that can't be edited or viewed easily
- PHP web viewer's need for a specific version of PHP which is unlikely to be compatible / ideal for other PHP applications on a shared server
- Distinction between IE and other browsers in the viewers due to ActiveX
Yes, I know that this is an Open Source project and so if I think it needs improving I should get involved, but honestly I would much rather donate my time to other projects like GeoServer or OpenLayers as these products have both made my life much easier and have well defined roadmaps.
Best Answer
Allow me to address your points individually:
Nearly all of MapGuide's API changes to the present day have been additive in nature (a new class here, a new method there). Only in very exceptional circumstances are classes or methods actually modified or removed. So to this end, even though you've been asked to use the 2.0 docs, they are still mostly applicable, with new classes and methods since then detailed in the respective MapGuide RFC that introduced them.
Still that does not excuse the fact that the "published" online API documentation is still at 2.0, and once again it's due to a lack of an active caretaker to maintain the mapguide.osgeo.org site and keep it up to date.
As explained above, lack of a mapguide.osgeo.org caretaker
Could you not say the same thing about any piece of software written in C++? We gain performance and responsiveness at the expense of ease of installation and configuration due to potential dll-hell trying to communicate with various 3rd party external libraries. We try to make installation and configuration as simple as we can but some external components will simply refuse to cooperate with MapGuide unless a very specific set of parameters are met.
Then again, Oracle isn't exactly renowned for ease of configuration is it? :)
We try to provide answers where we can, but I find unanswered threads usually are of the following:
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:
These are the stock pieces of information that any software support personnel would require in order to provide help.
Coding/Programming problems that can be easily answered by a Google search or StackOverflow (or any related StackExchange site). 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.
English not being the OP's primary language. Well, we can't do much about this one.
A super-specialized use case that nobody else has ever thought of. We can't do much about these questions either, because we never tried using MapGuide in this particular way that has been described.
The mailing list is kind of like this site (or any other StackExchange site), minus the meta-commentary and up/down voting of questions and answers. We can't exactly downvote silly or often-repeated questions on the mailing list. So rather than flaming such people (I don't do that, trying to be a model OSS citizen here), I just ignore them.
Again, the problem is due to MapGuide's C++ nature. The .net map viewer isn't truly .net code, it is .net code that wraps a whole set of MapGuide native libraries in C++. Same goes for Java and PHP viewer. Most .net viewer problems are a combination of:
The regular perils of trying to auto-configure IIS from a windows installer.
You could cite this one problem as the reason why the project as a whole seems to be stagnating, why the site isn't updated, why documentation isn't updated, etc, etc.
Yes, MapGuide Open Source does suffer from a low bus factor. At the end of the day, I'm just a passionate user and developer, and that is all an Open Source project really needs: More guys/gals like me (not exactly like me, but power users/developers submitting the occasional patch to fix or enhance something, writing the occasional blog post to spread their knowledge, writing the occasional piece of sample code to show how to do X/Y/Z, updating the occasional piece of documentation, etc, etc).
Financial funding helps too, but it seems Open Source software has this "free lunch" mentality that is hard to shake off.
I'm personally interested in how the other OSGeo projects (esp. MapServer and GeoServer) fare against MapGuide. These projects don't have backing from a major software vendor like Autodesk, so how to these projects get by? Do these projects face similar problems? Are their user communities the same? How do these projects stay alive?
As for your specific issues:
This is a consequence of the server-heavy architecture of MapGuide. The original design was probably along the lines of "let the server do all the hard work" which is probably the right choice at the time given the requirement of a client-side map viewer that doesn't require plugins and the state of web browsers at that time (2004-2006)
The configuration files are plain XML files. They are just stored in an ACID-compliant container (a berkeley DBXML database if you're wondering), so that such files aren't easily corrupted by concurrent multi-user access.
This is mostly a windows problem again due to MapGuide being written in C++ and needing to talk to assorted libraries of various languages. This is doubly compounded by the fact that Microsoft Visual C++ is the dominant compiler on Windows, and if you know C++ you cannot just mix and match various binaries built from different C++ compilers. So we have to build and bundle everything ourselves. Needing a specific version of PHP is a consequence of this.
On Linux, this isn't a problem but the MapGuide build system inherits all of the ugly kludges for windows, so we just kind of roll with it for Linux as well.
This is not true. MapGuide Open Source is architecturally different from MapGuide 6.5. There has never been a plugin-based viewer and for the sake of the modern web, I hope there never will be.
So after all that, I guess I didn't really answer your original question. Well let's ask the most important question here.
What are the requirements for your project?
Simply putting up an interactive map on the internet/intranet with tools for basic querying and spatial analysis? MapGuide excels at this. Tools like MapGuide Maestro (which I am the author of), makes this process even simpler.
Integration with other software/systems? If it's consuming existing external data stores, MapGuide also does this very well through FDO. If it's consuming external web services or providing web services for consumption by other systems, it falls a bit short here. If were talking OGC standards, only WFS and WMS are supported for service consumption and exposure.
Rich and complex spatial analysis like routing, network tracing, kriging, etc? You're now venturing into pure customization territory or possibly looking at Autodesk's commerical offerings as MapGuide Open Source doesn't support this out of the box.
Basically, as your [system integration or spatial analysis] requirements grows, the greater need there is for customization and programming. Which brings up my next point.
People often call Linux the "hacker's OS", I'd like to call MapGuide the "hacker's GIS". If you know how to code competently, questions that you may have (as long as they don't fall into the 4 aforementioned categories, because we get enough of them on the mailing list) do generally get answered or give you enough clues to find your solution.
If you're more GIS user than a programmer, then as the South Park ski instructor would say, "you're gonna have a bad time". Because if MapGuide doesn't do something you need out of the box, you'll have to write some code.
Just my 2c.
Disclaimer - I'm a software developer first, a GIS person second, sales/marketing way down the bottom of the list. I have not used MapServer, GeoServer or any other OSGeo alternatives to MapGuide. Skewed opinions may be the result