Oliver Roick Homepage
Brett Cannon making a point, grounded in philosophy, about the relationship between open-source maintainers and users of their software
When you treat a maintainer as a means to getting something from their software you are not morally treating them appropriately as an end (in other words, you’re simply using them), and thus not treating them morally as a human being. But when you treat a maintainer as a fellow human being who may be able to do you a favour of their own volition, then you end up in an appropriate relationship where you are not trying to use the maintainer for something specific.
And to conclude:
There should be no expectations toward the next commit, next release, etc. when you realize open source maintainers really don’t owe you anything. If you view open source code from that perspective then you will view it as a gift when it exists at all. As such, hopefully you feel less frustrated when open source doesn’t go the way you want since it was all a gift to begin with. And that then will lead you to treat maintainers as an end in and of themselves and thus as a fellow human being.
There is work that looks like overhead for a personal project or seems to hold you back at the beginning of a professional project but will pay off later in the product lifecycle. Simon Willison calls them PAGNIs — probably are gonna need it.
When should you over-ride YAGNI? When the cost of adding something later is so dramatically expensive compared with the cost of adding it early on that it’s worth taking the risk. On [sic] when you know from experience that an initial investment will pay off many times over.
Test automation, continuous integration and automated deployment are non-negotiable PAGNIs. API pagination, time-stamping records, and logging API traffic are others I didn’t think of initially but are just as important.
Logging request payloads proved to be especially valuable in previous projects I worked on. Tracking down bugs that only affect certain users is almost impossible if you do not know what data clients send to your backend. Plus, we were able to recover hundreds of transactions in the aftermath of an incident.
Paul Ramsey, the creator of PostGIS, looks back on the early days of the spatial database extension for Postgres:
When Dave had a working prototype, we hooked it up to our little applet and the thing sang. It was wonderfully quick, even when we loaded up quite large tables, zooming around the spatial data and drawing our maps. This is something we’d only seen on fancy XWindows displays on UNIX workstations and now were were doing it in an applet on ordinary PC. It was quite amazing.
Around 2004, after exclusively doing GIS only in ArcInfo, I worked on an online atlas for a local environment agency. We used PostGIS, MapServer and the Rosa Java applet in the front-end, all duct-taped together by some pretty awful PHP code. Nevertheless, there were solutions now that allowed us to put interactive maps on websites. Being able to store and retrieve data from a performing open-source database was one of the foundations that made modern-day Web GIS possible.
I‘ve hardly worked with any other spatial database since, other than occasionally toying around with CouchDB or SpatialLite.