As a young child with only the scarcest grasp of programming, I spent endless hours using ResEdit to crack open and customize every application on my mac. Every game and utility was filled with its own surprises; graphics I could edit, tables of strings to pore over, dialogs to rearrange, menus to customize, and so much more. I never had a manual, but everything was so straightforward and clear I learned everything I needed by experimenting. The entire experience was intensely empowering and gave me a wonderful sense of ownership and instrumentality over my computer.
The project that currently occupies most of my time, Decker[0], is a rapid development platform that can produce standalone single-file HTML "applications". The detail I'm most proud of is that every such app still contains the entire suite of editing tools: anything made with Decker is ready to be customized and extended by end-users.
Me too -- same exact story with using ResEdit as a kid to customize menus, dialogs, graphics! Then one day I found a "Super ResEdit" which did all the same things as the original but also disassembled a program's binary code into the 68k assembly.
It took a while for me to understand that I could do anything with that (or might want to do anything with that), but eventually I realized that there were descriptive names for sections (function names!), and that there were patterns in the list of opaque words like "CMP" was usually followed by a "BEQ" or "BNE", and hovering over one of the latter two would pop up an arrow to another line, just like if I hovered over a "BRANCH" -- aha, "CMP" must be "compare" and then "BEQ" is branch-if-equal, and "BNE" is branch-if-not-equal!
That was approximately the first time I realized that computer programs weren't magic, that they were complicated things built out of simpler things, and that it was possible in principle to see and understand the simpler things.
Then I realized I could change how it worked, just like changing the menu bar or graphics, by changing the corresponding hex codes next to the words! First time was to find a section like "checkIfRegistrationCodeIsValid" and notice a "CMP" followed by a "BEQ", and change that to a "BRANCH"...
Since you're here: I love Decker, it's exactly the sort of thing I want to get my kids playing around with. It's clearly a labor of love, keep up the good work!!
But how in the hell do you read that source code. I've seen some gnarly C in my time but man what even is that. How are you able to maintain this? It's beyond me. Please explain!
I use a handful of macros to abstract out repetitive patterns (EACH is a for-loop that iterates over all the elements of a lil list/dict), very short names for the most frequently-used utility functions (lin: lil-is-number? lil: lil-is-list? lmn: lil-make-number, lml: lil-make-list, etc), and typically aim for one idea/process per line, rather than one statement.
I find most C code dreadfully verbose, repetitive, and sparse. This style makes much better use of screen real estate and allows me to look at even fairly complex routines all at once, without having to scroll or jump around. Many APL-family languages use similar conventions in their implementations, though often relying much more heavily upon macros and abbreviations than I do.
It was a different world back then. To become “online”, you dialed a number. Then it was the time to search and download files, and to save pages for offline use. You probably also turned off images and JavaScript and accidentally learned HTML by looking at the text source of that broken layout.
The rest was an offline experience. You tinkered with the precious downloaded files. You knew how to change bytes with a hex editor, even if you knew nothing about the format.
I came to say the same. ResEdit was true tinkering... you could swap images, change user visible strings, menu items... I even managed to remove copy protection from a game (which I didn't have any way of purchasing due to being in a different country and stuff) which was compiled with (some) symbols and even though I didn't know 68000 assembly I figured out how to skip the call to the function which asked you for some word in the game's manual.
Years later, programming in Win32, I found you could do a lot of tinkering by getting window handles to windows and UI elements of other programs and changing attributes / calling various functions. I don't think this was exploited nearly enough by the curious youth.
These days if you show a kid that if you type
javascript:document.body.contentEditable=true
in the address bar you can change the contents of a web page just by clicking and typing they'll have a great time creating fake news items, etc.
Decker looks lovely. Can you speak more about how you create the wonderful HyperCard theme? Did you create your own graphical toolkit to match the Hypercard theme and draw everything yourself with that toolkit?
And is this available as a desktop too? or is it web only?
Everything in web-decker is drawn to a canvas using a custom software-rendered imgui-style UI toolkit. I considered this approach essential for maintaining fidelity across platforms and implementations, but it does come with notable accessibility and performance tradeoffs.
There is a native version of Decker implemented in C using SDL2. It's fairly easy to build from source for Linux[0], and I offer periodic Windows and MacOS builds on itch.io[1].
I think there’s a bit of survivorship bias in the tech industry. Many of us got into tech because we were able to explore computers with few limitations. But I’m not convinced it was mostly due to the tech of the 90s being more open.
We are the ones who did that kind of stuff, so we’re a filtered audience posting on HN about tinkerable software. We likely tinkered for a lot of reasons that didn’t have much to do what tech was like - we had unfettered access to tech in some form, for instance, or we were encouraged to do so by our parents or society or our peers.
Making our tech more accessible is a fine goal, but that’s likely not the biggest blocker for the next generation of technologists. Rather, I'm starting to think that, given recent advancements in UI, social media, etc. our belief of what makes a great engineer is totally off base for what we’ll actually need in the next decade.
I think it is reasonable to say the prevalence of smart phones with a better security model means that young people do not have the same skillset you possessed in general.
Add to this console gaming, and "view source" not working as well with the prevalence of optimised web frameworks, or the centralisation of compute services (you can't resedit Tinder or Snapchat and change what others experience); tinkering via tech is much much harder.
The creative types who want to have fun are off making innovative tiktok memes.
To help fix this, we need more open source apps with a "view source" button in the about tab taking you straight to GitHub with a "code now" button, to kill the app store in favour of sideloading apks from your local sneakernet, and an absolute buttload of Easter eggs.
Software is plenty tinkerable now, especially with so much of it being open source. Though applications rarely are, I don't know if that was all that different back then either for most people.
edit:
I think I misunderstood your last paragraph to mean we'll need to keep low level skills available so we don't lose the knowledge. I think you actually meant that we don't currently understand what the next generation will need to know to be effective which is a fair point, though have we ever known what skills the future requires?
/edit
There are still companies producing lower level engineering work, and the world still needs it. If academia and industry can't maintain the skills needed, bigger corporations will be able to run their own internal programs in collaboration with universities to produce the talent and those people would be paid handsomely.
With open source operating systems out there I also see it as being a recorded knowledge. Something that can be re-learned from, what will one day be referred to as, Ancient Codebases.
> Though applications rarely are, I don't know if that was all that different back then either for most people.
It was. Another commenter mentioned ResEdit and being able to tinker with classic Mac applications. Two things were universally true back then:
1. In a pre-internet world, the entire application had to be hackable in some fashion, even if the application's creator tried to make that difficult.
2. Most parts of an application boiled down to simple text files, simple binary layouts or compiled source code. Obfuscation, encryption or even compression all cost CPU cycles which were often too previous of a resource.
As an example, Civilization stored much of its data in *.txt files you could edit in notepad to change the strength of units, etc...
The author's piece refers to the ability to inspect web documents to see how markup works. This is an order of magnitude harder to do in mobile apps often providing the same functionality.
If you look at the state of drones an robotics right now, the 90's were nowhere near that.
So to any kid that is interested in technical things, there are currently 0 things holding you back: You all of the worlds information at your fingertips, can order any electronics part for cheap, can build cool things with tiny computers.
In the realm specifically of computers, I think kiddos today who do have the inclination to tinker in the ways we remember fondly doing so are going to have a lot harder time of it. I personally have spent time around Zoomers who were raised on iPads, and they love and are interested in learning more about technology, but at the same time are coming at it with what I perceive at least to be a far lower skill average than what I had at their age because all they know are iPads and smartphones, which are more and more locked down and untinkerable and who's muscle memory and general knowledge pool just isn't transferable to "real" computers, if you will. For example: a younger person once asked me where the file browser was on a Windows PC. I had to explain to them that's Explorer, but it didn't connect with them because it was configured on this machine to open their share drive on a university system which is just a drive letter, not a set of curated folders like "Documents," "Downloads," "Gallery," etc. And to be completely clear here: I am not calling this kid stupid, they weren't. They were untrained and ignorant, akin to someone who wants to learn to drive a sports car only ever being given access to the PlaySkool red and yellow pedal car.
Now that being said, there are still plenty of ways kiddos can tinker with software and electronics. 3D printers immediately come to mind. You (usually) can't just bang your sausage fingers on a capacitive screen and get good quality prints from go. There's calibration, for many there's assembly, for still others there's less computery-stuff but more things like chemistry if you're going the resin route, not to mention materials safety and of course, inevitable troubleshooting. It's not quite the same but IMO, it still promotes analytical, problem-solving, learning-to-research-and-self-teach type thinking which is critical to developing engineer brains.
That being said, if you do want your kid to go into software, if it isn't already obvious to you, take away their stupid phone and give them a proper computer. And if you don't want them necessarily going into software then just take away their stupid phone, at least sometimes, so the social media companies can't completely rot their brains out before they're even out of school.
> given recent advancements in UI
Also I have to push back on this specific point: I don't know of a single thing, except MAYBE iOS, that is consistently good with regard to UI. Windows is downright atrocious at this point, MacOS is fine (apart from Finder which is awful but it's always been awful), Android is a complete mess, every AAA game sports an interface that's even worse than the last, embedded systems are almost universally badly coded/organized and full to the brim with chinglish (is that term offensive?), web apps are slow as fuck with everything designed "mobile first" by which they mean they took out all the text and made everything stupid icons inside drawers so you end up sitting there translating some designer's idea of how hieroglyphs could work...
While I think your point is valid, IMO, entering in tech is so much easier. There's much more information available and you can tinker with hardware much more easier due to low prices. But it's very much easier to watch Youtube and play games on a playstation, so they do that.
I can't speak for everyone but I can tell you what my ice-breaking moment was that got me into software: I was playing the original Driver game for PC, and via reading on Gamespot forums, learned you could give yourself god-mode + access to any map if you went into the files and edited the map configuration, which was stored as plain text and easily editable. I never completed more than like... 3 missions of that game back then, I was just too dumb, but I was smart enough to edit a text file and it was the first time I altered software without using an interface or settings menu.
Of course being a dumb kid I assumed all software was like this and broke many files and executables opening them in Notepad and changing random characters, but nevertheless I credit this with starting me down the path of being a software developer. I don't think most people get into this stuff because it's easy or hard, we get into it because we want the computer to do something that it isn't currently doing, and we look for a way to make it do that. And of course there are still innumerable ways to go about it now, but they are paradoxically more complicated (not able to be performed in something like notepad, usually) and also less complicated (installing mods via Nexus, for example, is not technically challenging: the software does the vast majority of the work for you).
Could you give an example of a different avenue we could pursue? Your thesis seems plausible to me but I don't understand what we would do differently in light of it.
- make more kid-accessible low-code app development environments
- train hackable LLMs on a corpus targeted for younger audiences
- offer built in “escape codes” to the lower levels of gaming systems like the playdate
- offer social networking sites meant to be customized/hacked on (eg myspace)
/edit
These are ideas for how to bring tinker-ability to where kids are. But I don’t think I can say with confidence what is going to make a great explorative environment for the next generation. Bringing as much useful tech into the right places in kids’ lives, wherever they are and whatever background they have, is going to be the right start though.
Hmm, I'm confused. Those are all good ideas, but they all seem to be tinkerable?
Extrapolating it seems like what you're suggesting is making spaces where people can tinker socially rather than making tinkerability ubiquitous and trusting nerds like us to figure it out for themselves? Thus opening up the space to people we might not traditionally imagine as becoming software engineers?
The biggest incentive to lock down wasn't listed. It's economic.
If you can guide, or shoehorn, people into using your service, and it's 'good enough,' you can make a lot more money than if you're doing custom one-offs for everyone, or writing a bunch of potentially buggy code for different variations, or having your team troubleshoot integrations. An important point too is that, if one person sees another person using the app, and it's a standard unified experience, that helps its spread too.
"It is difficult to get a man to understand something when his salary depends upon his not understanding it." - Upton Sinclair. I personally would vote for not locking products down, but that's what we're up against.
I've long believed this to be the reason that component-oriented software never went anywhere back in the 90's. You could make _some_ money selling components. But you could make _tons_ of money selling a walled-off set of pre-integrated components as an office suite.
Agree with this. For me, being able to tweak Quake (when it came out) was massive. You could poke around in QuakeC, make a funny model / map etc. The fact that customisability extended to it's two sequels was even better.
To a lesser extent, even being able to modify pretty much any game mechanic via the pull-down Console was amazing too. A great entryway to programming for the young enthusiast!
Always was a wonderful advantage to owning a PC over a console. That, and the accompanying utilities you could combine with the game, to create new graphics, sounds etc.
Game modding is going to go away almost entirely soon. The vanguard here is Capcom. They have gotten a bit uncomfortable with modders who do things like put Chun Li and Cammy in bikinis, not to mention the possibility for cheat mods. Accordingly, they now consider modding to be the equivalent of piracy and have implemented mod-preventing DRM in their back catalog of PC games.
Other companies will soon follow. There's too much risk to a company's bottom line and reputation to allow or encourage modding. Mods compete with official DLC packs, and if someone streams with, say, a mod that puts a swastika on the main character or something, that harms the publisher's reputation.
I would say hang on to your old copies of Doom and Quake... but Doom and Quake are Microsoft products now, and Microsoft doubtless has ways to make the asset packs unavailable except to official ports which require a Microsoft account to play.
One of the reasons why I love open source software is that I can maintain personal patches. I'll upstream changes when it makes sense to do so, but mostly, I keep local branches.
Some of these tweaks are simple. Others are significant rewrites. But, the point is that I can approach computing on my own terms, and that's pretty neat.
I really appreciate how easy Nix makes this. It’s relatively straightforward to overlay a package in your configuration to add a patch - meaning I get to apply my own patches and also get updates from upstream - at least until my patch doesn’t apply cleanly.
That sounds interesting, do you have an example somewhere? I hadn't really considered this nix specific - does it make it easier than git normally allows (by keeping your patch in a branch?)
If you keep a patch in a branch, then you have to keep merging the upstream and your commit hashes become different from what everyone else sees, for example.
I'm currently playing with Pharo Smalltalk and everything is very accessible. I wonder why Smalltalk Environments did not catch on as operating systems, let alone just as languages, where everything can be tinkered with and modified on the fly.
Apple sounds like the kind of company that would successfully build a smalltalk device, yet they go the opposite way of locking down their devices hard.
Version control. Small talk is amazing, but dumping the binary to distribute is so scary. Did I unload my email client? Are my credentials in there? Gah. Scary.
The Pharo hackers write Pharo to enable them to make Pharo better. They are a shining manifestation of eating their own dog food.
Outcomes of this effort are powerful version control and package management. I don’t know, but it seems quite clear to me that Pharo folks start with base images, load their package dependencies on top of it, then hack away on their own code. Inevitably they create a new package with a list of dependencies for others to use.
What they don’t appear to be doing is “living” in their images. Rather they create application specific instances from source code.
Emacs users tend to “live” more within it than the SmallTalk/Pharo people do.
In the end they distribute images assembled much like a Docker image is today, made from a deterministic set of sources and then snapshot.
Yeah, I'm somewhat of a Pharo hacker and the workflow is pretty similar to any other software: Start with a base image, create a package, add code to the package, use git (via Iceberg) to save diffs for a particular package off for distribution. It's analogous to hacking on an operating system image in a container: keep your code and the system separate (via the "packages" abstraction in a Pharo image, or via the filesystem in an OCI container image) and you will be fine. The "Baseline" concept is a bit opaque (and weirdly named IMO, but a lot of the Pharo community is European, and especially French, so presumably it makes more sense in that context) but is a form of dependency management that works OK, though it would be nice to have a more Linux-distro type experience for installing packages.
I haven't messed around with smalltalk since squeak, around the dabble-db days. I was uncomfortable with the montachello (I think?) diff system. Maybe I'll have to give it another spin the next time I get a good long break.
I have experienced working with people who seemed far more interested in tinkering with the Smalltalk IDE than work on the mundane tasks needed to complete the project. They preferred tinkering to work ;-)
My Dearest TI-85 Calculator Games,
(I shall name a few by names)
In lines of code and pixels fair,
Within your realm, I find solace rare.
A love that's forged in binary strings,
A tapestry of malleable digital things.
Oh, how you captivate my heart,
With your C-programming art.
Your 8001 pixels dance upon my screen,
Creating worlds, both vivid & serene.
Through endless loops and if-else's rhyme,
We tinker in space, one byte at a time.
Together, we unravel mysteries profound,
In a realm where love, math & logic are bound.
Oh, Tetris, with your falling blocks of delight,
You bring joy that illuminates the night.
With each line cleared, my heartbeat soars,
Our Soviet connection strengthens forevermore.
And Snake, dear Snake, slithering through the maze,
A dance of patterns, a captivating craze.
As I guide you, pixel by pixel, with care,
Our bond grows deeper, beyond compare.
And let us not forget the classic Pong,
A symphony of paddles, back and forth, strong.
In this simple game, our tinkering takes flight,
A testament to the power of endless night.
Oh, TI-85 Calculator Games, you're my muse,
With you, my heart forever chooses.
In lines of C, our love shall persist,
Forever entwined in digital bliss.
To the best code goes the trophy,
Yours truly, BarefootJoey & my AI homie
Ah, I wrote some TI-85 games in HS.. DopeWars I had to recreate from scratch after I moved, and I implemented some classic arcade games. The interesting thing was that the simpler games were much more popular than the complex games, even if there was no slowdown on the complex game. I think my entire school shared Whack-a-Mole but my pac man and asteroids barely made it out of my calculus class.
But, as I recall, it was TI-BASIC, not C, as the programming language. Was that the AI's mistake?
Letting people into software as a soft thing, something shape-able, invites in the best human spirit! It's not just another appliance, not another gadget, it's something deeper & that you can geek with, imprint yourself & your behaviors or style on! I love it.
There is a notable e-collective dedicated to soft/changeable systems, the Malleable Systems collective, https://malleable.systems
I started out programming by hacking games to do what i wanted and sometimes tinkering with hex codes.
This article is very true, we have indeed lost the ability to do "naughty" things because everything has been made "safe" (illusion) but my gripe is even not that.
My gripe, the one I keep ranting about, is that the users themselves have become tamer.
They have believed that the way "Google" tells you to do things is the "right" way and you should always do only what the application suggests you to do.
Whereas I grew up in the early 2000s with a purely hacking and fun ideology for computing. Make bizarre graphics because something extra was deleted, talk to people who were into this and just have countless hours or fun tinkering.
I cut my teeth tweaking unit settings and then adding new units and buildings to Command & Conquer games with easy .ini tweaks.
I've long applauded the efforts of the JA2 1.13 devs and their drive to externalize basically every game parameter into xmls that can be edited rather than hardcoded inside the game's executable.
Since it hasn't been mentioned here yet, Emacs is deeply tinkerable. With Emacs, you are given an embarrassing amount of leeway to customize or even replace existing behavior to make it do what you want.
Playing with browser developer tools and always seeing obfuscated JavaScript makes me sad. I'm not a web developer, but I suspect the security gained is low enough to fall within the author's "unnecessary constraints."
On the other hand, there are projects like https://github.com/rxi/lite
Its scope and layout makes it extremely tinkerable.
While there is a slight difference that can add up (if text assets bandwith factor well into your traffic), I prefer to push out brotli compressed unminified js/css nowadays. Makes it easier to understand JS issues on prod as well.
You might be aware already but you can set up monitoring services which host your source maps (you can deploy versioned source maps to the service when your deploy your code), so you can get errors in the monitoring app which are pinned to the correct parts of your source code. It's a bit of legwork and complexity, but useful if you already use something like sentry. If you don't, what you're doing is likely a better solution.
my favorite thing about modern landscape of desktop apps is that… Electron apps are tinkerable! you go to the app's resources folder, extract an asar with one command, and then you can edit the node.js-side files. then, you can just change what the BrowserWindow instance is loading to resources you control, and you have end-to-end control over the entire application
Tinkerable software is alive in open source software of today.
I would recommend playing with simpler stuff and building it yourself from source and playing with adding things to it. It doesn't have to be useful things, try making all the menu text silly for the hell of it or whatever. It's still fun.
I remember playing with Deluxe Paint II on PC when I was a kid. Somehow it was not the same version that I saw people use on the Commodore Amiga. I also read somewhere in a magazine that there was Deluxe Paint Animation, but I did not have that on my computer.
So I set out to write a TSR (Terminate & Stay Resident) program that would pop up extra functionality in Deluxe Paint. Using some keyboard shortcuts I could add a rectangle to the screen, and select a grid of images. The separate images would then animate on another part of the screen. Needless to say that the integration with the rest of Deluxe Paint was somewhat limited, but it was good enough for me.
I'm fond of software I like to call "pervasively programmable", Emacs and the various Smalltalk environments being ur-examples. Every bit of them can be examined, inspected at run time, and changed in the running system as you work. It's the next step beyond open source. (If you compiled Emacs yourself, Emacs will remember where its C source lives and will happily bring that up if you M-. on one of its C primitives.) And I think we should celebrate and encourage software like that.
A love letter to tinkerable hardware as well...
If you think about how many people entered electronics via "the Arduinos of this world". How many kids learned that you can actually build physical "stuff" that is nice & blinks. How many artists created "stuff" due to tinkerable hardware.
Frontpage was anything but discoverable. Ditto with the MS Office suite.
I found Unix' (and by extension, GNU) philosophy much better to discover how did computers work. The Linux Gazzete taught you about HTML code, editors, system administration, networking without tons of hideous GUI's and Microsoft corpojargon to hide anything behind a lexicon wall having nothing to do with actual IT.
I feel like the world of software can probably be divided into the same moral classes as D&D, with M$ as Chaotic Evil (sorry M$!), Google as Chaotic Good (or would it be Lawful Evil? Probably lawful evil) and GNU as Lawful Good. All have their merits, flaws and compromises.
But, tinkering neutral is a great addition to that framework.
I've learned pixel art by messing with Sim City 2000 files!
I found out that I could just change the sprites, so I started modding the game, and learning how tiles and palette animation works.
Now, on every game I make or work on, I try to keep atlas and files exposed and unencrypted, so people can play around with it.
I remember writing a tool to “tweak” Google Chrome when it was launched back in 2008(?) to mass edit the resources inside DLL files to change icons within the browser chrome. There was no theme support back then, and it was cool.
Long before that, I’d spend hours editing random INI files in windows games in hopes of finding something.
There is almost certainly more tinker-able software out there today than ever before - and the accessibility has never been higher. Not everything is accessible, but it never used to be either.
This is totally off topic, but this made me think of it for some reason... Remember when computers had turbo buttons? What a fun concept. I wish my MacBook Pro had a physical button on there to knock it into ass-kicking mode.
I think the world would be a more perfect place if everything had turbo buttons. Internet too slow? Hit the turbo link button to 10x your download speeds for 30 seconds. ChatGPT prompt sucks and just isn’t getting it? Turbo that sucker and watch it prompt you instead. Food is taking too long at the restaurant? That’s right, turbo. JVM takes too long to spin up? Probably no turbo there, that’s never gonna get solved.
I believe the intention of those was that it was actually a "slow down" button just with enhanced marketing. But when you played an old game which was designed with no frame limit cap, you could slow the game down to a playable speed with the button.
Unfortunately, I had no such button on the family computer, so many games were unplayable because of our speedy 486SX33
This really resonates. The neat think about software that doesn't actively resist tinkering is you can make it do things nobody expected or thought possible.
Things got a lot more complex these days. When I was a kid I was able to hold in my mind how DOS works, how x86 works and was able to learn a bit of C and assembler to do about anything. Hack software, build my own, have fun.
Doing small games was pretty easy if you knew some graphic modes and had some undocumented source codes for drivers for various 2D graphics cards. Trying now to learn modern DirectX, Vulkan, shaders and graphics stacks is more complex.
Nobody can now hold in their heads all the important details of how operating systems work, how networks work, how graphics woks, how web apps work, how mobile apps work, how backend works, how desktop apps work, how ML and AI works.
You have to specialize in something. Get an Arduino and learn how to flip a led. Right click a popular website, paste the source code in Notepad and try to modify it.
It's not less fun tinkering, but it's going to be specialized fun if you ever want to learn something and get good at it.
As an X-Gen, I remember as a kid the first computer I ever saw was a ZX-80!
You could do 'stuff' with those early computers, and Basic was great and all, but the early days of the Web really opened up exploration for me.
As a solo developer it suddenly provided opportunities to work commercially without having to have a computer science background and be a very serious C++ developer.
These days I see my kids exploring programming through Minecraft Java Edition. They also create and make 3D printed toys and objects in software I could never have dreamed of. They also create and edit their own YouTube movies, again things I never dreamed of being able to do.
So whilst early tech opened up possibilities to explore creativity, the options were limited in many ways.
Now the entire world of creative exploration no longer has gatekeepers.
The explosion of the App Store genuinely opened up opportunities through tools like xCode and globally distribution that individuals never had before.
Similarly, you can be a movie maker, photographer, App Developer, 3D artist, and producer of 3D Printed Widgets, and you don't need to ask anyone's permission.
It's not a perfect world, but it's still good for creators.
Just that maybe it doesn't all seem as exotic as it once did in the 80s and 90s!
Edit: One thing missing today is the easy ability to play with commercial software without a license. Back in the day you just needed the file and a serial number.
Many schools provide licenses to Adobe software and more, so that's good.
And I suppose lots of software has a free Cloud version, or a limited trial. So its not all bad these days.
But I can recall preparing for interviews by finding a copy of some software and then playing with it on my own computer. That's riskier these days as you may end up turning your computer into a Crypto Mining device LOL
In case anyone's curious: I didn't recognize the .org domain but I felt lucky, punk, and followed it. civboot.org redirected me to https://github.com/civboot/civboot which I totally would feel comfortable visiting :)
Thinking about tinkerable software, this is one of the promises that crypto offers in my opinion, as it decouples the front end from the back end in a very clean way.
This gives the ability for anyone to add a different front end to any pure crypto back end.
The project that currently occupies most of my time, Decker[0], is a rapid development platform that can produce standalone single-file HTML "applications". The detail I'm most proud of is that every such app still contains the entire suite of editing tools: anything made with Decker is ready to be customized and extended by end-users.
[0]https://beyondloom.com/decker/