viernes, junio 24, 2011

Is propietary software better for developers?

I have recently been programming the SEXTANTE bindings for ArcGIS (they are not finished yet, since I am having a very busy week with other priorities, but I will resume working on them next week and hope to have them ready soon) and working with the ArcGIS API has made me think a bit about how the propietary software model can somehow be an advantage for a certain kind of developers. I am not, of course, saying that propietary means better (I will always prefer open source to propietary), but there might be a few things that we can learn from propietary software developers and some positive side effects of not sharing your source code.

This all comes from the following fact: being a complete ignorant about ArcObjects and the ArcGIS API, I have been able to create the corresponding SEXTANTE bindings from scratch in less time than I needed to create any other bindings before. That means less time than the gvSIG bindings (an application that I knew pretty well), and way less than the OpenJUMP or Geotools ones (both of them softwares that I had worked with before, at least once).

This is basically due to the clean, well designed and perfectly documented API of ArcGIS, which, along with the additional Eclipse plugins, makes it very easy to develop new plugins and extensions for the software. Unfortunately, open-source GIS lack that kind of APIs, or they are, at least, not so carefully designed, documented and implemented. Although other factors might concur, I am convinced that the propietary nature of ArcGIS is a decisive one to have such a powerful and developer-friendly API.

Let's put it this way: ArcGIS developers want other developers to create plugins for their software, so they have to provide an easy way of doing so. However, they cannot let you see the source code or their application, so they have to make sure that everything that an external developer might need to create his plugin is correctly exposed through their API. The API has to, somehow, replace the source code for certain development tasks. On the other hand, open-source programmers are aware of the importance of developing a correct and well documented API, but the availability of source-code might act as an excuse for sloppy or unfinished APIs, assuming that, if an external developers misses anything in it will search the source code and try to find whatever he is missing.

That doesn't necesarily mean that open-source APIs are not as good as proprietary ones, but, while an open-source software, even if it lacks documentation and has a poorly designed API, it is still useful (albeit frustrating) for a developer, the same circumstances will render a proprietary software useless in term of development. That alone should encourage proprietary software developers to create and document practical and useful API (and we all know that this is important, since that is not always a nice and rewarding task...)

Once again, I insist that I am not praising the proprietary model, but just trying to find its benefits and trying to learn from it and apply it later to my open-source projects. I believe that everyone can teach us something and there is always something to learn from everyone. And, although I am not one of those who see proprietary software as an enemy, even enemies can teach you a few valuable lessons and it is not a good idea to ignore them. Quoting the much-missed Rage Against the Machine: Know your enemy :-)

miércoles, junio 15, 2011

Bug Tracker

I am pleased to announce that we already have a fully-working SEXTANTE bug tracker. Instead of using OSOR's one, we are now sharing the gvSIG CE (Community Edition) tracker. I will soon put a link on our website. In the meantime, here is the tracker URL:

http://gvsigce.sourceforge.net/mantis/main_page.php

This also shows our commitment to help this interesting initiative, and we will probably use the Wiki and forums of the gvSIG CE project, hoping it might help to unite all SEXTANTE/gvSIG users and work together to improve both software packages.

lunes, junio 06, 2011

Scripts as algorithms

i have been improving the command-line interface and I have added one new feature that I guess will be interesting for SEXTANTE power users.

The command line interface allows the creation of scripts that can be put in a separate file and then executed with the source(filename) command. If a method is written to to that file, then executing the file will make the method available in the current command-line session.

For instance, if we have a method like the next one,

mymethod(rasterLayer, vectorLayer){
//do something with those layers
}

executing the corresponding file will add a new method calle "mymethod" that I can use anytime.

Since we are running a scripting language, there is no need to specify data types for method parameters. However, now, if you add some information about those types as comments before the method, SEXTANTE can not just execute them from the command line, but also from the toolbox as a normal algorithm.

The above method should be something like this:

//rasterLayer=raster
//vectorLayer=vector
mymethod(rasterLayer, vectorLayer){
//do something with those layer
}

Those two comments are used by SEXTANTE to create the corresponding dialog.

If you put the bsh file in the scripts folder (which now you can define in the settings dialog), the method it contains will appear automatically in the toolbox as any other algorithm or model.

I still have to work more on this and document it, but I guess it's a nice beginning for a rather intereesting idea.