Thursday, February 1, 2007

Smallworld Open Source Software

The proprietary nature of the Smallworld suite of products is sometimes used as a negative point against a potential customer choosing Smallworld as their GIS system. One argument is that the programming language (Magik) is not a standard and open language and therefore it is expensive to train (and retain) good Magik developers. A group of developers in the Smallworld community are attempting to address that concern and are using Open Source Software concepts as their guiding principles. I recently had the opportunity to interview Brad Sileo of Ten Sails Consulting about his thoughts on Open Source as it applies to Smallworld.

I have noticed that SourceForge has a MagikComponents project. Is that the main focus of the current open-source "movement" in the Smallworld community? Are there other open source initiatives going on with the Smallworld product.

This project is the main area I am aware of, though there are several packages currently hosted there. In addition to the Magik Component library, the Minto Spatial Workbench tools are hosted on the same Sourceforge site. These separate sets of software are both offered under different public licenses.


What is the SourceForge MagikComponents project all about?

I think this project is about lowering the cost of ownership for Smallworld software, and allowing the Smallworld community to build towards bigger, more complex solutions through reuse. Of course, that's a pretty grand vision, and it would require lots of contributors to really make any impact. A less idealistic goal is to provide a simple framework to share some nice bits of code that make the system easier. I find that I always want the suite of tools from that mclib layered product on any system I work on because they save me from reinventing things over and over.


Why do you think the Smallworld community should consider an open source paradigm? What benefits do you see to customers, GE partners and GE itself?


On the grand scale, moving the entire Magik platform to open source would provide a silver bullet to the age-old "proprietary" claims of Smallworld competitors. In reality, the majority of the Smallworld platform actually is open source, with the exception of the virtual machine and the sys_core code. But, the distinction between open source and free software is a critical one - without the open nature of Smallworld source, programming would be very difficult in the system. If it was taken further and made available as free software, the growth in Magik development could certainly provide direct benefit to the existing customer through additional bug fixes, code libraries, and interfaces.
At about that same time that Smallworld was first putting out Magik, Sun Microsystems decided to release its internal, proprietary, cross-platform language and make it available as free software. Java took off like a rocket into many different application spaces on the strength of being open and available.


What kind of Licensing concerns are you aware of with respect to open-sourcing Smallworld? How do(es) the licensing scheme(s) of SourceForge address those concerns?


There are two licenses being used for software in the Mclib library right now - The GNU Public License(GPL) and the Lesser GNU Public License(LGPL). The main difference is that the lesser license is intended to be used with libraries, and as such does not require that all code built from it be released for free access. I would encourage folks publishing items through the library to understand these licenses and consider which is appropriate for their software. I have heard some developers express concern about using modules in the library because they fear this will require them to publish all of the code in their systems for open use. As a practical matter, in most cases, the majority of code built on top of tools from this library is not reusable in a new context. The use of the LGPL mitigates this concern, which is why I have been working to move modules to that license. Of course, it's worth a read of the software license agreement delivered with Smallworld Core Spatial technology, which actually supersedes all of this discussion with its stance on derivative works.


What kind of actions from the Smallworld community (vendors, partners and users) would help further the open source cause?


There would be some benefit in more organizations recognizing that they get value from open source software and thus aiming to return reusable items to the library. There will always be a battle between closed/commercial software makers and the open source choice, which is no different in the Smallworld space than in operating systems, word processors, or web browsers. It takes a critical mass of contributors to push an open source initiative to the point where it can produce its own momentum. When that happens, the benefits start to magnify for the existing users and you can get an exponential return for the overall community in available functionally and software quality. This momentum also pushes the commercial software to compete with the open solutions, which further benefits the consumers.


*I also conducted the same interview with a colleague at GE Energy. He was able to provide insightful answers to the interview questions. But when he sought approval from his managers he was prohibited from publishing his comments.

Thank you to Brad and my unnamed colleague for their contributions (published and not) to this article.


I'm interested to hear if there are other Open Source initiatives in the Smallworld community. If anyone has information about this, please post a comment to this blog or send me an e-mail.

I wonder if we could get an official response from GE Energy to the question: "How do you see Smallworld working together with the Open Source paradigm?" Maybe it is something to ask them at the upcoming GITA Annual Conference. I would welcome that dialog.

7 comments:

Bill D'Arcy said...

Great topic - I'll be cheering (even if only from the sidelines) if this gets some traction. I have seen first hand the effects of the so-called 'closed system' argument being held against the Smallworld solution. It remains a real disadvantage - not because it's true, but due to the fact that it's an easy argument to make to those who don't necessarily have the insight, perspective and/or knowledge to know the difference or to question it.

