My phone screen flashed earlier this a.m. with the reception of e-mails indicating that a couple of fixes for typographical errors which I submitted some time ago for Fluent Python have been accepted by the author. I was motivated to submit them because of the near-perfection of the book, beautiful in concept and in implementation; it was my opportunity to help maintain a wonderful work. Just as importantly, the publisher made it easy.
The contribution of a quotation mark and a two-letter English word to a 740-page book is hardly remarkable. It is instead what is now an ordinary task made easy by the Internet — the same Internet that contributed immensely to the creation of the book in the first place, from the development and popularity of the subject matter of the book to the tools which were used to create it to the ability of a publisher to interact with more authors to the electronic marketing and commerce which resulted in my purchase.
This is not unlike the creation of the software we all use daily. A large amount of it has the mark of a company but it relies to a tremendous extent on open source software, easily obtained, usually easy to contribute to, and truly ubiquitous even in so-called “proprietary” software with which we interact. It works because of countless contributions big and small from developers all over the world, using collaboration methods made easy by the Internet. Ease of collaboration enables contributions which have further eased collaboration (not to mention the rest of electronic life), and the software industry is built on the result.
It is time to close the door on what has been called “open source strategy”, as the use of open source software and the need for strategies for appropriate consumption of the software and interaction with the communities has invaded even the darkest corridors of proprietary software development and become “business as usual.” All software projects are a fusion of open source and custom-built components, whether or not everyone involved acknowledges it.
I look forward to a refresh of my electronic copy of Fluent Python with the latest corrections. But since submitting those fixes to the book text, I’ve collaborated with a handful of open source projects in the Django ecosystem for the first time and seen most of my small contributions there accepted; I am still watching some of those for feedback from the project maintainer or for inclusion in a new release. Those contributions were an important day-job activity, enabling features that our customer requested which didn’t quite fit into the existing application.
Possible upcoming book contribution — convince the Two Scoops of Django authors to rework their claim that you can’t pass environment variables to Django apps running with Apache httpd :) I’m sure they think that Apache+Django implies mod_wsgi, and I guess it is not fun to pass through OS-level environment variables in that configuration. My 2 cents on that matter: Deploying Python Applications with httpd (PDF)