Hacker News Reader

Comment by eruci | Hacker News Reader

I was pondering this very question as I just launched an open source reverse geocoding/geolocation name service API ( https://3geonames.org/api ) whose business model consists upon selling a nicely packaged server AMI on AWS.

It works well both ways, in the sense that those who are capable coders may download and configure/install the software themselves.

Some others will just skip the hassle and buy the Marketplace version.

It is a win-win situation, insofar as someone does not take the time to repackage it and sell a competing version on the AWS Marketplace or some other sales channel.

I have not figured out that part yet. Any suggestions?

View on HN

Poor documentation is a strategy, and if it's poor enough you can run your own university/camp. A large complicated codebase is another strategy.

Edit: Strangely enough, I don't know anyone who did this on purpose.

I don't do that on purpose, but I'm guilty on both counts.

It seems that today is it is hardly a good strategy. Unless you are giving something so valuable and scarce, poor documentation is pushing away adopters. The average engineer will think about building the service on their own.

We talked about running a Pelias geocoder AMI back at Mapzen, and it still might make sense today. I'd be really interested to hear how it works out for you.

My personal feeling is that developers are irrationally averse to paying for someone else to set up and reliably run software for them, but that it's usually a massively good deal to pay for that service.

Even a simple software project that takes an hour a month to keep running is well worth most companies paying $100/month to not have to worry about, for example.

Developers don't want to pay that's true.. I hate a adopting a anything I can't setup myself or get cheap with a pay-as-you-go model.

But as soon as I'm deploying anything in a corporate setting, I would always prefer to pay rather than asking IT to setup and maintain a service. Or worse do it myself..

The combination is good. Because I would rarely try out something I couldn't run myself. But I would also never put it into production.

It has worked out relatively well. (Mostly due to the fact we have no competition on geoparsing )

There are a few geocoding AMI's on AWS Marketplace. ( https://aws.amazon.com/marketplace/search/results?searchTerm... )

Some big companies on the list (Pitney Bowes, Mapbox, Here)

I've always held Mapzen in high regard as one of the best geocoding APIs to come out of the opensource camp. Mapzen would have been a nice addition to AWS for sure.

Some companies prefer having their own server rather than sharing access to an API.

Oh wow I didn't realize there were so many! And yeah, geoparsing is a huge challenge above and beyond "standard" geocoding. Specialization like that is a great asset.

For us, we've really been focusing on the customization of Pelias for people who have specific needs. We have Elasticsearch under the hood which is perfect for that sort of thing, and the nature of customization is that an AMI probably can't do what our clients need. But probably someday it will make sense.

Is the data open sourced too?

Yes. It is from geonames.org

Reply on news.ycombinator.com