“Don’t write your own X” — authors of an X
(Go ahead and write your own frameworks and crypto folks. It’s a great way to learn.)
— xnoɹǝʃ uɐıɹq (@brianleroux) November 2, 2017
I wrote yesterday about the pointlessness of trying to be overly prescriptive about the language we use in talking about tech. Arguing about serverless vs Function as a Service, for example. I argued it’s generally OK to give things a name, or riff and re-appropriate terms that have been around for a while. The prescriptivist tendency however goes further – actively claiming we shouldn’t build something because someone else already has. But that’s just not how the world works any more. We live in in the post-permission era when it comes to software and technology. You don’t need to ask permission to scratch an itch. Cloud, open source, GitHub, social media – learning, building and sharing is frictionless.
Welcome to Mastermind, what is your chosen specialist subject?
June 1st 2014 to June 3rd 2014"
— Richard Dalton (@richardadalton) September 5, 2015
No more container orchestration platforms. No more X. But aren’t we led along to a reductio ad absurdam pretty quickly here? No more key value stores. No more databases. No more programming languages. Read my lips – no more new technology. That’s just not how the world works. Neither would many of us want it to be that way. Choice may carry a cognitive overhead, but it’s also fun. It allows us to join communities, to argue about stuff, to believe we have good taste, to learn and to share and to teach. Choice also of course means sadly that we sometimes exclude, tell other people their choices are bad, and make sub-optimal decisions. Ideally we limit the less constructive behaviours. Technology development is social.
Opinions are great. Opinionated infrastructures, which lessen cognitive overheads by making choices on behalf of the developer or engineer always have a place. But so do open tool-chains. One of the most interesting aspects of the Docker phenomenon is that it fits so well into so many people’s tool chains. Docker has an opinion about packaging, but doesn’t tell you what platforms and tools you should use. Put some scripts together and you’ve got the dynamic infrastructure that works best for you and your team, on pretty much any platform. Sometimes that script you wrote is going to be useful to other people. A precriptivist might argue you shouldn’t share it. But the fact is when it comes to software we are faced with a Cornucopia of the Commons, a horn of plenty stuffed with software goodies and the means to play with it. This essay was written in 2001.
“Yet lurking in the shadow of this mighty new industry, the free software movement has quietly persisted and grown, exemplifying the stubborn vitality of the gift economy. Empowered by the Internet, a global corps of computer aficionados arose to develop, improve, and freely share software. This process has generated hundreds of top-quality software programs, many of which have become critical operating components of the Internet.
What most distinguishes free software from off-the-shelf proprietary software is the openness of the source code, and thus the user’s freedom to use and distribute the software in whatever ways desired. Anyone with the expertise can “look under the hood” of the software and modify the engine, change the carburetor or install turbochargers. Inelegant designs can be changed, and bugs can be fixed. Sellers cannot coerce users into buying “bloatware” (overblown, inefficient packages with gratuitous features), Windows-compatible applications, or gratuitous upgrades made necessary by planned obsolescence. Free software also allows users to avoid constant upgrades in computer hardware.”
Would we really want it any other way? Freedom to tinker. Freedom to learn. Freedom to remix. Freedom to share. Sometimes we’ll make the wrong choices, but in an era where we’re designing for composability, with its attendant quality of disposability, it makes no sense to tell people not to build things.