My Fascination With XML – Coming To An End?

My first exposure to XML was when I began using JUMP to work with geospatial data encoded in GML 2.0. I was fascinated by this way of storing information. It was readable by both humans and computers, and it imposed a hierarchy on the document that encapsulated the data. Now that I’ve been programming for a few years I can look back on this fascination and identify the root causes.

[1] I had a terrifying fear of binary data. Binary data was shrouded in mystery and confusion.

[2] I liked the idea of an “open” file format that could be interpreted and used by so many different programs. This idea wasn’t as common at the time then as it is now, and I had hit the wall of “secret” file formats in my programming aspirations several times. Autodesk’s DXF format was the closest thing I had seen to an open file format, at least in the geospatial realm, and anyone who has worked with DXF files knows that there not that “human-readable”.

My interest in GML inspired me to learn about XML and my fascination began. I started to view XML as the solution to every programming problem. Data storage, object serialization, configuration files, data transfer formats…

How far did this fascination go? I came up with a simple subset of XML called 2SimpleXML and I’ve written a complete Pull-Parser for the sub-set from the ground up, using only the standard Java libraries. The parser is functionally complete, and only needs some more bug squishing and unit tests.

That’s a pretty serious fascination.

I questioned this fascination for the first time when I started dabbling with Python and posted some questions on a Python users list. I was quickly chastised for my Java habits, one of which was trying to incorporate XML into everything. (Python isn’t a compiled language like Java, so you can actually write and store code in text files. This means you can accomplish a lot by storing Python code in text files, instead of XML.)

I’ve begun to question that fascination some more. I've overcome my fear of binary data, for one thing. This due in large part to this book:

http://www.amazon.com/Code-Language-Computer-Hardware-Software/dp/0735611319

It explains binary data in terms most common people can understand, and I highly recommend it for new programmers, even if they're using a high-level language like Java.

I’ve also seen alternative means of text-based data storage in Linux. (The configuration file for the X-Windows system is one example.) I’m also looking for something that would allow for the construction of simpler parsers. (Now that I’ve seen how complex an XML parser is.) I’m really looking for a way to streamline the process from text file to Java object.

I’m not the only one who’s questioned the validity of XML as a “solve-all” programming solution. A Google search for “XML Alternatives” turned up a link to a list of XML alternatives:

http://www.pault.com/xmlalternatives.html

I’m going to experiment with some “flat file” text based storage. This will give me a chance to see if it fits my programming needs better than XML. I’m going to start by designing a system to store Feature and Geometry objects in OpenJUMP in text files. This will be the foundation for a data-caching system I need to implement in the new PostGIS Plug-In for OpenJUMP. (This data-caching system will store features retrieved from a database or other remote data source to allow manipulation of the data from these sources in the event of a connection loss.) If this system works, I’ll use it in my RAM-Independent Feature DataSource for OpenJUMP, and I may take a look at improving OpenJUMP’s project file.

I’m not totally abandoning XML, I’m just thinking about alternatives. In the end what I really want is what I had in GML 2.0. An easy to read, easy to interpret, and simple way to store Geospatial Data. Perhaps I’ll have to change the name of LocusXML to LocusText or something like that. :] We’ll just have to see.

I am beginning to realize, XML may not be that fascinating after all.

The Sunburned Surveyor

Read More

Commercial Support - The Forgotten Details...

My recent blog post about offering commercial support for OpenJUMP resulted in a rather lively discussion on the JUMP Pilot Project developers list. It appears as though I did a poor job of defining exactly what I would be offering as part of my “commercial support”, and whether or not this would be a violation of the GPL. (Both the original JUMP released by Vivid Solutions and OpenJUMP are released under the GPL license.)

I wanted to take a couple of minutes to clear some of the confusion around what I’ll be doing and hopefully ease some of the concerns.

I had hoped to make quarterly releases of OpenJUMP. (Stefan pointed out that this schedule might be tough to keep. He is probably right, and I might need to scale this back to biannual releases.) Whatever the release frequency is, my basic plan is this:

