PostGIS gets Spherical

One of the items we launched with our new web site this spring was what we have been internally calling "the menu", and ended up calling "core development". The premise is that a generation of proprietary software experiences have broken customers of the idea that they can directly pay a vendor for a new feature -- as customers we've been trained to just wait until the next version and hope.  But in an open source world, developers (us) are happy to work on new features directly for customers. So in our core development "menu" we try to provide customers with some guidance about what is possible, writing up some descriptions of larger development pieces and enumerating the functionality they would provide.

One of the items I put in my PostGIS menu last spring was "geodetic types", native support for latitude/longitude coordinates that allows for indexing of features that cross the poles or dateline, provides direct calculation of distances and areas on the spheroid, and integrates with the other functions in PostGIS.  And a few months ago, that menu item was funded by a client!  We are currently approaching the final delivery date, the code is committed to the PostGIS SVN repository, and I'm spending the rest of the week testing and polishing.

Amazingly, the open source development started paying off almost immediately -- I was getting testing and bug reports from third parties very early in the process, which means the final delivery will be that much stronger for the client. I've also added a large number of functions above and beyond those itemized in the contract terms, since this code is going to be in wide use as soon as it is released.

To get a feel for the functions that have been added, check out the documentation for the upcoming PostGIS release. For more technical details on using the new type, see this post.

EmailTwitterFacebookGoogle+tumblrLinkedIn

