2019 is only two and a half months in, but I’ve already been more active in the open source community than I had anticipated. During this short period of time, I’ve pushed code to the Esri Leaflet Doc, Esri Leaflet Vector, and Esri Leaflet Geocoder libraries. I don’t state this to boast in myself, but to document a segment of my journey participating in open source software development.
In this article, I wanted to share my experiences with open source software: my misunderstandings, my evolution from user to contributor, and the reasons I enjoy being a part of this community. Perhaps you’ll be encouraged to take the next step in actively engaging with open source!
The Open Source Process
I first discovered open source software when I was working for a small County’s Parks & Recreation department. I happened to be searching for a free GIS (mapping) software program. At that time, I had assumed free software and open source software were the same thing.
In my experience, many open source software programs/libraries are free to download and use. But there are some that require paid plans to use the product. Two examples are Esri Leaflet and Mapbox’s RoboSat. According to the Esri Leaflet Terms, developing apps that will generate revenue require a paid developer plan, or purchase of one of three products (which themselves have yearly maintenance support fees). In the blog post that announced RoboSat, Mapbox stated that feature extractions are free for OpenStreetMap contributions and non-commercial purposes (subject to map view & rate limits). But if you want to use RoboSat for commercial extractions, you are told to talk to sales.
So you may be asking, if these software libraries have a fee for commercial use, how can they also be open source? What makes these products open source is that anyone can contribute code to the library. And that is part of the power of open source software. It means someone like me, a local government GIS specialist, can push code to a project like Esri Leaflet, and improve the library for all the users worldwide!
Different projects have different guidelines for contributing. And by contributing, I mean creating a pull request to change the codebase, or to create an issue (i.e., a bug) with the project. Whenever you create a pull request, a few scenarios my play out:
- The project maintainers never acknowledge your pull request, and it just sits there through all the ages.
- The maintainers review your pull request, and request changes before accepting.
- The maintainers review your pull request, approve, and merge your code into the project.
I have had all three scenarios play out. And boy, does it feel good when your pull request gets approved, and you know that you helped make an open source project better!
My Experience with Open Source
I’m going to frame my experience with open source software within working with Leaflet.js and the various Esri plugins for this web mapping library. I used to follow a now defunct blog from Directions Magazine that would highlight web maps. Most of these were built with the Esri JavaScript API, but every now and then, one would show up that was built with Leaflet.
So when I, a novice JavaScript developer, stepped into the waters of building web map applications, I started with the Esri JS API. I didn’t get very far, and grew frustrated. I remember sitting in a GIS Day session on StoryMaps, deciding I would give Leaflet a try. I definitely got farther with Leaflet. But then an important question arose: could I use my organization’s existing Esri REST services with Leaflet?
The answer was yes! There are several plugins for Leaflet that integrate the Esri REST API. However, these plugins will never fully mimic the Esri JS API. And so I began building simple web map apps with Leaflet and Esri web services.
During the course of developing these maps, I encountered some issues with unexpected behavior. One of these was a quirk with the geocoding plugin. It was related to searching against a feature layer after searching against a geocoding service. Another issue was with a special map service rendering plugin not displaying the symbology of a web service for a map embedded on a Drupal site.
For both of these cases, my contributions to open source were creating an issue on the respective projects to document a bug. Others worked on creating the fix. New versions were soon released, and the projects were better for everyone.
The next step in my journey was working on the documentation site for Esri Leaflet. This is the place where people go to learn how to use the API/library. They can learn the nuts and bolts of each feature, and see helpful examples of code. I wrote some tutorials, made tweaks to the API reference, and even helped improve the site layout on mobile devices. These were some of my favorite contributions. Editing a project’s documentation site might not be as flashy as adding in new functionality, but it is crucial to the project’s success.
The most recent step in my journey has been pushing new code to these libraries. It took me a while to build up the confidence to attempt this. And I wasn’t sure what would happen after I opened the pull request. But most of these changes were accepted (with some additional edits requested by the maintainers).
These were all simple things. I was reviewing the ArcGIS Online “raster” basemaps, and noticed there were some that were not included in the Esri Leaflet plugin. There was a standard template for adding these. So, I just added a few to round out all of the available options. I did something similar for the experimental vector basemaps plugin.
My most recent contribution has been fixing a bug I actually created an issue for. The issue was related to the geocoding plugin and mobile devices. During normal behavior, the user would get suggested matches for what they searched. They should be able to scroll through the list and select their choice. But something changed! The user would try to scroll through the list, and the plugin would select the first thing they touched.
The issue was supposedly fixed, but I tested multiple releases of the plugin that all exhibited the same issues. And a couple more issues were opened related to this. So one day, I decided I would try to fix this issue. And fortunately, I was able to fix it!
I would say one-quarter to half of my contributions to Esri Leaflet have occurred in 2019. It wasn’t what I was planning, but it’s just what happened. Some of these I did while at work. And some I did in my free time after the kids went to bed.
Encouraging Other Professionals to Contribute
So why do I participate in open source software development? I am using open source libraries to develop web map applications for my organization. I am using technology others have helped built. And I want to do what I can to make these libraries better for other users worldwide. It is about giving back to a global community.
I’ve come across some articles that criticize companies for using open source, but not contributing to it. It is my personal belief, that any organization using open source software should be contributing back to open source software. I believe that is what helps makes this successful.
I work in the geospatial profession. The major players in this field are government agencies, non-profits, educational institutions, and private consulting agencies. I don’t see any reason why any of these sectors can’t give back to open source. These contributions can be working on bug fixes, adding in new functionality, or improving the documentation/API reference. Let me close this article by providing some ideas on how organizations can incorporate open source contribution into their practices:
- Give their employees dedicated time each week to work on open source projects (and make it protected time only for that)
- Encourage their employees to teach others these libraries at professional conferences
- Create/sponsor/promote one-day or half-day events where professionals can get together to work on open source projects together. Sort of like a hackathon, but with the sole purpose of contributing to open source
- Incentivize open source contributions. Bonuses, extra paid time off, or gift cards, based upon the amount of contributions, or number of bugs fixed.
So, what are your thoughts on contributing to open source? What are some other ways organizations can incorporate this practice into their culture or day-to-day operations?
PNM Carto Design Blog 
Thanks for sharing.
LikeLike