One of every two releases would be made available to all of the OpenJUMP community and the general public. The remaining releases would be made available to customers of the support packages. (This release would not be placed on the SourceForge server, but on an independent website that I would pay to have hosted. I’ll need a website for the business anyways.)

What would be in the releases? Not the source code. I repeat, not the source code. The release will include a graphical installer and perhaps some documentation goodies. I’m not restricting access to the source code, and even the installer and documentation will be available to all parties every other release cycle. The source code will be available at all times on the SurveyOS Subversion Repository. The bug fixes and improvements will also be pushed down to the OpenJUMP CVS at the JPP SourceForge site as I complete them. Not per release, but as I complete them. That means all my work will be available to all other interested developers in 2 different source code repositories almost immediately. No delay, no fee, no hassle.

Will this work? Who would pay for a support package that includes regular releases if the source code is already available?

I don’t know if it will work. But it just might. In order to understand this you need to understand the type of customer I’m targeting. I don’t intend on offering my services to the typical developer that is involved with OpenJUMP right now. They won’t pay for something they can easily do themselves, unless they’re just too busy. I’m only interested in those developers from a business perspective for one reason. What is that reason? I want them to contribute to the project so OpenJUMP becomes more appealing to the customers I’m really after. Who am I really after?

Small businesses.

That’s right. Small businesses. Not Java developers, not huge government entities with 3000 CAD workstations running ArcInfo. I’m after small businesses. (Actually, I’m after small businesses, agencies, and non-profits.) These organizations don’t have developers to commit to the work involved in building and maintaining OpenJUMP. They can’t afford a $15,000 dollar license fee for ESRI’s stuff. They want a program that is affordable, that works, and that fits there needs. They want someone to call when the program doesn’t work, and when it needs to grow or improve to fit there needs. They want a graphical installer and some tutorials, not Javadoc and an Ant build file to run in Eclipse.

That’s it. That’s my plan. My secret is out.

I’m not going to impose restrictions and barriers of any kind on OpenJUMP.

Will my plan work? I hope so. I’m realistic enough to realize it might not. We’ll just have to see how things turn out. I am, however, confident of 2 things, which will happen if the business succeeds or fails:

[1] I’ll be a wiser business man and a smarter open source developer.
[2] The OpenJUMP community will benefit, at least in the short term.

I will make an effort to address other concerns and issues about my plans to support OpenJUMP commercially as they arise. I really want this to be a positive thing for the community, not a negative thing. If it turns out to be a really negative thing I won’t do it. I won’t spoil the community I’ve worked hard with others to build over the past few years for a few bucks. I can always put in some extra hours on that surveyor’s sunburn if I need that. :]

The Sunburned Surveyor

Read More

Commercial Support For OpenJUMP

I’ve decided to offer commercial support for OpenJUMP in the near future. Let me explain why I am doing this, what I mean by “commercial support”, and when I hope to make the offer.

Why offer commercial support for OpenJUMP?

I had originally considered offering some form of commercial support along time ago, but decided against it. I felt that OpenJUMP wasn’t really mature enough for this step. “OpenJUMP just has too many limitations to be commercially viable.” I thought. “I’ll offer commercial support when I’ve added some more critical features.”

What has changed my mind? One thing was an e-mail I got from a company that was already using OpenJUMP in its commercial operations. They wanted to add some features to OpenJUMP, and were looking to hire a developer to do the work. However, there wasn’t a company in a position to offer this type of support, as most of OpenJUMP’s most active developers are volunteers. This e-mail demonstrated three important things too me:

[1] OpenJUMP was suitable for certain “commercial” applications already, despite its current limits.

[2] There was currently a market for services built around OpenJUMP, and the market demand for these services, however small it might be, was not being met.

[3] The lack of commercial support for OpenJUMP could seriously hamper its adoption by companies and organizations, and this would harm the overall OpenJUMP community in the long run.

The third item listed was reinforced by my own failed efforts to gain support for the use of OpenJUMP at the land surveying and civil engineering firm that I work for. Our IT guy “Joe” has a healthy fear of open source software. What was his number one beef with using a program like OpenJUMP? “Who am I going to call when something goes wrong? A program like that has no technical support.”