18 thoughts on “PostGIS gets Spherical

  1. "a generation of proprietary software experiences have broken customers of the idea that they can directly pay a vendor for a new feature".

    Bzzzzzzztttt! Wrong!

    I've got a request right here in my Inbox from a Cadcorp GeognoSIS user for enhancements to our WMS implementation. We've quoted for the work, they have accepted the quote, and we'll be implementing it soon. And, no, not just for that user, but for all GeognoSIS users. Think of it as a "core development"; we do.

    We've also added features in the past, and will do so in the future, in order to win particular business, in part by regarding the licence fees as payment for the new development, and in part by recognising that the new feature is useful for more than just the new user.

    So, keep the sweeping generalisations down please. Or perhaps Cadcorp is the exception that proves the rule.

  2. Hum. On the one hand, on the other. I can, when I put my mind to it, count quite a few proprietary companies that are notably open to comment and fast to respond, CadCorp and Safe amongst them. And yet, when I look at the mentality of customers around features and new releases, I see a mind-set that is extremely passive. Even on open source project lists, you'll see people asking after the next release rather than asking after functionality they need. And that's those proactive enough to ask about the next release. I think the general software population does have an "it is what it is" psychology about software, do you not see that? If you do see that, where do you think it comes from?

  3. Could it be that what they want to do with the software just doesn't change that much, or that quickly?

    Existing users (of any software) want it faster, and prettier, and easier to use, and so on, but they don't often, overnight, suddenly need a fancy new widget.

    Potential new users are different. If the software is missing what they need then they will look elsewhere, or - in your case - say "how much to get it added", or - in our case - say "we won't buy unless you add this".

  4. Hi Paul, I agree with Martin on this one, I think you make too broad a generalization here and that risks damaging the credibility of your argument. Throughout my career, all the closed source companies I have worked for like Smallworld and Intergraph would often develop specific features for a customer who paid for them, or would commit to certain new features to win a contract. The Intergraph Computer Aided Dispatching System went one further, and used a voting system developed by the user community to determine what went into the next release. I think you're better off making the argument along the lines of "OpenGeo's open source solutions are very responsive to customer input, here's an example. We think many alternatives are not that responsive". Then people can look at their own experience and make up their own mind.

    I actually think that responsiveness is probably more tied to the maturity of the product rather than the open versus closed source issue. Most products that are relatively new, with a small development team and small customer base, are in general pretty responsive to customer input (with or without specific payment for work) in either world. For more mature products with large customer bases, the issue is harder - what if you have not one specific customer request, but several hundred customers who want to pay you to do different things, a lot of which are inconsistent with each other? That is a hard problem to solve whether you're in the open source or closed source world. If I don't like the way something in Linux works and want to get it changed, there will be all sorts of compatibility issues and it's not just going to be a simple case of me paying someone to do what I think is right.

    Anyway, to get more specific I think there is validity to the argument that it is probably a lot easier and quicker to get a specific enhancement made to PostGIS than to, say, Oracle Spatial. But I think you just need to think about the best way to present that argument - the "closed source software companies are evil and completely ignore their customers' wishes" (which is a slight exaggeration but somewhat how your argument comes over) is too sweeping and risks alienating a lot of people who might buy the argument if it's just presented a little differently.

  5. This isn't good or evil, guys, it's the way different economic models condition customers expectations. If, as Martin notes, proprietary companies have the luxury of "regarding the licence fees as payment for the new development", how will that expectation play out in customers expectations for product development? What happens when they transfer those expectations to open source? Well, odd things, like people expecting that new obvious feature in the "next version", despite not ticketing it, asking for it, or, er, paying for it.

    It's not that proprietary companies are evil, it's that the proprietary model (and lets be clear, that is the model we have been working with for 25 years) makes people expect the vendor/customer relationship to work in a "certain way" that can be a bad fit for making use of open source. Software purchasing processes often have the same biases towards an "upfront fee" model.

    We've found that being clear about what features we can add helps people get to the "oh, yeah" point faster. Otherwise they tend to bring their old model that "it is what it is" to the table.

  6. Paul, don't get me wrong, I think that your "menu" approach is a good one. And I agree there is education needed as the business model is different with open source.
    I just think you are making too much of a generalization about closed source software users having an "it is what it is" mindset - most of those that I worked with were very proactive in letting us vendors know what they wanted (and in many cases paying for or otherwise helping out with those enhancements).

  7. I mostly agree w/ Peter's comment about maturity level and the speed of implementation of feature requests. We also have a menu of requested features, and alter the order of completion of those feature requests by the willingness of someone to pay.

    However, there is another way to approach this feature issue - namely by being "hackable" at the API level. We find that providing access to APIs that expose many of our core features, addresses many of the specific customer requests. "Openess" can occur on many levels. Enhancing your customers ability to help themselves is one (our) approach to creating a self-sustaining product ecosystem.

  8. I totally agree with Martin here. Its not about the model its about the attitude of the company and its approach to product development. The model is irrelevant. We have a lot of customers who move from open source to our proprietary software (yes people do move the other way you know) as I'm sure Martin does. When you ask people, its usually about a feature that won't be implemented or will taken too long. Your menu is just a product roadmap. You won't find a company that doesn't have one and whose customers see and influence regulary.

    Your comments are way too sweeping. Open or proprietary it's just about the approach of the company.

  9. I'm sure your companies are all lovely, but I'm not talking about companies, I'm talking about customers. What is the customers' mental model of the transaction process that causes new features to appear in a product? How do I get a new feature into Windows? How do I get a new feature into Linux? If my mental model of "new feature" is Windows-based, I'll never arrive at the psychological place where I hire a company to add the new feature I need in Linux.

  10. Oh, and Peter's point is taken on the customers, there's certainly lots of pushy SOBs who'll make sure you know what they want, regardless of whether they are dealing with OSS or proprietary. The population of customers is hardly uniform. But there's lots of blushing violets too.

  11. I built and sold a business (GDC) on the basis of responding to customers' feature requests. Our customers were our the principal source of our product roadmap and the feature that one customer requested (and contributed to the cost of) all other customers then received in the next release.
    I wish that I could say the same for other software regardless of open-ness of source e.g several years of bugginess and memory leaks in a certain much loved browser. Apologies for that but I think maturity, complexity and conflicting requests inevitably mean that software developers (open or proprietary) slow down in their responsiveness.
    Steven

  12. Paul, I have been fascinated by this debate, but ultimately have to disagree with your description of customers of the 'proprietary model'. We are a small (proprietary) GIS firm offering a (currently!) niche 3D based product. I could not characterise any of our clients as 'waiting for the next release' type as we are in constant dialogue with them trying to accommodate an ever-increasing list of feature demands. These guys know what they want. We've had to employ the normal prioritisation rules, but we also provide to our client user forum a bundle of 'free development time' to implement whatever they select (as a community). We find that this process engenders a better response from clients who move from the knee-jerk 'we want this now' perspective to 'this is what will provide us real value'. All developments / enhancements are made available to all clients. To those that really are "outside the box" we offer an API. So I'm guessing that this has nothing to do with the 'business model' that we offer our software under, but everything to do with the relationship that we have with our clients (which hopefully they would describe as 'open').

  13. Paul, I'm also talking about the customer. A customers' mental model for getting a new function implemented is surely directly defined by how a company approaches product management and talks to its customers. Everything you've talked about is just good product management. Some companies have a closed approach, some very open, its irrelevant of whether you are an OSS or proprietary outfit.

  14. Yes, it's a mix of mentalities, as Peter says. Now, what do you think is the dominant mentality? Right now, Microsoft is running a series of clever adds where the amusing trope is the idea that (very) ordinary people made suggestions and Microsoft acted on them. "I'm a PC and Windows 7 was my idea."

  15. We'll be wiring your new spherical stuff up to our GO Loader product ASAP as we've had customers waiting for ages for you to implement that ;)

  16. Har, har Ian. I'm not sure if that proves my point or negates it. :)

Comments are closed.