I look forward to hearing GE's 'official' response. I would hope they would see the value this can bring.

Anonymous said...

I manage the GIS division for a large utility, and have been in the GIS field for over 25 yrs now, with hands on development experience with just about all GIS platforms.

Smallworld is about as proprietary as it gets.

Yeah - it is still best of breed when it comes to version management, and modeling of complex networks .. but the gap is fading quickly.

And .. regarding how "open" Smallworld is .. I really don't give a hoot about whether the product source code is available thru open source.

I want to be able to use an industry standard development language and IDE .. I want to be able to leverage other IT software development personnel who are not specifically GIS professionals .. I want to access the data thru standard data reporting and query tools .. and I want to easily integrate it with other technologies and applications.

The "open GIS" train left the station about a decade ago, and Smallworld missed it.

The closest thing Smallworld has to that is SIAS, and that's not a match for what GE's competitors offer. Not even close.

Kirk said...

I think that making Magik open source is a fantastic idea. GE is certainly big enough to absorb any negative impacts and the positive benefits of making Magik more open is to diffuse the negative arguments about Smallworld that I often hear like it is not "standards based". This type of attack is easy for Senior Management to get scared of - and they will not understand "Object Oriented" even at the most basic level. GE can only win by making Magik more accessible.

Alfred Sawatzky said...

Hello "Anonymous from large utility".

First of all, I would like to thank you for taking the time and energy to post a comment. I also appreciate that you have identified what part of the Smallworld constituency you belong to (ie., large Smallworld GIS customer). It helps the conversation when we know that your comments are borne out of using the Smallworld suite as a large utility customer.

I cannot speak for GE, but I would like to make a few suggestions to some of the issues you raise.

Industry standard language
Clearly Magik is not a widely-known language. The most relevant product I know of out there that could allow your IT software development personnel to access VMDS data without having to know Magik is the SWConnector by Spatial Business Systems, Inc. I saw a demonstration of it a year ago at GITA in Tampa and it seemed quite promising then already. Using the connector should allow .Net developers in your organization to start developing in the .Net environment using data from VMDS. Now if only someone could write a similar connector for Java. There is already a Smallworld-provided OLE/Automation connector that allows you to write applications in VB (or other OLE-supporting languages) that access Smallworld data. Unfortunately, my experience with OLE has been that is has slow performance and there is no support for sending maps via OLE.

Industry standard IDE
A very populate IDE nowadays is Eclipse. ASTEC (Advanced Software Technologies) has developed a plugin for Eclipse called MDT (Magik Development Tools) that allows Magik to be run in a standard IDE. Eclipse has been popular with Java developers and I suspect that running Magik from this IDE will make some of the development transition to Magik a little less painful.

Accessing data thru standard data reporting and query tools
I described one way of opening VMDS to Oracle here. If you follow that approach then it would be easier (but definitely not trivial) to use standard data reporting and query tools against the VMDS data.

SIAS
I agree that the SIAS in the past may not have been as easy to use as competing products. I am eagerly looking forward to seeing what the new SIAS product (with new architecture) will offer.

Thanks again for your contributions to this important discussion.

Anonymous said...

Hi Alfred ...

Now if only someone could write a similar connector for Java.

Stay tuned, for an announcement abou exactly this in the next couple of months :)

Alfred Sawatzky said...

Hello Anonymous (if that's who you really are)

Are we going to get more than a teaser? Who, what, when, where?

Stuart said...

Sorry about the Anonymous posting (pressed the wrong radio button in blogger).

It's a Magik interoperability framework which allows magik objects & behaviour to be accessed from Java (.Net & C to follow).

eg.

public static void main(String[] args) {
MagikContext magik = Magik.openLocalContext ();

GisProgramManager gpm =
(GisProgramManager) magik.getGlobal ("gis_program_manager");

MagikDataset ds = gpm.getCachedDataset ("gis");
Iterator iter = ds.getCollection ("min_road").iterator ();

while (iter.hasNext ()) {
MinRoad road = (MinRoad) iter.next ();
System.out.println (road.getName ());
}
}

In addition to the core framework, we also have some specific extensions that make it easier to use version management functionality, rendering, interactive selection etc. in Java applications.

Currently we're looking at whether we just use it internally for product development, or whether to release it.

No firm decision has been made yet, but the timetable for any announcement would be sometime in May and then a release date in June.

- Stuart