I think this is a critical issue for many businesses that would like to use open source software as part of there business.

I think providing commercial support for OpenJUMP will only increase its adoption, and will open up the opportunity to develop features that would normally be delayed for a long period of time, or never appear in the program at all.

Some people are very suspicious of any commercial endeavor involving an open source program. I’d like to point out to these individuals that making piles of money is not a reason why I am offering commercial support for OpenJUMP. In fact, I realize I might not make any money on this at all, at least initially. I’ve already got a good job that pays most of my bills, and I don’t have to make a living at this. I’m just going to try it out. (Wouldn’t you get paid to do your hobby if you could?)

What type of “commercial support” will I offer?

The commercial support for OpenJUMP will be offered in 3 month and 6 month terms. All support packages will include 2 primary services:

[1] Technical assistance for installation, use, and development via e-mail. This is meant as an alternative, not a replacement, to the SourceForge mailing lists for OpenJUMP and the JUMP Pilot Project. I will be responding to each and every e-mail received by a customer. If the solution to the customers problem or issue is simple and readily apparent, then it will be provided at no charge. If the solution is more complex, or requires a significant investment of time and energy to solve, the customer will have the option of pursuing the solution for a fee. What advantages does this service provide customers when compared to the SourceForge mailing lists for OpenJUMP and the JUMP Pilot Project?

Every e-mail will receive a response.

Every e-mail will receive a timely response.

Solutions to problems will be pursued, discovered, and created if the customer desires. Problems will not remain unsolved.

[2] Regular releases of a “high-quality” build of OpenJUMP. (The high-quality build of OpenJUMP will be hosted on the SurveyOS Subversion repository, and will be a mirror of the OpenJUMP CVS with stricter controls on code submissions. All bug fixes and patches made in the high-quality build will be pushed back to the OpenJUMP CVS.) These releases will be made quarterly, starting in the first part of January 2007. The releases will include an installer for Linux and Microsoft Windows operating systems. Each April and September release will be made available to customers only. (The source code for the high-quality build of OpenJUMP will be available to all developers at any time via the SurveyOS Subversion repository. I’m talking about the installers and other “user” goodies.) Each January and June release will be made available to the general public as an official OpenJUMP release.

I will also offer developer services to add features or improvements to OpenJUMP independently of the commercial support package on a time and materials basis. Customers of the support package will receive a discounted rate for these services. If the source code and documentation resulting from the performance of these development services is not released under an open source license, the rate will be double the normal rate.

When will I be offering commercial support for OpenJUMP?

I hope to have a website for my little company offering commercial support for OpenJUMP up in the next few weeks. I will endeavor to have an agreement for the support package ready to go by the end of the year, to coincide with the next release of OpenJUMP.

I hope members of the OpenJUMP community will view this as a positive development, and I will be happy to address any concerns they may have about my decision to move forward with this. I will continue to support OpenJUMP as a volunteer developer and project administrator during this business venture, and afterwards, if it is not successful.

The Sunburned Surveyor

Read More

Getting Involved (No more long e-mails...)

Some recent activity on Paul Ramsey’s blog got me thinking about a blog for OpenJUMP. Here it is.

I hope this blog will provide a place for some longer discussions about OpenJUMP, OpenJUMP-Ex, JTS, the JUMP Pilot Project, and the SurveyOS Project. I hope it will also give me the opportunity to receive feedback from those involved in the regular use and development of OpenJUMP. The type of feedback that might not be appropriate or well suited for the JPP or SurveyOS mailing lists hosted at SourceForge. (That means the subscribers to those lists will no longer have to suffer trough as many of my terribly long and rambling philosophical posts.)

This blog will also allow me to have a more active role in the open source GIS community, which is something that I have neglected until now. Those that know me personally realize that I take a neutral stand in political matters, but this doesn’t mean that I can’t become a champion for the open source GIS and support issues that are important to me both as a free software developer and as a land surveyor. These are issues like reasonable access to publicly funded geospatial data, understanding and cooperation between land surveyors and GIS professionals, and the responsible use of geospatial data.

The Sunburned Surveyor

Read More