commit 242efc8fb9e2f16148b2f10ba8769c7f47b95b09 · bmann.ca/bmannconsulting.com

.gitignore

···

       7
       7
        
       # figure out which files should be checked in

     

       8
       8
        
       .obsidian/workspace.json

     

       9
       9
        
       .obsidian/workspace-mobile.json

     

       10
       10
       +
       .obsidian/graph.json

     

       10
       11
        
       tiddlywiki/output/*

     

       11
       12
        
       .DS_Store

     

       12
       13
        
       _archive

+10

_journals/2025-06-13_1222.md

···

       1
       1
       +
       ---

     

       2
       2
       +
       title: "202506131222"

     

       3
       3
       +
       date: 2025-06-13, 12:22:10 +02:00

     

       4
       4
       +
       section: journal

     

       5
       5
       +
       link: https://www.youtube.com/watch?v=0ptXBlsZwC0

     

       6
       6
       +
       tags:

     

       7
       7
       +
         - video

     

       8
       8
       +
         - llm

     

       9
       9
       +
       ---

     

       10
       10
       +
       As part of walking the startup showcase at Web Summit Vancouver, I saw [Forestwalk Labs](https://forestwalk.ai/) [demo'ing Timberline](https://www.youtube.com/watch?v=0ptXBlsZwC0), their agentic Mac app - building task management in an agent-first way.

+17

_notes/Forestwalk Labs.md

···

       1
       1
       +
       ---

     

       2
       2
       +
       link: https://forestwalk.ai

     

       3
       3
       +
       tags:

     

       4
       4
       +
         - AI

     

       5
       5
       +
         - llm

     

       6
       6
       +
         - organization

     

       7
       7
       +
         - startup

     

       8
       8
       +
         - Vancouver

     

       9
       9
       +
       ---

     

       10
       10
       +
       Building products that help teams do their best work. Forestwalk is building delightful LLM-powered tools that solve teams' problems.

     

       11
       11
       +
       

     

       12
       12
       +
       [[Vancouver]] based startup founded by Allen Pike and Jenn Cooper.

     

       13
       13
       +
       

     

       14
       14
       +
       They help run the [[Infer]] meetup in Vancouver.

     

       15
       15
       +
       ## Timberline

     

       16
       16
       +
       

     

       17
       17
       +
       <iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/0ptXBlsZwC0?si=pwKfEjKroSBpWhRu" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>

+15

_notes/Infer.md

···

       1
       1
       +
       ---

     

       2
       2
       +
       link: https://infervan.com/

     

       3
       3
       +
       tags:

     

       4
       4
       +
         - organization

     

       5
       5
       +
         - meetup

     

       6
       6
       +
         - Vancouver

     

       7
       7
       +
         - community

     

       8
       8
       +
         - llm

     

       9
       9
       +
         - developer

     

       10
       10
       +
       youtube: https://www.youtube.com/@InferVancouver

     

       11
       11
       +
       luma: https://lu.ma/infer

     

       12
       12
       +
       ---

     

       13
       13
       +
       Infer is Vancouver's meetup for tactics, techniques, and lessons learned in LLM and AI engineering.

     

       14
       14
       +
       

     

       15
       15
       +
       Brought to you by Latent Space, Northeastern U, and [[Forestwalk Labs]]

+135

_notes/Malleable Software Essay.md

···

       1
       1
       +
       ---

     

       2
       2
       +
       link: https://www.inkandswitch.com/essay/malleable-software/

     

       3
       3
       +
       author:

     

       4
       4
       +
         - Ink & Switch

     

       5
       5
       +
       published: 2025-06-10

     

       6
       6
       +
       tags:

     

       7
       7
       +
         - article

     

       8
       8
       +
         - malleablesoftware

     

       9
       9
       +
         - llm

     

       10
       10
       +
         - enduserprogramming

     

       11
       11
       +
       ---

     

       12
       12
       +
       By [[Ink & Switch]], subtitled _Restoring user agency in a world of locked-down apps_

     

       13
       13
       +
       

     

       14
       14
       +
       > tools that users can reshape with minimal friction to suit their unique needs. Modification becomes routine, not exceptional. Adaptation happens at the point of use, not through engineering teams at distant corporations.

     

       15
       15
       +
       

     

       16
       16
       +
       Citation:

     

       17
       17
       +
       > [[Geoffrey Litt]], Josh Horowitz, Peter van Hardenberg, and Todd Matthews. 2025. **Malleable Software: Restoring User Agency in a World of Locked-Down Apps**. Ink & Switch. https://www.inkandswitch.com/essay/malleable-software/.

     

       18
       18
       +
       

     

       19
       19
       +
       ## Outline

     

       20
       20
       +
       ### [Motivation](https://www.inkandswitch.com/essay/malleable-software/#motivation)

     

       21
       21
       +
       

     

       22
       22
       +
       #### [We want to adapt our environments](https://www.inkandswitch.com/essay/malleable-software/#we-want-to-adapt-our-environments)

     

       23
       23
       +
       #### [Mass-produced software is too rigid](https://www.inkandswitch.com/essay/malleable-software/#mass-produced-software-is-too-rigid)

     

       24
       24
       +
       

     

       25
       25
       +
       > Before, new ideas took minutes to try; now they could take hours of wrangling configurations, if they were possible at all. **Computerizing work led to a loss of agency.**

     

       26
       26
       +
       

     

       27
       27
       +
       > It may seem inevitable that our specific requirements aren’t served by our software—but that’s only because we’ve taken for granted that software is controlled by centralized development teams. What if we were to shift more control into the hands of users who know their own needs?

     

       28
       28
       +
       

     

       29
       29
       +
       > App stores are designed for companies distributing software to consumers, not amateurs sharing tools with their friends. This is a system of industrial mass production, not small-scale craft.

     

       30
       30
       +
       

     

       31
       31
       +
       This is interesting, but it also leads me to think about what the civilizational substrate of software needs to be, in order to serve the needs of the many, and how that is in opposition to "small scale craft". The equivalent of aqueducts and sewers. Sync engines, accounts, user owned data, and encryption.

     

       32
       32
       +
       #### [Our goal: malleable software](https://www.inkandswitch.com/essay/malleable-software/#our-goal-malleable-software)

     

       33
       33
       +
       

     

       34
       34
       +
       >  Malleability isn’t a narrow technical problem.

     

       35
       35
       +
       

     

       36
       36
       +
       Great phrase.

     

       37
       37
       +
       #### [Existing approaches](https://www.inkandswitch.com/essay/malleable-software/#existing-approaches)

     

       38
       38
       +
       

     

       39
       39
       +
       Plugins

     

       40
       40
       +
       

     

       41
       41
       +
       > <mark>Going from installing plugins to _making_ one is a chasm that’s hard to cross.</mark> And each app has its own distinct plugin system, making it typically impossible to share plugins across different apps.

     

       42
       42
       +
       

     

       43
       43
       +
       [[Obsidian]] is mentioned here.

     

       44
       44
       +
       

     

       45
       45
       +
       Quote the [[Open Source]] section in full:

     

       46
       46
       +
       

     

       47
       47
       +
       > The open source software movement promotes the idea of distributing source code so that users of software can own their software, contribute back to it, and if needed create their own version that better meets their own needs. <mark>This has been a positive force for the world, and represents an important ingredient for malleability.</mark>

     

       48
       48
       +
       > 

     

       49
       49
       +
       > But having access to edit the code doesn’t mean minimal friction. **Modifying a serious open source codebase usually requires significant expertise and effort**. This applies even for making a tiny change, like changing the color of a button . Even for a skilled programmer, setting up a development environment and getting acquainted with a codebase represents enough of a hurdle that it’s not casually pursued in the moment.

     

       50
       50
       +
       

     

       51
       51
       +
       I am less positive on open source, or rather the mere existence of a certain kind of license. [[Proto Apps]], with user owned data means that as a user, I can move between apps or switch between clients regardless of their license.

     

       52
       52
       +
       

     

       53
       53
       +
       AI-assisted coding

     

       54
       54
       +
       

     

       55
       55
       +
       > Will AI tools automatically make malleable software a reality?

     

       56
       56
       +
       

     

       57
       57
       +
       > There is now momentum towards a world where anyone can generate a web application from a chat, without needing any programming experience.

     

       58
       58
       +
       

     

       59
       59
       +
       > How can users tweak the _existing_ tools they’ve installed, rather than just making new siloed applications? How can AI-generated tools compose with one another to build up larger workflows over shared data? And how can we let users take more direct, precise control over tweaking their software, without needing to resort to AI coding for even the tiniest change? None of these questions are addressed by products that generate a cloud-hosted application from a prompt.

     

       60
       60
       +
       > 

     

       61
       61
       +
       > **Bringing AI coding tools into today’s software ecosystem is like bringing a talented sous chef to a food court.** If you’re used purchasing meals from a menu, a skilled chef can’t do much to help you. Similarly, if you’re using closed-source software from an app store, an AI coding assistant can’t do very much to help you as a user. <mark>To fully take advantage of the capabilities of AI, we need to move past the food court to something more like a kitchen—a site of open-ended creation</mark>.

     

       62
       62
       +
       

     

       63
       63
       +
       > This essay isn’t an exhaustive survey of all work on malleability. For a longer reading list, we recommend the [Malleable Systems Collective catalog](https://malleable.systems/catalog/).

     

       64
       64
       +
       

     

       65
       65
       +
       Bookmarked! [[Malleable Systems Collective]]

     

       66
       66
       +
       ### [A gentle slope from user to creator](https://www.inkandswitch.com/essay/malleable-software/#a-gentle-slope-from-user-to-creator)

     

       67
       67
       +
       

     

       68
       68
       +
       ### [Tools, not apps](https://www.inkandswitch.com/essay/malleable-software/#tools-not-apps)

     

       69
       69
       +
       

     

       70
       70
       +
       > So far we’ve focused on the rigidity of individual applications. But there’s another reason that it’s hard to adapt software to meet our needs: the very idea of “applications”. Because we’re so accustomed to this idea, it can be hard to see the nature of the problem—so let’s consider an analogy from the kitchen.

     

       71
       71
       +
       

     

       72
       72
       +
       #### [Apps are avocado slicers](https://www.inkandswitch.com/essay/malleable-software/#apps-are-avocado-slicers)

     

       73
       73
       +
       

     

       74
       74
       +
       > …because the avocado slicer is narrowly focused on one task, it’s useless at anything else. If you used a specialized gadget for every single task, you’d end up with a mountain of plastic.

     

       75
       75
       +
       

     

       76
       76
       +
       > How does this analogy apply to software? **Many applications are avocado slicers.** They’re a bundle of functionality targeted at some specific use case: planning a trip, tracking workouts, organizing recipes. Because an app needs to handle many tasks associated with a use case, it sometimes doesn’t handle any of them particularly well. You may have come across situations where an app is missing some functionality that’s important to you, while simultaneously including extra bits you don’t need.

     

       77
       77
       +
       > 

     

       78
       78
       +
       > On top of that, solving a larger task using multiple applications often requires manual coordination. We can put windows next to each other and copy-paste data, but not much more. If we want more knife-like software tools, we’ll need better ways for smaller software tools to work together.

     

       79
       79
       +
       

     

       80
       80
       +
       > **How might we reorient software around more general, composable tools**—that feels more like a knife and less like an avocado slicer? There are two sub-problems to address: sharing data between tools, and combining tools within the user interface.

     

       81
       81
       +
       

     

       82
       82
       +
       Aside:

     

       83
       83
       +
       > A key inspiration in this area is Michel Beaudouin-Lafon’s work on [Instrumental Interaction](https://dl.acm.org/doi/10.1145/332040.332473) described in his talk [A World Without Apps](https://www.youtube.com/watch?v=ntaudUum06E).

     

       84
       84
       +
       #### [Sharing data between tools](https://www.inkandswitch.com/essay/malleable-software/#sharing-data-between-tools)

     

       85
       85
       +
       

     

       86
       86
       +
       #### [Composing the user interface](https://www.inkandswitch.com/essay/malleable-software/#composing-the-user-interface)

     

       87
       87
       +
       

     

       88
       88
       +
       ### [Communal creation](https://www.inkandswitch.com/essay/malleable-software/#communal-creation)

     

       89
       89
       +
       

     

       90
       90
       +
       This whole section is great

     

       91
       91
       +
       

     

       92
       92
       +
       > And there’s an even more fundamental reason to think of malleability through a communal lens: we use computers together! A product team needs a single system for tracking projects. A department at a hospital needs a single system for patient intake forms. These communities are certainly not well-served by one-size-fits-all applications they have no control over. But the solution can’t be every-user-for-themselves either. We should help communities build and maintain _shared_ solutions to their problems.

     

       93
       93
       +
       > 

     

       94
       94
       +
       > See [The inequities of our remote gathering tools](https://medium.com/@paulate/the-inequities-of-our-remote-gathering-tools-185f0446b0f6) for more on how one-size-fits-all apps like Zoom can disrupt democratic social dynamics.

     

       95
       95
       +
       > 

     

       96
       96
       +
       > **With the right infrastructure, we can work together to craft our software.** People with similar needs around the world can exchange work and build collaboratively, as we have seen happen in free-software communities. And local communities, from companies to families to civic organizations, can build and maintain software suited to their local needs. When local needs get higher up the “slope” and call for special levels of skill and enthusiasm, you don’t need everyone in a community to attain these levels – just enough people to play that role and get the job done.

     

       97
       97
       +
       

     

       98
       98
       +
       > **Building software for “local” contexts is sometimes _easier_ than building software for world-wide use.** You don’t need to build airtight, industrial-grade software if you are in direct contact with your users and can be responsive to the situations they run into. You don’t need to anticipate everyone’s needs in your design, just your community’s.

     

       99
       99
       +
       

     

       100
       100
       +
       > On an even more intimate level, Robin Sloan memorably described how an app built for his family could be a [“home-cooked meal”](https://www.robinsloan.com/notes/home-cooked-app/).

     

       101
       101
       +
       

     

       102
       102
       +
       See also [[Home-Cooked Software and Barefoot Developers]]

     

       103
       103
       +
       

     

       104
       104
       +
       ### [Ink & Switch prototypes](https://www.inkandswitch.com/essay/malleable-software/#ink-switch-prototypes)

     

       105
       105
       +
       

     

       106
       106
       +
       > **we have been prototyping an infrastructure stack for building, running, and sharing software that prioritizes malleability.** Our approach builds on another area of our research: local-first software [[Local-first Software]], which is a philosophy that prioritizes giving users ownership and control over their data, while maintaining the ability to collaborate with others. As part of that work, we developed a collaboration library called [[Automerge]], which persists and synchronizes JSON documents among users.

     

       107
       107
       +
       

     

       108
       108
       +
       #### [[Patchwork]]

     

       109
       109
       +
       

     

       110
       110
       +
       > Another thing we’ve found while customizing Patchwork is that **AI is a useful complement to a malleable environment.** We argued earlier that AI-assisted coding alone does not guarantee malleability. But _when combined with a malleable environment_, AI-assisted development can make it much faster to edit your tools.

     

       111
       111
       +
       > 

     

       112
       112
       +
       > We’ve used AI assistance to rapidly build many tools in Patchwork. The Section Word Counter tool mentioned above was coded with AI assistance in just a few minutes—in the middle of a writing session, without needing to set aside dedicated time.

     

       113
       113
       +
       > 

     

       114
       114
       +
       > A malleable environment can also provide platform capabilities that make AI-generated software more useful. For example: we have an interface for making small software tools from an AI chat. While this UI superficially resembles existing products like [Claude Artifacts](https://support.anthropic.com/en/articles/9487310-what-are-artifacts-and-how-do-i-use-them), the generated tools gain capabilities from existing inside of Patchwork. They automatically support persistence and multi-user collaboration, and can compose with existing tools for editing existing data.

     

       115
       115
       +
       

     

       116
       116
       +
       > A related challenge is managing expectations of quality. Most of the tools we’ve built aren’t anywhere close to the polish level of commercial products; they’re scrappy personal tools. When someone shares a tool, how can they communicate its level of quality? There’s a difference between sharing a tool “as-is” and committing to ongoing maintenance.

     

       117
       117
       +
       

     

       118
       118
       +
       

     

       119
       119
       +
       

     

       120
       120
       +
       #### [Infrastructure for malleability](https://www.inkandswitch.com/essay/malleable-software/#infrastructure-for-malleability)

     

       121
       121
       +
       #### [Dynamic documents](https://www.inkandswitch.com/essay/malleable-software/#dynamic-documents)

     

       122
       122
       +
       

     

       123
       123
       +
       ### [Towards a better future](https://www.inkandswitch.com/essay/malleable-software/#towards-a-better-future)

     

       124
       124
       +
       

     

       125
       125
       +
       Big challenges ahead:

     

       126
       126
       +
       

     

       127
       127
       +
       > **Privacy and security**: How do we reconcile the desire for extensible software and interoperability with the reality of bad actors? When untrusted strangers are sharing modifications to existing software that can access sensitive data, dangerous things can happen.

     

       128
       128
       +
       > 

     

       129
       129
       +
       > **Business models**: How would developers make money from their software if they were shipping composable tools, not monolithic applications? How is support and maintenance paid for?

     

       130
       130
       +
       > 

     

       131
       131
       +
       > **Culture**: How do we cultivate a movement towards personal agency where people _want_ to modify their environments, both digital and otherwise?

     

       132
       132
       +
       > 

     

       133
       133
       +
       > These are daunting challenges. <mark>Technical capabilities can’t be a full solution; economic and cultural shifts will also be required.</mark> But change is possible—computing is still young, it has changed a lot in the past decades, and surely many structural shifts still lie ahead.

     

       134
       134
       +
       

     

       135
       135
       +
       > Everyone deserves the right to evolve their digital environments. It’s an important way to fulfill our creative potential and maintain a sense of agency in a world that is increasingly defined in code.

+1 -1

_notes/Malleable Software.md

···

       12
       12
        
       

     

       13
       13
        
       > Designing software environments where people can customize tools in the moment to meet their unique needs.

     

       14
       14
        
       

     

       15
       15
       -
       The "Malleable Software Essay" has not yet been published. It aims to set a foundation much as their April 2019 [[Local-first Software]] essay did.
     

       15
       15
       +
       The [[Malleable Software Essay]] essay was published in June 2025. It aims to set a foundation much as their April 2019 [[Local-first Software]] essay did.

+57

_notes/Malleable Systems Collective.md

···

       1
       1
       +
       > This catalog highlights projects, people, groups, research, discussions, and other initiatives in the malleable software community. It is our hope that bringing more awareness to these efforts will lead to greater collaboration and better systems for us all that support the [essential principles](https://malleable.systems/mission/) of malleability.

     

       2
       2
       +
       

     

       3
       3
       +
       _Community section & Principles outline copied from the website_

     

       4
       4
       +
       

     

       5
       5
       +
       Comparing with [[DWeb]] Principles is interesting.

     

       6
       6
       +
       ## Community

     

       7
       7
       +
       

     

       8
       8
       +
       The Malleable Systems Collective is a community space that [catalogs](https://malleable.systems/catalog/) and experiments with **malleable software and systems** that reset the balance of power via several essential principles detailed below.

     

       9
       9
       +
       

     

       10
       10
       +
       For all of these principles, it is not yet clear how to best achieve them, and there are sure to be many possible solutions with different tradeoffs. We’ll need to experiment as community with various approaches. The collective’s primary goal is to report on such efforts and raise awareness of work in these directions.

     

       11
       11
       +
       ## Principles

     

       12
       12
       +
       

     

       13
       13
       +
       ### 1. Easy to change

     

       14
       14
       +
       

     

       15
       15
       +
       _Software must be as easy to change as it is to use it.[^1]_

     

       16
       16
       +
       

     

       17
       17
       +
       ### 2. Arbitrary recombination and reuse

     

       18
       18
       +
       

     

       19
       19
       +
       _All layers, from the user interface through functionality to the data within, must support arbitrary recombination and reuse in new environments._

     

       20
       20
       +
       

     

       21
       21
       +
       ### 3. Open-ended potential

     

       22
       22
       +
       

     

       23
       23
       +
       _Tools should strive to be easy to begin working with but still have lots of open-ended potential._

     

       24
       24
       +
       

     

       25
       25
       +
       ### 4. Retain ownership and control

     

       26
       26
       +
       

     

       27
       27
       +
       _People of all experience levels must be able to retain ownership and control._

     

       28
       28
       +
       

     

       29
       29
       +
       ### 5. Freely sharable

     

       30
       30
       +
       

     

       31
       31
       +
       _Recombined workflows and experiences must be freely sharable with others.[^2]

     

       32
       32
       +
       

     

       33
       33
       +
       ### 6. Modifying in the context of use

     

       34
       34
       +
       

     

       35
       35
       +
       _Modifying a system should happen in the context of use, rather than through some separate development toolchain and skill set.[^3]

     

       36
       36
       +
       

     

       37
       37
       +
       ### 7. Thoughtfully crafted

     

       38
       38
       +
       

     

       39
       39
       +
       _Computing should be a thoughtfully crafted, fun, and empowering experience._

     

       40
       40
       +
       

     

       41
       41
       +
       Modern computing is a jungle of arcane, inscrutable tools that throw up walls of difficult to parse errors that slowly chip away at your enjoyment of the creative work of building something new. While today much of this is only seen by software developers, it does sometimes leak through, such as when raw error messages are displayed.

     

       42
       42
       +
       

     

       43
       43
       +
       If we are to have any hope of giving all people the same power over computers currently accessible only to experts, we must get rid of these obstacles by refining our tools so that we can focus more on the actual goal, which should make computing more fun and accessible to all.

     

       44
       44
       +
       

     

       45
       45
       +
       ## Revolution

     

       46
       46
       +
       

     

       47
       47
       +
       Most contemporary applications fail to meet all of these principles, leaving us with no pathway towards improvement. The only option is to plead with the app developer and hope they will deign to grant your request. As the importance of computing in everyday life grows with each passing year, we must fight for these values to ensure the power of computing is evenly distributed.

     

       48
       48
       +
       

     

       49
       49
       +
       We hope you agree this is a revolution worth fighting for.

     

       50
       50
       +
       

     

       51
       51
       +
       ---

     

       52
       52
       +
       

     

       53
       53
       +
       [^1]: This paraphrases [User-tailorable systems: pressing the issues with buttons](https://dl.acm.org/citation.cfm?doid=97243.97271) (MacLean et al., 1990): “it should be as easy to change the environment as it is to use it”.

     

       54
       54
       +
           

     

       55
       55
       +
       [^2]: This is adapted from [What Lies in the Path of the Revolution](https://malleable.systems/catalog/#revolution) (Basman and Tchernavskij, 2018) who argue that “all authors should have the ability to freely contribute their expressions to the work of others, and freely ‘buy into’ and ‘buy out of’ the expressions of others”. 

     

       56
       56
       +
           

     

       57
       57
       +
       [^3]: This draws on similar themes from the [in-place toolchain](https://www.inkandswitch.com/end-user-programming.html#in-place-toolchain) section of [End-user programming](https://malleable.systems/catalog/#enduser) (Ink & Switch, 2019).

+10

_notes/Vancouver.md

···

       1
       1
       +
       

     

       2
       2
       +
       

     

       3
       3
       +
       Vancouver resources:

     

       4
       4
       +
       <ul>

     

       5
       5
       +
       {% for post in site.notes %}

     

       6
       6
       +
       {% if post.tags contains "Vancouver" %}

     

       7
       7
       +
       <li><a href="{{ post.url }}" class="internal-link">{{ post.title }}</a></li>

     

       8
       8
       +
       {% endif %}

     

       9
       9
       +
       {% endfor %}

     

       10
       10
       +
       </ul>