You have just read a blog post written by Jason McIntosh. If you enjoyed it, please anonymously acknowledge your visit by tapping the little star button underneath it.
Thank you kindly for your time and attention today.
Spent the first half of the week in Raleigh to attend All Things Open. This year marked its fifth iteration, and the first one I attended, alongside some 3,499 colleagues in the software business. With a stated theme of “open source in the enterprise”, it seems to have a particular focus on “devops” — the software-engineering sub-discipline focusing more on integration and deployment of code than its development per se — but its broad spread of tracks did its best to cover a full spectrum of software-related specializations.
All of which is to say I felt a little out of my depth, because I identify professionally as a freelancer, avoiding any title more specific than “engineer” (or “hacker”, but only among kindred spirits). I answer directly to clients who don’t really care how I deliver my magic, so long as it happens. While this situation works well enough for me day-to-day, it carries the compounding danger that I too will stop caring how I do what I do. And that is why from time to time I frogmarch myself onto a train or plane that’ll take me to a great big conference like this, marinating me in ideas and practices that the whole world of software-crafting talks about outside of my tiny bubble.
I had a good time! I learned a lot, met some great people, and I have a lot of new ideas to unpack and process, which will lead to plenty of project-specific followup work for myself. For now, though, I can share three major takeaways, based on themes that ran through the whole confernece.
To bring something new to the table in any business means, today, to also get into the software-development business. At least two speakers directly referenced a 2011 Marc Andreesen op-ed titled “Why Software is Eating the World”. The column sits behind a Wall Street Journal paywall, but I gather the gist of it anyway: running any modern business means running software, and businesses that don’t wish to float passively through their respective markets must actively develop their own software, even if their ultimate service or product has nothing to do with software per se.
My BS-detection instincts would have me push back against this concept as self-congratulatory hogwash arising from any large gathering of software creators. But: who are my clients? Currently I work with a Boston-area travel company that — through me — has written its own reservation system, in order to give itself a competitive edge, and I also assist an international publisher that continues to maintain a thoroughly custom and vastly complex account management system.
In fact, each client I’ve worked with over my ten-year freelance career is a business or organization that wished to distinguish itself within its market by doing things its competitors couldn’t, and that literally means commissioning the creation of new, in-house software, which it then subsequently owns and maintains indefinitely. So… yeah! I’d never thought of any of this the way Andreesen phrased it, but I can hardly deny it.
Tech giants have begun sharing a dizzying array of free-ish public APIs. Want your own natural-language-processing instance of IBM’s Watson? You got it. Want to write something that lets you send queries directly to Amazon’s in-house image-recognition AI and receive responses back in plain English? Knock yourself out. Two talks I attended oh-so-casually referred to these particular services as if it’s the most natural thing in the world to base the core of your program’s functionality not on any locally installed library but some bit of well-documented hand-wavium way up in the cloud, operated and made free-as-in-beerly available by one benevolent capitalist overlord or another.
Now that I describe it in writing, it reminds me of a central plot point from a recent William Gibson novel. This involved a seemingly impossible web service that ran out of China, and none of the European protagonists felt more than mild curiosity about how it worked, much less who paid for it or why. I find it fascinating and maybe a little nerve-wracking and I should really set some time aside to explore this unexpectedly real-life landscape for myself.
On personal computers, the browser “won” a long time ago. Even though All Things Open did not have any explicit topical restriction to web software, I did not see a single scrap of support for or discussion about public-facing applications that ran natively on any common operating system. I did attend many interesting talks on internal tools and processes, but in every case, these ultimately served the creation and maintenance of web-based software.
In retrospect, I think I would have expected at least a little representation for, I don’t know, at least iOS or Android development tools, and maybe Windows — but, no. With the sole exception of video games, the web is the default target platform for all software. If you make (non-game) software today, and you don’t specify otherwise, others can be safe to assume that it runs on the web.
This does not represent any shockingly fresh revelation, of course! Every Perl-specific conference I’ve attended has focused on either web apps or obscure internal tools, but these sorts of creations seem endemic to that programming language so I didn’t give it much thought. But it’s not just Perl, it’s everything. And it seems so natural to me that I didn’t stop to think about it until the flight home.
(I did also learn about software specific to small devices — wearables, Raspberry Pi experiments, and so on — but I class these less as “applications” than as the soft side of very hardware-specific projects.)
Previous post: I read American Flagg!: Hard Times
I attended All Things Open 2018My second visit to this annual open-source conference inspired me to improve my own project leadership, organizational repping, and joyful public API hackery.
I’m a weird place with Perl (and so is Perl)A meditation on my relationship with Perl, and Perl's relationship with the world, 20 years after I started using it.
If a page elsewhere on the web responds to or otherwise mentions this post, you may provide its URL here.