Written by At instaGIS we rely on several Open Source tools to perform some common operations. When you reuse proven and well tested third party code, and then enhance it to make it more secure or efficient, you really should give your enhancements back to the community.
As I said. Code reusability is a must among ninja developers, and we are. But it is also a must to repay your debts. Even if you use open sourced third party code (which is good, because there’s no point in reinventing the wheel when there are really good and proven libraries out there) you still have a debt. Not a monetary debt, but a moral debt.
During our regular developing process, which involves daily scrum meetings, unhealthy eating, working at insane hours and laughing our asses out several times a day, we also conduct the process of keep looking for the best tools for any given repetitive task.
Quoting my partner, Kammus:
…we noticed we had a lot of line breaks. After any sentence or semicolon, we had a line break. Our ENTER key was worn out, so we started looking for a third party library to break our lines for us.
Actually, I’m just joking. I hope Kammus won’t read this article. But what isn’t a joke is that we use tools such as GisConverter, and when implementing instaGIS capability to parse and translate KML files, we noticed that GisConverter was missing a feature we needed (in this case: parsing KML metadata). We modified the original library to perform the task we needed, but that was an opportunity to repay our debts to open source software. After building the corresponding tests to pack and deliver our contribution, we made a pull request to the developers and, guess what, instaGIS KML inner logic made its way to GisConverter for anyone to use.
Not too long after that, we made new pull requests to be able to parse old KML Entities and even made an adapter for WKB geometry format.
When it comes to javascript, we rely heavily in the library Wicket, to which we have contributed adding support for PostGIS BBOX elements, Google Maps API Rectangle and Circle elements and, recently, with support for the whole google.maps.Data family of elements.
Other collaborations worth noting are our MultiPolygon support for Doctrine Spatial, and bugfixes to NodeDirectUploader, OpcacheGUI and APCu.
Delivering your code enhancements back to the original project isn’t just about karma. I mean, there’s a lot of karma to it, but that’s not all. We also love to send our contributions back because when they’re accepted it means that our code meets the standards to be reused by others. For a coder, there no reward so sweet as peer recongision.
So that’s it. In too many ways, instaGIS escapes of any reasonable definition of “casual map editing”. Our customers demand from the tool the capability of handling impossible workloads, and several times we achieve that by refactoring existing tools: sometimes to to work in batches, other times to do their stuff just more efficiently. There are some design bottlenecks in common libraries that only come to surface when you try to use them to parse gigabytes of information, so I guess we’re also making stress tests that no one thought about.
In short: we use trustworthy, proven open source third party tools. We build on top and alonside those libraries, but sometimes, we also modify those libraries to handle increased workloads. If we can, we pack those enhancements into a pull request, and try to repay our debt to open source ecosystem by giving something back. We all should.