Tuesday, March 06, 2007

Kosmo - What fruit will you put in your basket? (Kosmo)

The last couple of weeks there has been some great discussion on a handful of different topics. Most of this discussion has centered on one of the JUMP 'brands” called Kosmo. Kosmo's development team has shown interest in contributing to the development of OpenJUMP. This has us very excited, as Kosmo contains a variety of great enhancements and new features. There were a few different ideas about how this collaboration with Kosmo could take place, and even some suggestions that we “jump” to Kosmo's code base. I wanted to take some time to talk about Kosmo and some of these ideas in a little more depth.

Kosmo demonstrates a very important reality. This is a reality that is important not only to OpenJUMP, but to other efforts at producing open source GIS software. Kosmo is currently maintained by 9 full-time developers. That wasn't a typo. You read it correctly. I said 9 full-time developers. Now I realize that 9 full-time developers is chicken feed to a lot of big software development corporations, but for a small open source program like OpenJUMP 9 full-time developers is an amazing commitment. (For OpenJUMP even 1 full-time developer would be an amazing committment.) I don't even think JUMP's parent company Vivid Solutions has the resources to throw 9 full-time developers at JUMP.

Kosmo's bold development of the JUMP code base shows us two important things:

[1] Given a serious commitment, an open source program like OpenJUMP can produce serious results.
[2] OpenJUMP/JUMP is a viable platform for commercial development and support.

If nothing else, Kosmo is worthy of mention and merits a measure of respect on for its demonstration of these 2 things alone.

I must, however, urge some caution and a little bit of restraint. I think the team maintaining Kosmo is doing some great work, and I hope we can tap into that work to improve Kosmo and OpenJUMP at the same time. However, we must not loose focus of some important traits that make OpenJUMP worth our time and energy. Traits that may not be shared by Kosmo. A lot of these traits I've mentioned before, when we talked about merging with Vivid Solution's JUMP core. But I'll take a few moments to mention them again.

The maker's of Kosmo are running a for-profit company. There is nothing “wrong” or “evil” about running a for-profit company. I work at a for-profit company, and if the owners didn't make a profit I wouldn't be able to pay my rent. Nor is there anything wrong with making money from the support and/or development of an open source program like JUMP. However, it is important to remember that the fate of Kosmo lies in large part with a single entity. This is a single entity that is driven by one primary goal. Profit. Sometimes the goal of profit creates no conflicts with the goal s of the user community, and sometimes it does.

Remember that OpenJUMP offers something that Kosmo and even Vivid's JUMP do not. Community driven development and maintenance. You don't have to worry that profit will taint decisions about how we will manage or maintain OpenJUMP's code base. Our decisions about OpenJUMP are always made with the best interests of our user community in mind, within the reasonable limits of our own natural biases and prejudices.

This community driven development philosophy means that we can achieve goals in OpenJUMP that we might not otherwise be able to. We can keep our code base lean and mean, without the pressure to continually add more and more features. We don't have to sacrifice code quality for the sake of a corporate deadline. We have the liberty to explore new features just because they interest us, not because its what a paying customer is willing to foot the bill.

Kosmo contains some really neat “stuff”. I'd love to see some of that “stuff” in OpenJUMP under the right circumstances. However, lets not forget that we develop OpenJUMP to appeal to a global community, and I think our focus with OpenJUMP is larger than the typical corporate agenda.

Some of the other developers have mentioned concerns about Kosmo's size and external dependencies. I think that these are valid concerns. Instead of adopting large chunk's of Kosmo's source code wholesale, lets be picky customers, considering carefully each piece of produce that is placed in our basket for inclusion into OpenJUMP.

The Sunburned Surveyor