https://akkartik.name/freewheeling/ contact Kartik Agaram Freewheeling Apps Using computers more freely and safely Transcript for this video (18 minutes). Click on images for full-size versions. 2 kids at a How can we use computers more freely and safely? computer These are my suggestions. * Prefer software with thousands rather than millions of users, * that doesn't change often, * that seems to get forked a lot, * that can be modified without specialized the punchline tools, and, ideally Prefer software: * that you can make small changes to. Yourself. In a single afternoon. * with thousands rather than You don't have to do all this. Their benefits are millions of additive, but acting on even one of these users suggestions is better than nothing. The * that seldom suggestions are arranged roughly in order of requires increasing effort and skill required. Trying to updates follow one suggestion will pave the way for the * that spawns others, should you choose later to continue down lots of forks this path. Software without constant updates is * that is easy easier for forks to keep up with. Forks are signs to modify of easily-modified software, and testimonials from * that you can nearby programmers can be promising signs that, modify hey, maybe making a change yourself won't be very hard. The most important step is the first one. Humanity didn't get good at building houses by building the same house a million times. We built lots of different houses and learned from each other's failures. Gravitating away from monopolies is a way everyone can help improve software, regardless of our abilities or needs. That's the whole argument in a nutshell. In the rest of this talk I want to show how to apply outline these principles in small ways in your day-to-day decision-making, making the world a little better * Problems in the process. I'll show this by drawing on my * Suggestions - own journey over the past year for examples. I'll Examples first back up to some problems I was responding to at the start, then show how I responded fairly directly to these problems and ended up with the above suggestions. So, problems. The first problem is: software is expensive. We like to think the incremental cost of software is 0. You build it once, lots of expensive people use it. The additional cost for any new user is negligible. This is just not borne out by multiple decades of experience. Apps and services require constant maintenance. And they grow complex over time, so their costs grow over time. untrustworthy Also, software today is just not very trustworthy. Data breaches impact millions of people every year incompetence . some data on data breaches If you manage data for others it's extremely difficult to secure. Efforts to secure it add to your costs. Beyond incompetence, services engage in rampant misbehavior. This is a headline from a couple of malice years ago. Just about every single major phone app headline: how was snooping on your clipboard. And this was going popular apps can on for years before these researchers noticed. read your phone& apos;s clipboard Since they noticed, Apple plugged this loophole. without permission But what else are apps up to, and what current misbehavior will we find out about this year or the next? Ok, so software providers fail to keep us secure slow and also do shady stuff. What do we get for this? headline: the Are they at least effective at providing the website obesity service they advertise? Here is a talk about how crisis by Maciej inefficient just about every single mainstream Ceglowski website is. Our computers pay a tax on every page we read. slow But maybe that's just websites that have to go out screenshot: over the internet. What about native apps? Here is computer latency a study showing that a computer from 2015 is 2-5 by Dan Luu times slower than an Apple 2e from 1986 just at reading a keystroke and displaying it on screen. all is not well with computers * they grow increasingly complex and expensive These are the fairly fundamental problems I see. * they grow They're not new or insightful, lots of people have untrustworthy said all this. What do we do about it? as they grow complex * they slow down as they grow complex My first resolution is just to bring less software into my life. It is still early days, we don't depend less on really understand computers yet. It's important to software be clear-eyed about the risks they bring with them, and to think about computers primarily as a liability rather than an asset. But, unfortunately, I came to this realization too late. Computers have already eaten the world. Today I need to use computers to conduct commerce, interact with my government, and to talk to my family and friends. What to do about this? One coping mechanism is an idea from almost 20 years ago called situated software. This is depend on services software with a few users who know each other and with dozens of share a social context or situation. The idea is users analogous to local government: services with few Situated Software stakeholders are often better able to meet the by Clay Shirky needs of their stakeholders, particularly when everyone knows everyone and there's a certain level of social accountability. This isn't always possible. Sometimes we have to use software with millions of users. But I think it helps to rely on small-scale tools as much as possible, and to question tools for large crowds of people at every opportunity. The idea of situated software has been seeing a renaissance recently, and there is growing awareness of the value it brings. However, I think we don't yet appreciate the implications of this idea at all levels of activity around computers. As a programmer, I've tried multiple times in the past decade to create services just for myself and depend on the a few friends. Each of them has fallen away after right tools a year or two. And a big reason for that was the Dependency by burden of keeping up with updates for all the Randall Munroe tools they depend on. It took me a while to realize the underlying issue: I was using tools that themselves are catering to non-situated software. They assume that it's worth someone's time to keep up with updates every month or two. But situated software doesn't have those kinds of surpluses. It requires programs to just work once built, with little maintenance. Last year I switched to something new. This is the Lua programming language. It's implemented in just screenshot: 12k LoC, it's extremely easy to build from source lua.org and it's quite fast. It's not as popular as Javascript or Python. As a result, it doesn't tend to get used in products of conquest that try to be all things to all people. Another thing I love about it: there's a widespread culture of using old versions. Lua is often embedded in games. Games are a hits-driven screenshot: business like movies. Hits are short-lived. As a lua.org versions result, it's less common for released games to page receive updates. Old games running old versions of Lua are common. I use version 5.1 which came out in 2006. This is the LOVE game engine. It's based on Lua, it's easy to build, it changes infrequently, and it's surprisingly versatile while providing a tiny screenshot: set of APIs. love2d.org LOVE allows me to send a zip file with inspectable source code to my friends. All they need to run it is a single, reputable 5MB binary. Now, you don't have to use Lua and LOVE. I have friends who use Python or Rails or Javascript and are able to manage the overheads of upgrading. They do so by being extremely selective about what libraries they depend on. This can work, but I think it's not ideal. These languages foster a alternatives culture of depending on lots of libraries, and those libraries put out frequent updates. If you use these languages, you have to spend some energy espousing your values to collaborators and users, so they are parsimonious with libraries and depend on the right libraries. It requires constant discipline. With Lua and LOVE the community shares these values and this discipline. What can I do with this platform? A language that doesn't try to be all things to all people and tends to leave copies of itself embedded in older games is fertile soil for forking. Every new game is an opportunity to rethink old ideas, to shed some complexity. This culture has had an effect on me even though I don't build games. I build little apps for my own life, and when I need something forks/examples new, some of the time I now copy an existing a map of my forks program and permit the two copies to diverge. This picture shows a family tree of sorts for the apps I built over the past year. I organized the tree roughly by complexity from left to right. And the lines trace heredity from top to bottom. Look for this image over the rest of the talk as I focus on individual apps to illustrate values I care about and concerns I can jettison entirely. The app that started it all was a plain-text editor that lets me draw little line drawings in the middle of text. I find it very useful. Definitely talk to me if it or any of my other programs sounds interesting. I want to support anyone interested in using it or hacking on it. screenshot: When I show it to other programmers, often the editing a file first question I get is about what the file format with a drawing for drawings is, and how to get other editors to using lines.love support that file format. But does it make sense lines.love on the to so privilege interoperability? You have a tool map of forks to draw pictures as you write. There are situations where it can be useful, even if nobody else can read it. Trying to stay close to other people and tools makes things more complex and less supple. A tiny, open-source tool that is easy to run and works with a simple file format allows me (and you) to focus on the writing experience without precluding others from taking on additional concerns. This is an example of keeping requirements values negotiable. We programmers have a tendency to start with a germ of a neat idea and, in a * no microsecond, often so fast we're not even requirements conscious of the transition, pile on a bunch of requirements to it, just because other things like it satisfy those requirements. Requirements often stem from unconscious acculturation, so it's worth coming up with strategies to question assumptions. One hack I've found useful is to stop trying to seem values "professional". * no I remember when I started out programming, I requirements wanted my programs to look "professional," like * wabi-sabi the programs other "real" programmers made. This desire is the devil. It's taken me 20 years as a professional programmer to realize what matters is what it does, for your specific situation. In practice, seeming professional is often a way to end up with a pile of stuff you don't need. All it does is slow you down. One particularly egregious requirement we unthinkingly take on is backwards compatibility. Backwards compatibility is of huge strategic values importance if you're Intel and trying to sell a lot of chips. But it's also easy to end up * no depending on a million lines of code just to avoid requirements writing a thousand. * wabi-sabi * no Deciding when and how an organization should break compatibility compatibility is a thorny problem. But fortunately we're not concerned with organizations here. When we're just individuals creating for other individuals, asking each other to make small changes just isn't that big a deal. Here's another of my forks. This one's not an editor, just a viewer. Its only reason for Your browser does existence is to use all available width to display not support the text in a readable way. That's it. It's a very video tag. simple thing to build, just 100 lines once you broadsheet.love on have an editor, and yet it's something I've never the map of forks seen other programs do. I'm sick of overly wide lines of text and oceans of wasted whitespace. Now I can have dense but readable text on screen. We programmers have long had an ideal of building programs that do one thing and do it well. But we values have a really hard time keeping such programs from accreting features and complexity over time. I * no think one essential requirement for programs that requirements do a single thing well is to not tie yourself too * wabi-sabi tightly with what other people want. It's easy for * no two people to want slightly different things, and compatibility a program that tries to cover both is no longer * avoid doing one thing. Rinse and repeat, and you end up disagreements with programs with hundreds of commandline flags by forking or preferences. Or worse, someone deciding for everyone, whose preferred settings should get taken out. Just say no. Build simple things, and if others want to do something slightly different, well we already have a solution: fork! Here's how I draw pictures in my text editor. One Your browser does thing to notice is that there are no menus, not support the dialogs or conventional UI elements. I've been video tag. trying to mimic the feel of paper and pen. I want lines.love on the to be able to draw at a moment's notice, but I map of forks don't want any reminders that I could draw. I don't want any widgets constantly on screen just for the moment when I might start drawing. values Now, I likely don't know what I'm doing. I've only * no been drawing pixels for a year now, I'm not a UX requirements designer. But I notice that menus grow over time, * wabi-sabi and the trend doesn't often come with great UX. * no compatibility Our conventional UI idioms were created in the * avoid context of organizations. Menus and toolbars are disagreements at least partly scalable ways to pack lots of by forking features in, to be all things to all people. * limit features Situated software doesn't need menus and toolbars. per fork Let's set aside app features and look at how we meme: setup my dev might make changes to these apps. It's environment distressingly common to need complicated tools to modify an app. We'd like to avoid requiring any such setup. To modify any of my LOVE apps you need just a second LOVE app. Run the same 5MB LOVE binary, Your browser does just on a different 5k lines of Lua, mostly the not support the same as my editor, just tweaked in a few ways, and video tag. now you can make changes to any of my apps as they driver.love on the run, without having to restart them. map of forks Teaching a new LOVE app to listen for commands from the editor takes 250 LoC. values * no requirements It's not enough that the sources are available. * wabi-sabi "Open" is a spectrum, and most open software today * no is too hard to build, so we leave the build compatibility process to a priest class, and the priests * avoid accumulate power over time. What if there was zero disagreements accidental complexity to modifying a app, and all by forking you had to focus on was understanding how it * limit features worked? per fork * reward curiosity values * no My editing environment doesn't have requirements find-and-replace yet. I haven't felt much need for * wabi-sabi it, which is surprising because I used to use it * no all the time. I recently realized why: small compatibility programs just tend to need less bulk replacement. * avoid disagreements There are many features like this that my by forking environment lacks at the moment. Some of them I'll * limit features get to, some I may never add. per fork * reward There will absolutely be programs that are curiosity difficult to create this way, but that's ok. * just small apps (for now) I've surprised myself a couple of times when a Your browser does seemingly complex program turns out to have a not support the simple core. This is a simple DOM model I wrote in video tag. 50 lines of code. It doesn't support 99.9% of CSS. luaML.love on the It's just a simple way to specify grid layouts. map of forks Throw in an infinite 2D surface with support for panning and zooming, and it requires 350 LoC. Your browser does Once I built it, it was easy to include in my not support the editing app. Here you can see my programming video tag. environment with the ability to view multiple driver.love on the definitions at once. This is something I've wanted map of forks for a long time, to view not just arbitrary files but arbitrary definitions side by side. When I first started working on this environment I Your browser does had a hazy desire for multiple views. However, I not support the found myself gravitating towards a style where I video tag. positioned definitions once and never moved them driver.love on the thereafter. It was valuable to give all the code map of forks for my apps a place, so I always have a sense of space when I make changes to it. The computer contains my memory palace. I'm a little surprised at this point, by how far I've been able to take what I initially considered just a coping strategy. My initial plan had been to create clones of apps for myself and take out Your browser does lots of features. It felt like eating my not support the vegetables. I didn't expect to find myself video tag. wondering what a web browser for memory palaces might look like. Small apps leave more headroom for design exploration. What new types of experience might you create if you undertook such a journey? Focus on keeping software easy to try out, easy to modify and easy to share. avoid crowds Prefer software: The final message I want to leave you with is: * with thousands avoid crowds. We can each have huge quantities of rather than freedom inside our own devices on this crowded millions of planet. Our freedoms only run into frictions when users we leave our devices. The less often we need to do * that seldom that, the happier we'll be. It doesn't solve requires everything, but it helps. A lot. updates * that spawns There isn't a whole lot of software out there that lots of forks follows these principles. I expect I have a lot * that is easy more to learn on this journey. If you're to modify interested in joining me, I'd love to help ease * that you can your way along however you need. My freewheeling modify apps are freely available and designed for the long term, and I'm always looking for ways to make https://git.sr.ht/ them useful to others. ~akkartik/ driver.love Resources Mirrors for the video: PeerTube, YouTube Moar demo: Hands-on with Freewheeling Apps (mirror, mirror) Links to all the apps/forks I showed above. Click on any node in this image to see its repo and Readme. (Unfortunately HTML doesn't support resizing such an image.) clickable map of my forks (image map generated using image-map.net) --------------------------------------------------------------------- 2023-05-22