├── .github
└── CODEOWNERS
├── .gitignore
├── .gitmodules
├── CODE_OF_CONDUCT.md
├── CONTRIBUTING.md
├── LICENSE.md
├── README.md
├── archetypes
├── blog.md
└── pages.md
├── config.yaml
├── content
├── _index.md
├── blog
│ ├── _index.md
│ ├── challenge-problem-fearless-extensibility.md
│ ├── digest-2020.md
│ ├── digest-2021.md
│ ├── digest-2022.md
│ ├── digest-2023.md
│ ├── digest-2024.md
│ ├── emacs.md
│ ├── forum.md
│ ├── welcome.md
│ └── wildcard-review.md
├── catalog
│ └── _index.md
└── pages
│ ├── code-of-conduct.md
│ ├── mission.md
│ └── participate.md
├── data
├── actors.yaml
├── catalog
│ ├── a-future-of-programming.yaml
│ ├── a-world-without-apps.yaml
│ ├── an-app-can-be-a-home-cooked-meal.yaml
│ ├── armories-for-tool-maker-tool-user-collaborations.yaml
│ ├── beta-programming-language.yaml
│ ├── boxer-a-reconstructible-computational-medium.yaml
│ ├── bring-your-own-client.yaml
│ ├── browser-extensions-are-underrated-the-promise-of-hackable-software.yaml
│ ├── brutalist-html-quine.yaml
│ ├── convivial-design-heuristics-for-software-systems.yaml
│ ├── crochet.yaml
│ ├── decker.yaml
│ ├── designing-and-programming-malleable-software.yaml
│ ├── dynamicland.yaml
│ ├── encoding-for-robust-immutable-storage-eris.yaml
│ ├── end-user-programming.yaml
│ ├── folk-computer.yaml
│ ├── glamorous-toolkit.yaml
│ ├── gnu-emacs.yaml
│ ├── hypercard.yaml
│ ├── liballocs.yaml
│ ├── lopecode-self-editing-humanely-embeddable-observable-notebooks.yaml
│ ├── mcculloch-pitts-neural-nets.yaml
│ ├── micro-prolog.yaml
│ ├── milliforth-forth-in-380-bytes-on-x86.yaml
│ ├── myths-and-mythconceptions-what-does-it-mean-to-be-a-programming-language-anyhow.yaml
│ ├── nova-multiset-rewriting-language.yaml
│ ├── pad-a-zooming-graphical-interface-for-exploring-alternate-interface-physics.yaml
│ ├── pinocchioverse.yaml
│ ├── sliding-blocks-computing.yaml
│ ├── smallscript-a-smalltalk-inspired-scripting-language.yaml
│ ├── smalltalk.yaml
│ ├── software-as-a-place.yaml
│ ├── syntropize-an-operating-environment-for-malleable-software.yaml
│ ├── tangible-functional-programming.yaml
│ ├── the-future-of-software-the-end-of-apps-and-why-ux-designers-should-care-about-type-theory.yaml
│ ├── the-mythical-matched-modules-overcoming-the-tyranny-of-inflexible-software-construction.yaml
│ ├── the-space-of-computing.yaml
│ ├── the-syndicated-actor-model.yaml
│ ├── tote-multiset-rewriting-language.yaml
│ ├── user-tailorable-systems-pressing-the-issues-with-buttons.yaml
│ ├── using-computers-more-freely-and-safely.yaml
│ ├── wang-tiles-computing.yaml
│ ├── webstrates-shareable-dynamic-media.yaml
│ ├── what-lies-in-the-path-of-the-revolution.yaml
│ └── wildcard-spreadsheet-driven-customization-of-web-applications.yaml
└── contributors.yaml
├── flake.lock
├── flake.nix
├── layouts
├── _default
│ ├── baseof.html
│ ├── list.html
│ ├── single.html
│ ├── taxonomy.html
│ └── terms.html
├── blog
│ ├── list.xml
│ └── single.html
├── catalog
│ └── list.html
├── index.html
└── partials
│ ├── menu-contextual.html
│ ├── opengraph.html
│ ├── site-favicon.html
│ ├── site-footer.html
│ ├── site-header.html
│ ├── site-navigation.html
│ ├── social-follow.html
│ ├── summary-with-image.html
│ ├── summary.html
│ ├── tags.html
│ └── twitter-cards.html
├── netlify.toml
├── scripts
├── .gitignore
├── config
│ └── default.json
├── package-lock.json
├── package.json
└── update-catalog.js
└── static
├── avatars
├── 7h3kk1d.jpg
├── akkartik.jpg
├── basman.jpg
├── cklokmose.jpg
├── computably.jpg
├── eagan.jpg
├── geoffreylitt.jpg
├── inkandswitch.png
├── jryans.jpg
├── karlicoss.jpg
├── khinsen.jpg
├── ptchernavskij.jpg
├── stephenrkell.jpg
├── weiwei.jpg
└── yoshikischmitz.jpg
├── css
├── custom.css
└── forkawesome
│ └── fork-awesome.css
├── fonts
├── forkawesome
│ ├── forkawesome-webfont.eot
│ ├── forkawesome-webfont.svg
│ ├── forkawesome-webfont.ttf
│ ├── forkawesome-webfont.woff
│ └── forkawesome-webfont.woff2
└── sourcesanspro
│ ├── bold-italic.woff2
│ ├── bold.woff2
│ ├── extra-light-italic.woff2
│ ├── extra-light.woff2
│ ├── italic.woff2
│ └── regular.woff2
├── js
└── shuffle.js
├── meta
├── android-chrome-192x192.png
├── android-chrome-512x512.png
├── apple-touch-icon.png
├── browserconfig.xml
├── favicon-16x16.png
├── favicon-32x32.png
├── favicon.ico
├── header.svg
├── mstile-144x144.png
├── mstile-150x150.png
├── mstile-310x150.png
├── mstile-310x310.png
├── mstile-70x70.png
├── safari-pinned-tab.svg
├── shortcut.svg
└── site.webmanifest
└── works
├── boxer.png
├── emacs.png
├── gtoolkit.png
├── hypercard.png
├── space.png
├── webstrates.png
├── wildcard.png
└── worldwithoutapps.jpg
/.github/CODEOWNERS:
--------------------------------------------------------------------------------
1 | * @malleable-systems/core
2 | /data/ @malleable-systems/curator
3 |
--------------------------------------------------------------------------------
/.gitignore:
--------------------------------------------------------------------------------
1 | .hugo_build.lock
2 |
--------------------------------------------------------------------------------
/.gitmodules:
--------------------------------------------------------------------------------
1 | [submodule "themes/ananke"]
2 | path = themes/ananke
3 | url = https://github.com/budparr/gohugo-theme-ananke.git
4 |
--------------------------------------------------------------------------------
/CODE_OF_CONDUCT.md:
--------------------------------------------------------------------------------
1 | # Contributor Covenant Code of Conduct
2 |
3 | ## Our Pledge
4 |
5 | We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.
6 |
7 | We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.
8 |
9 | ## Our Standards
10 |
11 | Examples of behavior that contributes to a positive environment for our community include:
12 |
13 | * Demonstrating empathy and kindness toward other people
14 | * Being respectful of differing opinions, viewpoints, and experiences
15 | * Giving and gracefully accepting constructive feedback
16 | * Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
17 | * Focusing on what is best not just for us as individuals, but for the overall community
18 |
19 | Examples of unacceptable behavior include:
20 |
21 | * The use of sexualized language or imagery, and sexual attention or
22 | advances of any kind
23 | * Trolling, insulting or derogatory comments, and personal or political attacks
24 | * Public or private harassment
25 | * Publishing others' private information, such as a physical or email
26 | address, without their explicit permission
27 | * Other conduct which could reasonably be considered inappropriate in a
28 | professional setting
29 |
30 | The three gates of speech are useful as guide: before you speak, let your words pass through three gates:
31 |
32 | * At the first gate, ask yourself, "is it true?"
33 | * At the second gate, ask "is it necessary?"
34 | * At the third gate, ask "is it kind?"
35 |
36 | ## Enforcement Responsibilities
37 |
38 | Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.
39 |
40 | Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.
41 |
42 | ## Scope
43 |
44 | This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
45 |
46 | ## Enforcement
47 |
48 | Instances of abusive, harassing, or otherwise unacceptable behavior may be
49 | reported to the community leaders responsible for enforcement at
50 | [abuse@malleable.systems](mailto:abuse@malleable.systems). All complaints will be reviewed and investigated
51 | promptly and fairly.
52 |
53 | All community leaders are obligated to respect the privacy and security of the reporter of any incident.
54 |
55 | ## Enforcement Guidelines
56 |
57 | Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:
58 |
59 | ### 1. Correction
60 |
61 | **Community Impact**: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community.
62 |
63 | **Consequence**: A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.
64 |
65 | ### 2. Warning
66 |
67 | **Community Impact**: A violation through a single incident or series of actions.
68 |
69 | **Consequence**: A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.
70 |
71 | ### 3. Temporary Ban
72 |
73 | **Community Impact**: A serious violation of community standards, including sustained inappropriate behavior.
74 |
75 | **Consequence**: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.
76 |
77 | ### 4. Permanent Ban
78 |
79 | **Community Impact**: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.
80 |
81 | **Consequence**: A permanent ban from any sort of public interaction within the project community.
82 |
83 | ## Attribution
84 |
85 | This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 2.0,
86 | available at https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.
87 |
88 | Community Impact Guidelines were inspired by [Mozilla's code of conduct enforcement ladder](https://github.com/mozilla/diversity).
89 |
90 | The three gates of speech section is borrowed from Merveilles's [discourse
91 | guide](https://wiki.xxiivv.com/site/discourse.html).
92 |
93 | [homepage]: https://www.contributor-covenant.org
94 |
95 | For answers to common questions about this code of conduct, see the FAQ at
96 | https://www.contributor-covenant.org/faq. Translations are available at
97 | https://www.contributor-covenant.org/translations.
98 |
--------------------------------------------------------------------------------
/CONTRIBUTING.md:
--------------------------------------------------------------------------------
1 | ## Contribution guide
2 |
3 | We hope the collective's [mission][mission] has inspired you to follow the
4 | community's work, post your thoughts, and share your experiments. There are many
5 | ways to get involved and contribute to this movement.
6 |
7 | ### Blog
8 |
9 | We'd like to host several kinds of posts from different voices in the community.
10 | If you'd like to write something, please [open an issue][issue] or [get in touch][mail].
11 |
12 | Some of the types of content we have in mind include:
13 |
14 | * Summaries of papers and projects in the community
15 | * Reports of experiments in progress
16 | * Essays on what malleable software should be and how we can get there
17 |
18 | ### Catalog
19 |
20 | Along with the blog, we've also started a [catalog][catalog] of projects,
21 | people, discussions, and other efforts in this field. We hope it can grow to
22 | become a comprehensive list of resources for the community.
23 |
24 | If you know of people, projects, threads, or anything else that should be added
25 | to [the catalog][catalog], please feel free to [edit the wiki][catalog-wiki]. If
26 | you're not sure what should be added, but you'd like to help with the curation
27 | effort, there's a [queue of items waiting to be added][catalog-issues], and we'd
28 | be happy to have your help curating them. If curation sounds like too much work,
29 | please at least [open an issue][issue] so it can eventually be added when
30 | someone has time to do so.
31 |
32 | The [about page][catalog-wiki-about] for the catalog wiki describes the
33 | forum-focused process in a bit more detail, and hopefully it given enough
34 | guidance to start making a contribution. Once you have edited the forum-based
35 | wiki, a site admin will merge the wiki changes into this repo.
36 |
37 | ### Contributors
38 |
39 | At the collective, we believe it's important to recognise all forms of
40 | contribution, so we're doing our best to record everyone involved in the process
41 | so we can [feature][contributors] them on the site. If you have made some kind
42 | of contribution, feel free to add yourself to the [contributors
43 | list][contributors-data]. A site admin may also do this for you.
44 |
45 | ### Preview
46 |
47 | If you would like to preview any changes made to the site, you should be able to
48 | do so locally:
49 |
50 | 1. Install [Hugo][hugo]
51 | 2. Clone this repo
52 | 3. Fetch submodules as well: `git submodule update --init`
53 | 3. Run `hugo server` at root level of the repo
54 |
55 | Our CI system will also deploy a preview site once you open your PR,
56 | so it's easy for everyone to check over your contribution.
57 |
58 | If you made it this far, thanks so much for your help! 😄
59 |
60 | ### Feedback
61 |
62 | At the end of the day, we want this to be a space for anyone working to advance
63 | the goals of malleable software. If you have thoughts or feedback on how best to
64 | achieve that, please [open an issue][issue] or [send us a note][mail].
65 |
66 | [mission]: https://malleable.systems/mission/
67 | [catalog]: https://malleable.systems/catalog/
68 | [issue]: https://github.com/malleable-systems/malleable.systems/issues/new
69 | [mail]: mailto:hello@malleable.systems
70 | [catalog-wiki]: https://forum.malleable.systems/c/catalog/7
71 | [catalog-wiki-about]: https://forum.malleable.systems/t/about-the-catalog-category/14
72 | [catalog-issues]: https://github.com/malleable-systems/malleable.systems/issues?q=is%3Aissue+is%3Aopen+label%3Acatalog
73 | [contributors]: https://malleable.systems/#contributors
74 | [contributors-data]: data/contributors.yaml
75 | [avatars]: static/avatars/
76 | [hugo]: https://gohugo.io/
77 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | # malleable.systems
2 |
3 | Modern computing is far too rigid. Applications can only function in preset ways determined by some far away team. Software is trapped in hermetically sealed silos and is rewritten many times over rather than recomposed.
4 |
5 | This community catalogs and experiments with malleable software and systems that reset the balance of power.
6 |
7 | Learn more by exploring [the site][site] and [the catalog of work][catalog] in this space.
8 |
9 | ## Contributing
10 |
11 | If you know of people, projects, threads, or anything else that should be added
12 | to [the catalog][catalog], please feel free to [edit the wiki][catalog-wiki]. If
13 | you have questions or feedback, feel free to open an issue or [send us a
14 | note][note]. Similarly, please let us know about anything that should be removed
15 | or corrected.
16 |
17 | For more info on contributing to the collective, please see the [contribution
18 | guide][contribute].
19 |
20 | [site]: https://malleable.systems
21 | [catalog]: https://malleable.systems/catalog/
22 | [catalog-wiki]: https://forum.malleable.systems/c/catalog/7
23 | [note]: mailto:hello@malleable.systems
24 | [contribute]: CONTRIBUTING.md
25 |
--------------------------------------------------------------------------------
/archetypes/blog.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: {{ replace .TranslationBaseName "-" " " | title }}
3 | date: {{ .Date }}
4 | author: "[J. Ryan Stinnett](https://convolv.es)"
5 | authorAvatar: jryans
6 | tags:
7 | categories:
8 | featured_image:
9 | description:
10 | ---
11 |
--------------------------------------------------------------------------------
/archetypes/pages.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: {{ replace .TranslationBaseName "-" " " | title }}
3 | date: {{ .Date }}
4 | featured_image:
5 | description:
6 | menu: main
7 | ---
8 |
--------------------------------------------------------------------------------
/config.yaml:
--------------------------------------------------------------------------------
1 | baseURL: https://malleable.systems/
2 | languageCode: en-gb
3 | title: Malleable Systems Collective
4 | theme: ananke
5 | enableRobotsTXT: true
6 |
7 | params:
8 | description:
9 | "The Malleable Systems Collective catalogs and experiments with malleable
10 | software and systems that reset the balance of power in computing"
11 | custom_css:
12 | - css/forkawesome/fork-awesome.css
13 | - css/custom.css
14 | licenseURL: https://creativecommons.org/licenses/by-sa/4.0/
15 | licenseName: CC BY-SA 4.0
16 | logo: /meta/header.svg
17 | mainSections:
18 | - blog
19 | email: mailto:hello@malleable.systems
20 | newsletter: https://buttondown.email/malleable-systems
21 | mastodon: https://hachyderm.io/@malleablesys
22 | twitter: https://twitter.com/malleablesys
23 | forum: https://forum.malleable.systems
24 | matrix: https://matrix.to/#/#malleable-systems:matrix.org
25 | github: https://github.com/malleable-systems
26 | source: https://github.com/malleable-systems/malleable.systems
27 |
28 | social:
29 | twitter: malleablesys
30 |
31 | permalinks:
32 | blog: /blog/:year/:month/:day/:title/
33 | tags: /blog/tags/:title/
34 | categories: /blog/categories/:title/
35 | pages: /:title/
36 |
37 | markup:
38 | goldmark:
39 | renderer:
40 | unsafe: true
41 |
--------------------------------------------------------------------------------
/content/_index.md:
--------------------------------------------------------------------------------
1 | ---
2 | recent_copy: Recent Posts
3 | all_copy: See all posts
4 | ---
5 |
6 | > The user wants open software, software that can be modified, and that can
7 | > participate in a progressive improvement process.
8 | >
9 |
10 | Modern computing is far too rigid. Applications can only function in preset ways
11 | determined by some far away team. Software is trapped in hermetically sealed
12 | silos and is rewritten many times over rather than recomposed.
13 |
14 | This community [catalogs][catalog] and experiments with **malleable software and
15 | systems** that reset the balance of power via several essential principles:
16 |
17 | 1. Software must be as [**easy to change**][mission-1] as it is to use it
18 | 2. All layers, from the user interface through functionality to the data within,
19 | must support [**arbitrary recombination and reuse**][mission-2] in new
20 | environments
21 | 3. Tools should strive to be easy to begin working with but still have lots of
22 | [**open-ended potential**][mission-3]
23 | 4. People of all experience levels must be able to [**retain ownership and
24 | control**][mission-4]
25 | 5. Recombined workflows and experiences must be [**freely sharable**][mission-5]
26 | with others
27 | 6. Modifying a system should happen [**in the context of use**][mission-6],
28 | rather than through some separate development toolchain and skill set
29 | 7. Computing should be a [**thoughtfully crafted**][mission-7], fun, and
30 | empowering experience
31 |
32 | Most contemporary applications fail to meet all of these, leaving us with no
33 | pathway towards improvement. The only option is to plead with the app developer
34 | and hope they will deign to grant your request. As the importance of computing
35 | in everyday life grows with each passing year, we must fight for these values to
36 | ensure the power of computing is evenly distributed.
37 |
38 | We hope you agree this is a revolution worth fighting for. We welcome your
39 | [feedback][feedback] and [contributions][contribute] of related projects and
40 | experiments from yourself and others. You can follow the community on
41 | [Mastodon][mastodon], [Twitter][twitter], our [forum][forum], [Matrix][matrix],
42 | and our [blog][blog]. The blog content is also available via our
43 | [newsletter][newsletter]. The [forum][forum] and [Matrix room][matrix] currently
44 | have the most activity, so we encourage you to give them a try.
45 |
46 | [catalog]: {{< relref "/catalog/_index.md" >}}
47 | [contribute]: https://github.com/malleable-systems/malleable.systems/blob/main/CONTRIBUTING.md
48 | [feedback]: mailto:hello@malleable.systems
49 | [mastodon]: https://hachyderm.io/@malleablesys
50 | [twitter]: https://twitter.com/malleablesys
51 | [forum]: https://forum.malleable.systems
52 | [matrix]: https://matrix.to/#/#malleable-systems:matrix.org
53 | [blog]: {{< relref "/blog/_index.md" >}}
54 | [newsletter]: https://buttondown.email/malleable-systems
55 |
56 | [mission-1]: {{< relref "/pages/mission.md#1-easy-to-change" >}}
57 | [mission-2]: {{< relref "/pages/mission.md#2-arbitrary-recombination-and-reuse" >}}
58 | [mission-3]: {{< relref "/pages/mission.md#3-open-ended-potential" >}}
59 | [mission-4]: {{< relref "/pages/mission.md#4-retain-ownership-and-control" >}}
60 | [mission-5]: {{< relref "/pages/mission.md#5-freely-sharable" >}}
61 | [mission-6]: {{< relref "/pages/mission.md#6-modifying-in-the-context-of-use" >}}
62 | [mission-7]: {{< relref "/pages/mission.md#7-thoughtfully-crafted" >}}
63 |
--------------------------------------------------------------------------------
/content/blog/_index.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Blog
3 | menu: main
4 | ---
5 |
--------------------------------------------------------------------------------
/content/blog/challenge-problem-fearless-extensibility.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Challenge problem: Fearless extensibility"
3 | date: 2024-07-24T20:22:41+01:00
4 | author: "[J. Ryan Stinnett](https://convolv.es)"
5 | authorAvatar: jryans
6 | tags:
7 | - Challenge problems
8 | - Forum
9 | categories:
10 | featured_image:
11 | description:
12 | ---
13 |
14 | Over on the [community forum][forum], we're trying out a new activity called a
15 | "challenge problem" where we focus on a theme for several months through
16 | submissions that may take various different forms. It's like a hybrid between a
17 | virtual workshop and a game jam.
18 |
19 | For our first challenge problem, the theme is "fearless extensibility". Why
20 | "fearless"...? Allowing extension authors complete freedom to change all aspects
21 | of a system may seem like a malleable path to take, but it carries with it
22 | maintenance and security headaches. How can we achieve powerful extensibility to
23 | configure systems to meet our individual needs while also reducing security and
24 | maintainability risks?
25 |
26 | If this sounds interesting to you, please see the [challenge problem
27 | thread][thread] for additional context and submission details. Submissions are
28 | due on 2024-11-01.
29 |
30 | [forum]: https://forum.malleable.systems
31 | [thread]: https://forum.malleable.systems/t/challenge-problem-fearless-extensibility/205
32 |
--------------------------------------------------------------------------------
/content/blog/digest-2020.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Collective digest — 2020
3 | date: 2020-12-28T06:09:23Z
4 | author: "[J. Ryan Stinnett](https://convolv.es)"
5 | authorAvatar: jryans
6 | tags:
7 | - Digest
8 | categories:
9 | featured_image:
10 | description:
11 | summary:
12 | "2020 is almost over... finally! It's been the longest and saddest year in
13 | recent memory due to the global pandemic. I hope you and your family are
14 | staying safe at home. Let's jump into this 2020 digest of collective
15 | activity and try to forget the general madness of the world for at least a
16 | few moments."
17 | ---
18 |
19 | 2020 is almost over... finally! It's been the longest and saddest
20 | year in recent memory due to the global pandemic. I hope you and your family are
21 | staying safe at home. Let's jump into this 2020 digest of collective activity and try to forget the general madness of the world for at least a few moments.
22 |
23 | ## Catalog
24 |
25 | In the early days of the collective site (March 2020, which feels like several
26 | years ago), there were 10 related works listed in our [catalog][catalog]. With
27 | the additional suggestions and curation of our community, we're now up to 19
28 | works in the catalog, with 27 further suggestions [waiting for
29 | curation][curation-queue]! Thanks to everyone for their contributions.
30 |
31 | The new additions to the catalog include:
32 |
33 | * [HyperCard][hypercard] (Bill Atkinson, Dan Winkler, HyperCard team at Apple)
34 | * [Glamorous Toolkit][gtoolkit] (feenk)
35 | * [User-tailorable systems: pressing the issues with buttons][buttons] (Allan MacLean, Kathleen Carter, Lennart Lövstrand, Thomas Moran)
36 | * [A Future of Programming][futureofprogramming] (Stefan Lesser)
37 |
38 | ## Matrix
39 |
40 | When we first set up this site, it wasn't clear which communication styles and
41 | channels would see the most use. Looking back over the first year, our [Matrix
42 | room][matrix] has by far seen the most activity among the community!
43 |
44 | Here's a sampling of interesting conversation topics from our room in 2020:
45 |
46 | * [Living in the stone age](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$WKM14pCdObsIQOBWr_8LUNpveYdY14GAMqTcZRp5iiY)
47 | * [Security, capabilities](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$piaQ6gO5iL37DSpTqyNU-ZaOfAKBRoifORAEuCdKdIo)
48 | * [UI customisation, tearing down walls between apps](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$sliTfTMxGhSviieq9LTITiKGVriiGadtK1SpC5JJoEU)
49 | * [Avoiding silos, core web concepts](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$ZXJ1jtOokVL1KFvZjSj9IxOkuN3KWt2Up-2ueElJIJU)
50 | * [TiddlyWiki, local-first data storage](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$_gsQcAsP1h4tflsA16efW5gcXsakqRkwhaC7clOo7QM)
51 | * [The path ahead, many different experiments needed](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$DfXgRUQZmHIWi4Oze6kb5ZUQRTZdt3XLTLkQ9BOXAjw)
52 | * [Extracting frames out of apps](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$l10B1LIdJPwZsIUdUOuUjrDsOV2yVKq99YCQ-QhSWgg)
53 | * [Challenges of funding open software](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$DenH499rHZGBw_WBpytGtaVSXubvL81CCox_jtR-a7c)
54 | * [Static and gradual typing for modules](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$wyNOzn2sZAKpS8gsUHZQ5JZezB79G6QUtEUDR9RXGjI)
55 | * [Self, Smalltalk](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$D70bKOK9l9ju8uz4wuhXW1FPgtl6xPElEPzVbQ9P3MY)
56 | * [Language design, gradual typing](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$3fSHBP4m-QjCn1m-2ChKxFx4booNUvvrxWvU6i6FWcY)
57 | * [Moving programs across devices](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$uRntmaT5ggTIDsF0wVJx_KoeoyEres_XoIc3Jc7slWg)
58 | * [Window management](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$K7kjIFuiXEjWoo_ubR_towA-aia3ZoVogPuxVo1fjb0)
59 | * [Project Cambria, lenses](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$YFO_D5wCf2qQ8vvot2dgVRmDXxPW0bBsDqUkCVFKq90)
60 | * [Related podcasts](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$coVDSloIwe0bgP-BXmnqsc2pUYQnSpmBuG4y5zLaxCA)
61 | * [Add-on systems](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$F1T3cPbVc9-YR5VsyipqdAw7OUUBTjAhh3dqnCWN7Ao)
62 | * [Knowledge management tools](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$W225Bgcgu5-pRlv4Oe47YuqNTEsjpGxGcvmy18P9ivg)
63 | * [Decentralised authentication](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$JS-WNNHG3rfYFHzEzDYMDayQ3jREgVKYhTCoiRzL-Gs)
64 | * [Extensibility, resource sandboxing, permission management](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$w5ZyI5bWMxlwy3dDPREzEQVMlvKLPRY9LuKZ-52u67o)
65 |
66 | ## Related communities
67 |
68 | The collective's goals and dreams intersect with some other communities, which
69 | we encourage you to check out:
70 |
71 | * [Thinking Tools][thinking-tools]: rethinking how we create, share and organise
72 | knowledge
73 | * [Future of Coding][future-of-coding]: sharing many different projects and
74 | possible futures of more humane computing
75 |
76 | ## Looking ahead
77 |
78 | In the year ahead, we hope the collective will continue to grow and take on a
79 | more active experimentation role as some of us try out various ideas we've
80 | discussed. In particular, we're hoping to have more projects and experiments
81 | shared here on the site as people try out various approaches to extensibility
82 | and user empowerment. As always, please do [contact us][feedback] if there's
83 | something you'd like to share with the collective. I'm planning to share my own
84 | efforts here, and perhaps that will encourage others to do the same.
85 |
86 | 2020 was quite a draining year, and I found it hard to have energy for new
87 | efforts. I imagine many people may have gone through something similar. I've got
88 | big plans for 2021, and I bet many of you do as well. I hope the world state
89 | will allow us all to follow through on our dreams of malleability in the new
90 | year.
91 |
92 | [catalog]: {{< relref "/catalog/_index.md" >}}
93 | [feedback]: mailto:hello@malleable.systems
94 | [matrix]: https://matrix.to/#/#malleable-systems:matrix.org
95 | [curation-queue]: https://github.com/malleable-systems/malleable.systems/issues?q=is%3Aissue+is%3Aopen+label%3Acatalog
96 |
97 | [hypercard]: {{< relref "/catalog/_index.md#hypercard" >}}
98 | [gtoolkit]: {{< relref "/catalog/_index.md#gtoolkit" >}}
99 | [buttons]: {{< relref "/catalog/_index.md#buttons" >}}
100 | [futureofprogramming]: {{< relref "/catalog/_index.md#futureofprogramming" >}}
101 |
102 | [thinking-tools]: https://thinkingtools.space
103 | [future-of-coding]: https://futureofcoding.org
104 |
--------------------------------------------------------------------------------
/content/blog/digest-2022.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Collective digest — 2022
3 | date: 2022-12-30T15:33:52Z
4 | author: "[J. Ryan Stinnett](https://convolv.es)"
5 | authorAvatar: jryans
6 | tags:
7 | - Digest
8 | categories:
9 | featured_image:
10 | description:
11 | summary:
12 | "2022 wobbled it's way through some version of normality, with a bit more
13 | energy than recent years, but there's still a lot going wrong as well...
14 | Let's jump into this 2022 digest of collective activity and reflect on our
15 | conversations over the past year."
16 | ---
17 |
18 | 2022 wobbled it's way through some version of normality, with a bit more energy
19 | than recent years, but there's still a lot going wrong as well... Let's jump
20 | into this 2022 digest of collective activity and reflect on our conversations
21 | over the past year.
22 |
23 | ## Catalog
24 |
25 | In 2022, we added 1 more work to our [catalog][catalog], bringing the total to
26 | 26 items. There are 45 further suggestions [waiting for
27 | curation][curation-queue].
28 |
29 | The new addition to the catalog is:
30 |
31 | * [Crochet][crochet] (Q)
32 |
33 | It's fairly clear now that the current catalog process is too heavyweight. I
34 | hope we can move to a lighter workflow in the future that feels more like
35 | editing a wiki.
36 |
37 | ## Mastodon
38 |
39 | Twitter's descent rapidly escalated this year. Many community members moved to
40 | Mastodon. A [collective Mastodon account][mastodon] now exists, so please do
41 | follow along there. The [contributors section][contributors] also lists Mastodon
42 | accounts for those that have them.
43 |
44 | ## Matrix
45 |
46 | Our [Matrix room][matrix] has continued to be the most active communication
47 | medium used by the community.
48 |
49 | Here's a summary of interesting conversation topics from our room in 2022:
50 |
51 | * [TypeCell, notebooks, CRDTs, Matrix rooms as data stores](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$j8rIqdPRB74z7jW3Ku5R2fQQEqedOwPOpHBkxpY2zic)
52 | * [Audit logs, sandboxing](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$dJqxPgUYitQd2ixktdugbHn6LYru_KwF71zqY0l4hU4)
53 | * [Goals for 2022](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$4JSs78ftYWnfYxxyM9p8pVOZoYn8WQ9VFaULkhBNLcs)
54 | * [Long form communication medium, malleable wikis](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$V2fUENjO-igkpzfC_MnBt2JWYpoJ5YASFO7liyN8ShI)
55 | * [TUIs, SSH apps](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$xhyUKOY8aIr9TlETMQIL1rJTTdXH6kl-tI4mRW2L8-0)
56 | * [Catalog ported to TiddlyWiki and Glamorous Toolkit](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$XhWVMm1c7hX4XJeudth3tnsJIuc8HhermL04Ud52NjQ)
57 | * [Data colonialism](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$HdoGZpMPoZwqcHwh8n18fl_Yriwr7_jYKJlDDJ9r4Hk)
58 | * [Division of labor](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$Zln7bxNU42vZgR5z3SN5avH1LZf4RH_WFyMMsqg65N4)
59 | * [Common Lisp history, standardising languages](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$BhqEI0SXYWS5JHuv0hFdUYtRjyYebiUz1Hw7TileQh4)
60 | * [Static vs. dynamic type systems, formal verification](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$kVyvOjvvaf3kMNQ7ecBChma0FwdtrhTOxVdL6ONx4ns)
61 | * [Malleability for domain experts](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$INnamnQDZZ-Zeoz9UzG0hDrxlw-YN5i_5PdS1SofMP4)
62 | * [Block protocol, document models](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$wdtDGNb08ZmBxkMnpW0XofggD04Ua3euVshgMxP3sjE)
63 | * [Plugin-style customisation, platform capabilities](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$wTfofYIDsIgk5-nxGltf9n-mwF-3OBhZEjhc_4MZ62A)
64 | * [Social structures, obstacles, research funding](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$K5t2j1C1aKtUEJohtyH_4K-fmQfKRT_vCeZtLg_lTxA)
65 | * [Startups, afraid of open platforms](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$L7dVUVduo5XS661tLTYjHfOrmkw7V0HB8-n-F_8gckU)
66 | * [Ledgers, homomorphic encryption](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$_sZ_DUaLJKKCt8sER15xxJXZ-G9foeruj7g3kkTXE-k)
67 | * [Unified project, parsing / serialisation](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$haIgSOJmXHDCQCgIlQLM0T2lYcTzC7TbOjfvlIsNNUg)
68 | * [Kartik Agaram's Teliva, Zettelkasten, sandboxing](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$8VlKZ7GEaK9XoLsiBfZQEuh2_Oj3852KX7TjKWvFX30)
69 | * [Web-based OS, trusted agent](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$CdxzEE61lsxUok5VXNT-QfATRc4qkk2bjN6vKfPI1aU)
70 | * [Wasm, JVM, interoperability, debugging, profiling](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$coPaPi-7R0bJzMNqXdFiCl3s_Ooic_ceX_jTa0-iWp8)
71 | * [Monocultures, privacy](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$4-xw_id7JmDE4mC5JO53Miqgrf5njGxZBecBoevh7KY)
72 | * [Programming systems](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$swLe103GL8DiuRczxD_FkFFvcpE0lOS9zPuLsnci-50)
73 | * [Modular hardware](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$PtnTGcw7Mqlr-rAqpJZhqxaWTlHgupOELErslJKlEYc)
74 | * [Compile-time vs. run-time type checking](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$4FMebZovxElvArVy4JK7hbDYdgkpwcI2JsfRpvcL80I)
75 | * [Debugging, inspecting state](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$u2ioL1wV5aO4hqYB9xJgE1YGyIulKvJ7f4nSvRZnH3Y)
76 | * [Encapsulation, program reuse](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$jjRUNe_lXWsE0yhjyBC7gSTqysSi0nI_O6W3BCfnkzI)
77 | * [Metamuse, CRDTs](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$LGAyASexBM9OuIt7TPNdVv6O1X5D_TigZ-4l2BuxpvQ)
78 | * [Programming workflows, notebooks, Alex Bandukwala's draft blog post](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$mScfuCfh5Oftt--5JnRJNvDsfttEk1kh3nlH1lw65go)
79 | * [Debugging optimised programs](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$AKxsQkQwFlwD59biuWjkLzL-XvrKiio5rhvJNEt0p7E)
80 | * [Incremental workflows, late binding](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$Ect1GdFFO3iIa9KxTWpWwDfSKEPXHldD6KkuGq3ds1w)
81 | * [Folk interfaces, end-user programming](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$M2Cu3wENsHKYXKku6raq2fH0-AFi078hoTRWcs5XG1E)
82 | * [Unison language, collaboration, distributed programming](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$l123H2IadVO0ZTTmcaWGypsb1imoV4fm0jNk3RjrA4c)
83 | * [Common Lisp, code browser, GUI toolkits](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$38zcbZgmYJm18BtAKw4qTFmuJtq3J2ygUGoSwFOfCmw)
84 | * [Industry headwinds, simple but wrong answers](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$J_OFwr3bxcvywSsvWWTuaudEh-qhY-EpkqZgSV1vjaw)
85 | * [File managers, removing files from the OS](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$U67mLYYlbYs9FHiv0HNcyR_kpIq4YgrYRuTG2nU9-YA)
86 | * [Projectional editing](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$kmfyNb5irahEXJSx14VglzzPNfhiKICkP2m4tYhmbCc)
87 | * [Subconscious, distributed data storage](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$bk8d6M_lBq1hcvZAjfYRxMceKIKO12rQ2PogMG2raLo)
88 | * [Interactive / REPL-driven workflows](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$-ozjeAndcma1635MGJuTyt5dftikuXK52d0RNBJvgUo)
89 | * [Annotations](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$FikAVb9_77XPcBOktfFTC10XTnBES3s49Id1_5AguWg)
90 | * [Languages, funding](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$ZRRB1ZedvEEnZCe7uhNm3TYFHDFhGTXaWUMcY_7t74I)
91 | * [Future of Coding podcast, Richard P. Gabriel](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$nQGJ1quD9NN4GxcQ15JppS5C-yPc2e-FucFCywEycEc)
92 | * [Jack Rusher's Stop Writing Dead Programs talk](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$geGvydiB5oDQ_xptA0sOuGcPckWRmvtJNxQFaBHeMjU)
93 | * [Type systems, capabilities, effects](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$1oTy7ugx5PjpEukDhGlmyFjuQQ2hJvGgcSAj2t_9DCM)
94 | * [Universality, interoperability](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$CNQa-mKL_umS-OvN4-qh5MxCM-qLsM1wYN_qy0qWCZ4)
95 | * [Mastodon](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$oyKg-dyLWq_w92T6TYNUpCsJw2M4bHCw7_PnyRS_wg8)
96 | * [Webstrates](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$WFisPQx36kxNW3_3hzpMLbLzQQnmnwB7YZm99Z7ZVAo)
97 | * [Expression vs. stepping debuggers, term rewriting](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$p4QQTgGQlE0mSLTqizhJTaDUfQk9IHrFz_fcPDQYEN0)
98 |
99 | There continues to be interest in adding a long form communication medium
100 | (such as a Discourse forum). I'm hopeful we'll have some time to arrange this in
101 | the new year.
102 |
103 | ## Looking ahead
104 |
105 | I hope we'll continue to have insightful conversations as a community. I know
106 | I've learned quite a few new things as part of our discussions, and I hope
107 | others have as well.
108 |
109 | As always, please do [contact us][feedback] if there's something you'd like to
110 | share with the collective.
111 |
112 | [catalog]: {{< relref "/catalog/_index.md" >}}
113 | [feedback]: mailto:hello@malleable.systems
114 | [mastodon]: https://hachyderm.io/@malleablesys
115 | [matrix]: https://matrix.to/#/#malleable-systems:matrix.org
116 | [curation-queue]: https://github.com/malleable-systems/malleable.systems/issues?q=is%3Aissue+is%3Aopen+label%3Acatalog
117 | [contributors]: {{< relref "/_index.md#contributors" >}}
118 |
119 | [crochet]: {{< relref "/catalog/_index.md#crochet" >}}
120 |
--------------------------------------------------------------------------------
/content/blog/digest-2024.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Collective digest — 2024
3 | date: 2024-12-28T22:49:13
4 | author: "[J. Ryan Stinnett](https://convolv.es)"
5 | authorAvatar: jryans
6 | tags:
7 | - Digest
8 | categories:
9 | featured_image:
10 | description:
11 | summary:
12 | "2024 is drawing to a close.
13 | It's time for our annual digest of collective activities over the past year!"
14 | ---
15 |
16 | 2024 is drawing to a close.
17 | It's time for our annual digest of collective activities over the past year!
18 |
19 | ## Discourse
20 |
21 | Our [Discourse-based forum][forum] continues to be our most active communication
22 | medium. If you're not already on the forum, please do check it out.
23 |
24 | Here are some of the topics we discussed:
25 |
26 | - [Small Virtual Machines](https://forum.malleable.systems/t/small-virtual-machines/148)
27 | - [Collapse Computing](https://forum.malleable.systems/t/collapse-computing/143)
28 | - [Alan Kay's Quora dialogues and the philosophical dilemma of Systems thinking](https://forum.malleable.systems/t/alan-kays-quora-dialogues-and-the-philosophical-dilemma-of-systems-thinking/173)
29 | - [Shouldn't the phone be our target?](https://forum.malleable.systems/t/shouldnt-the-phone-be-our-target/235)
30 | - [Feedback on a malleable operating system](https://forum.malleable.systems/t/feedback-on-a-malleable-operating-system/230)
31 | - [Rethinking the object-oriented paradigm - what can we throw away?](https://forum.malleable.systems/t/rethinking-the-object-oriented-paradigm-what-can-we-throw-away/199)
32 | - [Taking Alan Kay's vision to the extreme](https://forum.malleable.systems/t/taking-alan-kays-vision-to-the-extreme/200)
33 | - [Bootstrappable Software](https://forum.malleable.systems/t/bootstrappable-software/149)
34 | - [The Brutalist Programming Manifesto](https://forum.malleable.systems/t/the-brutalist-programming-manifesto/146)
35 | - [The Mystery of Moose](https://forum.malleable.systems/t/the-mystery-of-moose/163)
36 | - [Objects as Records vs Activities](https://forum.malleable.systems/t/objects-as-records-vs-activities/273)
37 | - [Spaces of Data](https://forum.malleable.systems/t/spaces-of-data/223)
38 | - [Reversibility](https://forum.malleable.systems/t/reversibility/259)
39 | - [A programming environment with first class categories](https://forum.malleable.systems/t/a-programming-environment-with-first-class-categories/179)
40 | - [Decker](https://forum.malleable.systems/t/decker/154)
41 | - [Point-Free Logic Programming](https://forum.malleable.systems/t/point-free-logic-programming/151)
42 | - [Micro-PROLOG](https://forum.malleable.systems/t/micro-prolog/150)
43 | - [Modal](https://forum.malleable.systems/t/modal/183)
44 | - [folk.computer](https://forum.malleable.systems/t/folk-computer/236)
45 | - [Modules vs Centers: Thinking about Christopher Alexander's Thought in Software](https://forum.malleable.systems/t/modules-vs-centers-thinking-about-christopher-alexanders-thought-in-software/145)
46 | - [Nova: Multiset Rewriting Language](https://forum.malleable.systems/t/nova-multiset-rewriting-language/274)
47 |
48 | ## Matrix
49 |
50 | Our [Matrix room][matrix] remains active as well.
51 |
52 | Here's a summary of interesting conversation topics from our room this year:
53 |
54 | - [Programming for the Planet (PROPL) workshop](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$wBizPt2elCls-4x51BjJK2ZUZ2NElSfQYHaOh88K-bU)
55 | - [Autonomous cells, self-organisation](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$u1cmypgjrC0uLHNQVrUZlmYT8GW6gnsFzLoAbbv3D3Q)
56 | - [LLMs in conflict with malleability](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$VmTuljbtUPC4igGvwsjW0YnfEo60BmsBBb6gx-aeFxY)
57 | - [Linked data, fediverse](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$JymknR-eCQzbTUwehXLBjHkUYE1d4d7TrFuk7v5Z3rs)
58 | - [Target users: tinkerers vs. consumers](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$IhJ95_OApup4HRQkJnocFnvoVrWvSTVvLXcQoshq5Fc)
59 | - [Evaluating projects in relative terms](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$vyHqwdwQk6p7gJXSu0UhqYKqPhjU_oAncCu3_XHB_cU)
60 | - [Software complexity](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$h1bvyJLybba9dlr5kxh-bRfFRZg1ZwFJs7skcYVcUHU)
61 | - [Browser extension, construction kit](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$z0XopcoT9UQvr3x3EOFHIff3RJl6TuJ21BQenQr2kHA)
62 | - [Wasm's potential](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$kvG8ahWgFdK3V_6RPmqcHYzaV_P6mgtgzT9P6arTlgc)
63 | - [Orion's DOM to canvas prototype](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$d9M3LLd1OTAMRbfrU92KLLTmSuAemeCPV5fPnmdmwWI)
64 | - [Incremental build systems](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$csFlnQ4fLT3_bMqCMc8bE0E0uPgPJKMD4_PIXaKiRDc)
65 | - [Evaluation framework](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$t3Vt1d2CDiG8IvM9yg0DDR9V9Kbzj80e3F6icf6KN5M)
66 | - [Damaged Earth Catalog](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$8k9BY54EFu8H5Kbzs_oF3k5AcqRidG5PQKJj8L3ziiY)
67 | - [UI design: search, toolbar, command palette](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$L7KRy2hRmWlzp926XoYMmTLrMROmZ4vG06HGdg_KA18)
68 | - [Natto](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$W7uoOU5b4w0lPJe9SPL6XluwOKJg36hsDFFUulG0Xrw)
69 | - [Aarhus conference, computing conflict](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$RzvghzwWJs1cJMmKut5ao1g0GqLAzx01OOpOjkKdLQU)
70 | - [Typed polyglot environments](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$JD4OoTKmt6_ioHllh467T6XmIgavcWm8Yg6c6GWrJd4)
71 | - [Workflows for domain experts](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$T-upGEJdg7NrlesK6eooiJ1GBCnQ77bGaA90yzjxMn8)
72 | - ["Circuit board"-style extension host](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$hndWly3T_FxuhHtgAoItmJOHASr_4xit-uIUuhqEo14)
73 | - [Joel's self-sustainability thesis](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$L3Dloc4iCJongB6Z-76qPldFcS0YLIVfMtevn8891cY)
74 | - [Maggie's "home-cooked software"](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$k5nDQChHkMPMbbIa8BaEwmhiF4V2V731C3YDgx0vdaQ)
75 | - [Webstrates as local-first software](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$sYJivM4ieEsbDF62xC_t9e46zx9Tv6bt-iqZwdNZV5M)
76 | - [Convivial computing origin](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$RGjsi1iEUE19vABj1hwGeyGRqcx8Av_iFf7ZMTHvSsk)
77 | - [Example of user empowerment](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$H4z_gKluc_ZEo9S0Gj35xikDYLKmrP0LZF7EVNCuPZg)
78 | - [Video game development experience, Arcan](https://matrix.to/#/!bQveTkYXFyxLJQwcLG:matrix.org/$0EXwjn3YLyGqQjdeEJum0u85N5ktDeqb6gi15knfHiw)
79 |
80 | ## Challenge problem
81 |
82 | This year, we tried out a "challenge problem" focused on [fearless
83 | extensibility][fe-blog]. Our community pondered this topic for several months
84 | and contributed many interesting [submissions][fe-submissions]. Overall, I think
85 | it was quite successful and hopefully we'll run a similar event in the future
86 | for another topic.
87 |
88 | ## Looking ahead
89 |
90 | Are there other activities you'd like our community to try out in the future?
91 | We're still a small group all things considered... Should we attempt to more
92 | actively publicise our existence somehow? Please share your thoughts.
93 |
94 | [forum]: https://forum.malleable.systems
95 | [catalog]: {{< relref "/catalog/_index.md" >}}
96 | [catalog-wiki]: https://forum.malleable.systems/c/catalog/7
97 | [matrix]: https://matrix.to/#/#malleable-systems:matrix.org
98 |
99 | [fe-blog]: {{< relref "./challenge-problem-fearless-extensibility.md" >}}
100 | [fe-submissions]: https://forum.malleable.systems/c/challenge-problems/fearless-extensibility/9
101 |
--------------------------------------------------------------------------------
/content/blog/forum.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Community forum now available
3 | date: 2023-06-20T21:54:50+01:00
4 | author: "[J. Ryan Stinnett](https://convolv.es)"
5 | authorAvatar: jryans
6 | tags:
7 | - Forum
8 | categories:
9 | featured_image:
10 | description:
11 | ---
12 |
13 | Do you have malleable ideas or projects you'd like to discuss, but you've been
14 | wishing there were a more structured medium for longer conversations than just
15 | the [Matrix room][matrix]?
16 |
17 | Try out our new [community forum][forum]! 🎉
18 |
19 | Along with a forum-style interface for general discussion, there's also special
20 | support for our catalog, which is now easily [editable][catalog-about] via
21 | [wiki-style posts][catalog-wiki] on the forum.
22 |
23 | The Matrix room will continue to live on in parallel with the forum. Come on by
24 | the forum and share your malleable ideas and projects. 😄
25 |
26 | [forum]: https://forum.malleable.systems
27 | [catalog-about]: https://forum.malleable.systems/t/about-the-catalog-category/14
28 | [catalog-wiki]: https://forum.malleable.systems/c/catalog/7
29 | [matrix]: https://matrix.to/#/#malleable-systems:matrix.org
30 |
--------------------------------------------------------------------------------
/content/blog/welcome.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Welcome
3 | date: 2019-12-26T19:52:19Z
4 | author: "[J. Ryan Stinnett](https://convolv.es)"
5 | authorAvatar: jryans
6 | tags:
7 | categories:
8 | featured_image:
9 | description:
10 | "Welcome to the Malleable Systems Collective, a community space for those
11 | interested in redefining our relationship with software by dismantling the
12 | boundaries of contemporary applications."
13 | ---
14 |
15 | Welcome to the Malleable Systems Collective, a community space for those
16 | interested in redefining our relationship with software by dismantling the
17 | boundaries of contemporary applications.
18 |
19 | If you haven't already, read through the collective's [mission][mission] to get
20 | an idea of the revolution we're working towards. While we believe this mission
21 | is achievable, it will likely take many years and the work of many people to
22 | achieve. Quite a few of the ideas that our mission is built around have been
23 | percolating for decades already.
24 |
25 | It's our hope that the collective can become a long-term home for people,
26 | projects, and ideas fighting to make this mission a reality.
27 |
28 | We're planning to share a variety of content on this blog, including:
29 |
30 | * Summaries of papers and projects in the community
31 | * Reports of experiments in progress
32 | * Essays on what malleable software should be and how we can get there
33 |
34 | Along with the blog, we've also started a [catalog][catalog] of projects,
35 | people, discussions, and other efforts in this field. We hope it can grow to
36 | become a comprehensive list of resources for the community.
37 |
38 | If you'd like to add your own voice, please [get in touch][feedback]. There are
39 | many hard problems ahead of us, but I believe we can achieve great things by
40 | exploring solutions together. The collective is happy to have contributions of
41 | all kinds in whatever state of completion you're comfortable with sharing,
42 | ranging from random thoughts you had in the shower through to peer-reviewed
43 | research publications. We aspire to "[work with the garage door up][garage]" and
44 | believe it's best to share ideas and experiments with the community early on in
45 | the process.
46 |
47 | We hope you'll join the fight to save us all from [digital serfdom][revolution].
48 |
49 | [mission]: {{< relref "/pages/mission.md">}}
50 | [catalog]: {{< relref "/catalog/_index.md">}}
51 | [feedback]: mailto:hello@malleable.systems
52 | [garage]: https://notes.andymatuschak.org/Work_with_the_garage_door_up
53 | [revolution]: {{< relref "/catalog/_index.md#revolution">}}
54 |
--------------------------------------------------------------------------------
/content/blog/wildcard-review.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Wildcard review"
3 | date: 2020-02-29T18:44:32Z
4 | author: "[J. Ryan Stinnett](https://convolv.es)"
5 | authorAvatar: jryans
6 | tags:
7 | - Review
8 | - Paper
9 | featured_image:
10 | description:
11 | summary:
12 | "Geoffrey Litt and Daniel Jackson have been working on Wildcard, which
13 | enables customising websites via one of the most popular programming models
14 | in existence today: the spreadsheet. Wildcard's sheet is bidirectionally
15 | linked to the site content, so that changes and also user additions to the
16 | sheet are reflected back in the site's UI. Similarly, if the site content
17 | changes, the sheet is updated as well."
18 | ---
19 |
20 | [Geoffrey Litt][litt] and [Daniel Jackson][jackson] have been working on
21 | [Wildcard: Spreadsheet-Driven Customization of Web Applications][wildcard],
22 | which they will be presenting at the [Convivial Computing Salon 2020][salon]
23 | workshop in March. (_Disclaimer: I am on the program committee for the
24 | Salon, but I was not involved in any part of Wildcard's review process at the
25 | workshop._)
26 |
27 | ## Summary
28 |
29 | Wildcard enables customising websites via one of the most popular programming
30 | models in existence today: the spreadsheet. Wildcard's sheet is bidirectionally
31 | linked to the site content, so that changes and also user additions to the sheet
32 | are reflected back in the site's UI. Similarly, if the site content changes, the
33 | sheet is updated as well.
34 |
35 | 
36 |
37 | The [web version of the paper][wildcard] includes several videos demonstrating
38 | how this concept can be used to augment search results with additional data, add
39 | small bits of functionality based on user-added data, and drive form inputs
40 | with smarter controls.
41 |
42 | > Our approach requires extracting structured data from the user interfaces of
43 | > existing applications, but we hide the complexity of data extraction from end
44 | > users. Programmers write site adapters which use web scraping techniques to
45 | > extract structured data from existing applications and map it to the
46 | > spreadsheet table.
47 |
48 | Since websites in 2020 do not contain much in the way of attached metadata that
49 | would support extracting the sheet's data, Wildcard relies on experts to write
50 | site-specific adapters to extract data, keep it in sync, etc. This
51 | does mean the approach can't immediately be used on a new site, but the Wildcard
52 | authors believe that if the tool proves popular, a growing repository of
53 | adapters would come to life. After the one-time step of writing a site adapter,
54 | anyone of any experience level can use Wildcard to explore, manipulate, and
55 | extend the site's content for their own purposes.
56 |
57 | > Low floor, high ceiling: Wildcard provides an easy entry point for end users,
58 | > since small tweaks like sorting data can be performed with a single click. At
59 | > the same time, it also supports a variety of richer customizations, like
60 | > adding private annotations to a webpage or joining in related data from a web
61 | > API.
62 |
63 | Wildcard's spreadsheet model allows for a form of [open-ended
64 | potential][mission-3]: it's very easy to get started, but also allows you to
65 | achieve more complex customisations as you become more familiar with the system.
66 |
67 | > Generic tools are especially important for software customization, because a
68 | > common barrier to customizing software is not having enough time [Mackay 1991]
69 | > — it’s more likely that people will customize software frequently if they can
70 | > reuse the same tools across many applications.
71 |
72 | One of the major design goals of Wildcard is supporting customisation through a
73 | "universal data structure". While Unix tools have historically piped text around
74 | for such things, Wildcard focuses on the spreadsheet / relational table as a
75 | view of data that can be used in many contexts. All designers of tools that
76 | enable software malleability would do well to remember that their tool is just
77 | supporting the user in completing the actual goal they want to achieve.
78 | Anything that helps users understand and use the tool more quickly and easily
79 | will greatly boost its general utility. For Wildcard, focusing on the
80 | spreadsheet model is one way the authors have given their tool more generality.
81 |
82 | > Documents (e.g. Google Docs) or graphs (e.g. social network friend graphs) may
83 | > prove more challenging to map to the table abstraction.
84 |
85 | Of course, there are also many sites that are more interactive or involve data
86 | that does not map well to a list of items. Even with that limitation, I think
87 | Wildcard will still prove useful, as there are quite a lot of sites that do fit
88 | well with a table-style data model.
89 |
90 | ## Questions and future work
91 |
92 | From reading the paper, I couldn't tell how the extra user columns are mapped
93 | onto each list item in the site. In the demo videos, user data added to the
94 | sheet seems to magically appear in a relevant part of the site's UI. This leads
95 | me to assume that the site adapters define a fixed, generic location for user
96 | data to appear that can't be changed from the sheet. Assuming that's the case,
97 | it does seem better than having no user data at all, but the ideal UI location
98 | is likely highly variable and dependent on the type, length, etc. of the content
99 | that the user wants to add. I would like to see future work that explores ways
100 | of allowing more control over how and where the user data attaches to the page.
101 |
102 | As the authors suggest several times in the paper, maintaining a reliable set of
103 | site adapters could easily become complex. Sites are constantly changing, and
104 | the adapters would need to be updated to match. At the very least, structural
105 | changes to the DOM would likely imply work for adapter maintainers, but perhaps
106 | even more kinds of site changes would as well.
107 |
108 | While this reliance on expert curation of site adapters is reasonable given
109 | what's possible today, I believe we'll need to do much better for malleable
110 | approaches to empower the computing experience of people at all experience
111 | levels. I would like to see future work that automates as much possible both:
112 |
113 | * the creation of site adapters for snapshots of a site at a point in time
114 | * the continual maintenance of the adapters over time as sites change
115 |
116 | I am hoping to share some approaches to this in my own research, and I'd like to
117 | see ideas from others in the community as well. I expect it will take a while to
118 | to find the best way to make this work without a lot of manual effort.
119 |
120 | Wildcard is currently implemented as a browser extension, and so it can only
121 | influence web content. That does indeed seem like a natural place to prototype
122 | such a tool, as there is a lot of the list-like content on the web. At the same
123 | time, computing is more than just the web, and so I'd like to see systems that
124 | apply some of these ideas to even more of our computing experience.
125 |
126 | ## Review summary
127 |
128 | Overall, I think Wildcard is an exciting step towards greater user customisation
129 | of existing websites and applications, and it aims towards a number of the
130 | collective's [core principles][principles].
131 |
132 | I have signed up for the [mailing list][list] to try it out and discover more
133 | about how it works in detail.
134 |
135 | [litt]: https://www.geoffreylitt.com/
136 | [jackson]: http://people.csail.mit.edu/dnj/
137 | [wildcard]: https://www.geoffreylitt.com/wildcard/salon2020/
138 | [salon]: https://2020.programming-conference.org/home/salon-2020
139 | [mission-3]: {{< relref "/pages/mission.md#3-open-ended-potential" >}}
140 | [principles]: {{< relref "/pages/mission.md">}}
141 | [list]: https://docs.google.com/forms/d/e/1FAIpQLSf8nJZ5hY0ZTB0g3WmHEpvP-p8keRzWbWRltEidTK8awsfBEw/viewform?usp=sf_link
142 |
--------------------------------------------------------------------------------
/content/catalog/_index.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Catalog
3 | featured_image:
4 | description:
5 | menu: main
6 | weight: 2
7 | ---
8 |
9 | This catalog highlights projects, people, groups, research, discussions, and
10 | other initiatives in the malleable software community. It is our hope that
11 | bringing more awareness to these efforts will lead to greater collaboration and
12 | better systems for us all that support the [essential principles][principles] of
13 | malleability.
14 |
15 | If you know of people, projects, threads, or anything else that should be added,
16 | please [edit the wiki][catalog-wiki] or [send us a note][feedback]. Similarly,
17 | please let us know about anything that should be removed or corrected.
18 |
19 | _Order in the catalog is randomised on each page load._
20 |
21 | [principles]: {{< relref "/pages/mission.md">}}
22 | [catalog-wiki]: https://forum.malleable.systems/c/catalog/7
23 | [feedback]: mailto:hello@malleable.systems
24 |
--------------------------------------------------------------------------------
/content/pages/code-of-conduct.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Code of Conduct
3 | featured_image:
4 | description:
5 | menu: footer
6 | ---
7 |
8 | ## Our Pledge
9 |
10 | We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.
11 |
12 | We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.
13 |
14 | ## Our Standards
15 |
16 | Examples of behavior that contributes to a positive environment for our community include:
17 |
18 | * Demonstrating empathy and kindness toward other people
19 | * Being respectful of differing opinions, viewpoints, and experiences
20 | * Giving and gracefully accepting constructive feedback
21 | * Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
22 | * Focusing on what is best not just for us as individuals, but for the overall community
23 |
24 | Examples of unacceptable behavior include:
25 |
26 | * The use of sexualized language or imagery, and sexual attention or
27 | advances of any kind
28 | * Trolling, insulting or derogatory comments, and personal or political attacks
29 | * Public or private harassment
30 | * Publishing others' private information, such as a physical or email
31 | address, without their explicit permission
32 | * Other conduct which could reasonably be considered inappropriate in a
33 | professional setting
34 |
35 | The three gates of speech are useful as guide: before you speak, let your words pass through three gates:
36 |
37 | * At the first gate, ask yourself, "is it true?"
38 | * At the second gate, ask "is it necessary?"
39 | * At the third gate, ask "is it kind?"
40 |
41 | ## Enforcement Responsibilities
42 |
43 | Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.
44 |
45 | Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.
46 |
47 | ## Scope
48 |
49 | This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
50 |
51 | ## Enforcement
52 |
53 | Instances of abusive, harassing, or otherwise unacceptable behavior may be
54 | reported to the community leaders responsible for enforcement at
55 | [abuse@malleable.systems](mailto:abuse@malleable.systems). All complaints will be reviewed and investigated
56 | promptly and fairly.
57 |
58 | All community leaders are obligated to respect the privacy and security of the reporter of any incident.
59 |
60 | ## Enforcement Guidelines
61 |
62 | Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:
63 |
64 | ### 1. Correction
65 |
66 | **Community Impact**: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community.
67 |
68 | **Consequence**: A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.
69 |
70 | ### 2. Warning
71 |
72 | **Community Impact**: A violation through a single incident or series of actions.
73 |
74 | **Consequence**: A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.
75 |
76 | ### 3. Temporary Ban
77 |
78 | **Community Impact**: A serious violation of community standards, including sustained inappropriate behavior.
79 |
80 | **Consequence**: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.
81 |
82 | ### 4. Permanent Ban
83 |
84 | **Community Impact**: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.
85 |
86 | **Consequence**: A permanent ban from any sort of public interaction within the project community.
87 |
88 | ## Attribution
89 |
90 | This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 2.0,
91 | available at https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.
92 |
93 | Community Impact Guidelines were inspired by [Mozilla's code of conduct enforcement ladder](https://github.com/mozilla/diversity).
94 |
95 | The three gates of speech section is borrowed from Merveilles's [discourse
96 | guide](https://wiki.xxiivv.com/site/discourse.html).
97 |
98 | [homepage]: https://www.contributor-covenant.org
99 |
100 | For answers to common questions about this code of conduct, see the FAQ at
101 | https://www.contributor-covenant.org/faq. Translations are available at
102 | https://www.contributor-covenant.org/translations.
103 |
--------------------------------------------------------------------------------
/content/pages/mission.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Mission
3 | date: 2019-12-26T23:46:42Z
4 | featured_image:
5 | description:
6 | menu: main
7 | weight: 1
8 | toc: true
9 | postscript:
10 | Thanks to Ben Robbins for feedback on earlier drafts.
11 | ---
12 |
13 | ## Community
14 |
15 | The Malleable Systems Collective is a community space that [catalogs][catalog]
16 | and experiments with **malleable software and systems** that reset the balance
17 | of power via several essential principles detailed below.
18 |
19 | For all of these principles, it is not yet clear how to best achieve them, and
20 | there are sure to be many possible solutions with different tradeoffs. We'll
21 | need to experiment as community with various approaches. The collective's
22 | primary goal is to report on such efforts and raise awareness of work in these
23 | directions.
24 |
25 | ## Principles
26 |
27 | ### 1. Easy to change
28 |
29 | _Software must be as easy to change as it is to use it.[^1]_
30 |
31 | We have spent many decades in the worthy pursuit of making computing easier to
32 | use, and many such improvements to the experience of using software do in fact
33 | come to life and improve the computing applications we use everyday.
34 |
35 | By contrast, the process of changing the features and interfaces of most
36 | software is not _just_ difficult: in many modern ecosystems, such as
37 | the app stores of smartphones and increasingly on desktop operating systems as
38 | well, each application is sandboxed and effectively untouchable by you, the
39 | owner of the hardware on which it runs.
40 |
41 | We must empower people to tailor and customise their computing experience to
42 | support their personal workflows in ways which likely will never be
43 | prioritised or even imagined by the original application vendor.
44 |
45 | Some may believe open source applications achieve this, but having the source
46 | available still implies a software engineering toolchain and skill set, which
47 | effectively prohibits most people from making the changes they desire.
48 |
49 | ### 2. Arbitrary recombination and reuse
50 |
51 | _All layers, from the user interface through functionality to the data
52 | within, must support arbitrary recombination and reuse in new environments._
53 |
54 | Some software architectures, such as the plugin APIs that support things like
55 | browser extensions, exist today that allow for some amount of customisation.
56 | However, you are still limited to what the API vendor has imagined someone might
57 | want to customise, which leaves us with a similar dilemma as with most
58 | applications: we must beseech the vendor to support our needs if the plugin API
59 | does not already offer it.
60 |
61 | We argue an even more radical level of customisation is required: it must be
62 | possible to extract arbitrary bits of user interface, logic, and data for
63 | recombination in a new environment. If I want to grab a UI control from one
64 | application, some processing logic from another, and run it all against a data
65 | source from somewhere else again, it should be possible to do so.
66 |
67 | ### 3. Open-ended potential
68 |
69 | _Tools should strive to be easy to begin working with but still have lots of
70 | open-ended potential._
71 |
72 | While we do have systems such as IFTTT and Zapier that simplify snapping
73 | together specific triggers and actions, the possibilities are once again limited
74 | by what each application vendor imagines you might want to do.
75 |
76 | We should instead aim for a wider spectrum of possibilities as we once had with
77 | tools like HyperCard: it was easy to get started by making a few cards and
78 | linking them together, which could be enough for a simple problem. As you
79 | learned more about the system through gradual experience, you could grow into
80 | the scripting system and achieve a much larger set of things which did not have
81 | to be pre-imagined by the creators of the system.
82 |
83 | ### 4. Retain ownership and control
84 |
85 | _People of all experience levels must be able to retain ownership and control._
86 |
87 | A fundamental problem of today's software ecosystem is that we do not own or
88 | control the software that runs on our devices. In addition, much of the actual
89 | processing logic has been passed off to remote systems in the cloud, so only the
90 | inputs and outputs are observable.
91 |
92 | We must ensure that malleable software approaches allow the customisations and
93 | personal workflows you create to be owned and used as you see fit. If an
94 | approach relies on some amount of remote functionality (perhaps to assist with
95 | pulling apart an application or service), we must ensure there's a clear path
96 | for anyone interested to keep those dependencies alive so that their workflows
97 | are not disturbed if the remote service were to shut down.
98 |
99 | This has many parallels with the ongoing movement towards data ownership, which
100 | is gaining popular awareness. Although the data ownership movement typically
101 | focuses on identity and social data, the programs and customisations that
102 | authors create are personal creative expressions. Authors must retain ownership
103 | of their data, programs, and customisations just as anyone would
104 | expect to have control over a book they wrote or art they created.
105 |
106 | ### 5. Freely sharable
107 |
108 | _Recombined workflows and experiences must be freely sharable with others.[^2]_
109 |
110 | Malleable system approaches must allow each author to share their creations as
111 | they see fit. For example, it must be possible to share a workflow you've
112 | created with a curious friend or coworker by using a transmission channel that
113 | does not depend on a centralised service. Similarly, you must have the option of
114 | adding workflows that others have created to your personal tool set.
115 |
116 | We can only consider the works we create on a computer to truly be "ours" if we
117 | can share them in the same ways you share physical tools in a workshop. Digital
118 | workflows have the lucky advantage of being easily copied, but we must ensure we
119 | don't create artificial restrictions that limit what a workflow creator can do
120 | with what they have made.
121 |
122 | ### 6. Modifying in the context of use
123 |
124 | _Modifying a system should happen in the context of use, rather than through
125 | some separate development toolchain and skill set.[^3]_
126 |
127 | In the current ecosystem, it is _possible_ for software experts to achieve
128 | limited change, but to do so, they must use a set of tools and skills that are
129 | completely separate from the application itself. This is far too high of a bar
130 | to make a simple customisation to some tool you use every day.
131 |
132 | Instead, it should be possible to _modify_ a system using interfaces and
133 | techniques that are consistent with _using_ the same system. This allows you to
134 | naturally build on what you already know about the system at hand while tweaking
135 | and extending it.
136 |
137 | ### 7. Thoughtfully crafted
138 |
139 | _Computing should be a thoughtfully crafted, fun, and empowering experience._
140 |
141 | Modern computing is a jungle of arcane, inscrutable tools that throw up walls of
142 | difficult to parse errors that slowly chip away at your enjoyment of the
143 | creative work of building something new. While today much of this is only seen
144 | by software developers, it does sometimes leak through, such as when raw error
145 | messages are displayed.
146 |
147 | If we are to have any hope of giving all people the same power over computers
148 | currently accessible only to experts, we must get rid of these obstacles by
149 | refining our tools so that we can focus more on the actual goal, which should
150 | make computing more fun and accessible to all.
151 |
152 | ## Revolution
153 |
154 | Most contemporary applications fail to meet all of these principles, leaving us
155 | with no pathway towards improvement. The only option is to plead with the app
156 | developer and hope they will deign to grant your request. As the importance of
157 | computing in everyday life grows with each passing year, we must fight for these
158 | values to ensure the power of computing is evenly distributed.
159 |
160 | We hope you agree this is a revolution worth fighting for.
161 |
162 | [catalog]: {{< relref "/catalog/_index.md">}}
163 |
164 | [^1]: This paraphrases [User-tailorable systems: pressing the issues with
165 | buttons](https://dl.acm.org/citation.cfm?doid=97243.97271) (MacLean et al.,
166 | 1990): "it should be as easy to change the environment as it is to use it".
167 | [^2]: This is adapted from [What Lies in the Path of the Revolution]({{< relref
168 | "/catalog/_index.md#revolution" >}}) (Basman and Tchernavskij, 2018) who argue
169 | that "all authors should have the ability to freely contribute their expressions
170 | to the work of others, and freely 'buy into' and 'buy out of' the expressions
171 | of others".
172 | [^3]: This draws on similar themes from the [in-place
173 | toolchain](https://www.inkandswitch.com/end-user-programming.html#in-place-toolchain)
174 | section of [End-user programming]({{< relref "/catalog/_index.md#enduser" >}})
175 | (Ink & Switch, 2019).
176 |
--------------------------------------------------------------------------------
/content/pages/participate.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Participate
3 | featured_image:
4 | description:
5 | menu: main
6 | ---
7 |
8 | We hope the collective's [mission][mission] has inspired you to follow the
9 | community's work, post your thoughts, and share your experiments. There are many
10 | ways to get involved and contribute to this movement.
11 |
12 | ### Discuss
13 |
14 | We have various ways to share and discuss work from the community:
15 |
16 | * Follow and mention the community on [Mastodon][mastodon] and
17 | [Twitter][twitter]
18 | * Join the discussion in our [forum][forum]
19 | * Chat with us in our [Matrix room][matrix]
20 | * Read the community [blog][blog] where we share projects and essays in various
21 | states of completion
22 | * Subscribe to the [newsletter][newsletter] if you prefer to receive the blog
23 | content via email
24 |
25 | The [forum][forum] and [Matrix room][matrix] currently have the most activity,
26 | so we encourage you to give them a try.
27 |
28 | ### Contribute
29 |
30 | We'd like to host several kinds of posts from different voices in the community.
31 | If you'd like to write something, please [get in touch][feedback].
32 |
33 | Some of the types of content we have in mind include:
34 |
35 | * Summaries of papers and projects in the community
36 | * Reports of experiments in progress
37 | * Essays on what malleable software should be and how we can get there
38 |
39 | Along with the blog, we've also started a [catalog][catalog] of projects,
40 | people, discussions, and other efforts in this field. We hope it can grow to
41 | become a comprehensive list of resources for the community.
42 |
43 | For more info on contributing to the collective, please see the [contribution
44 | guide][contribute].
45 |
46 | ### Feedback
47 |
48 | At the end of the day, we want this to be a space for anyone working to advance
49 | the goals of malleable software. If you have thoughts or feedback on how best to
50 | achieve that, please let us know.
51 |
52 | [mission]: {{< relref "/pages/mission.md">}}
53 | [catalog]: {{< relref "/catalog/_index.md">}}
54 | [contribute]: https://github.com/malleable-systems/malleable.systems/blob/main/CONTRIBUTING.md
55 | [feedback]: mailto:hello@malleable.systems
56 | [mastodon]: https://hachyderm.io/@malleablesys
57 | [twitter]: https://twitter.com/malleablesys
58 | [forum]: https://forum.malleable.systems
59 | [matrix]: https://matrix.to/#/#malleable-systems:matrix.org
60 | [blog]: {{< relref "/blog/_index.md" >}}
61 | [newsletter]: https://buttondown.email/malleable-systems
62 |
--------------------------------------------------------------------------------
/data/actors.yaml:
--------------------------------------------------------------------------------
1 | basman:
2 | name: Antranig Basman
3 | affiliation: Raising the Floor - International
4 | avatar: /avatars/basman.jpg
5 | website: https://ponder.org.uk
6 | twitter: amb26ponder
7 | eagan:
8 | name: James R. Eagan
9 | affiliation: Télécom Paris
10 | avatar: /avatars/eagan.jpg
11 | website: https://james.eagan.fr
12 | twitter: dr_eagan
13 | stephenrkell:
14 | name: Stephen Kell
15 | affiliation: King's College London
16 | avatar: /avatars/stephenrkell.jpg
17 | website: https://www.humprog.org/~stephen/
18 | twitter: stephenrkell
19 | cklokmose:
20 | name: Clemens N. Klokmose
21 | affiliation: Aarhus University
22 | avatar: /avatars/cklokmose.jpg
23 | website: https://cs.au.dk/~clemens/
24 | mastodon: https://social.multiverset.net/@clemens
25 | twitter: cklokmose
26 | weiwei:
27 | name: Weiwei Xu
28 | affiliation: California College of the Arts
29 | avatar: /avatars/weiwei.jpg
30 | website: https://weiwei.place
31 | twitter: weiweiwei33
32 | inkandswitch:
33 | name: Ink & Switch
34 | avatar: /avatars/inkandswitch.png
35 | website: https://www.inkandswitch.com
36 | twitter: inkandswitch
37 | geoffreylitt:
38 | name: Geoffrey Litt
39 | affiliation: MIT
40 | avatar: /avatars/geoffreylitt.jpg
41 | website: https://www.geoffreylitt.com
42 | mastodon: https://mastodon.social/@geoffreylitt
43 | twitter: geoffreylitt
44 | yoshikischmitz:
45 | name: Yoshiki Schmitz
46 | avatar: /avatars/yoshikischmitz.jpg
47 | website: https://www.notion.so/About-Me-7543563c194748f4a500d2c164bd3057
48 | twitter: yoshikischmitz
49 | jryans:
50 | name: J. Ryan Stinnett
51 | affiliation: King's College London
52 | avatar: /avatars/jryans.jpg
53 | website: https://convolv.es
54 | mastodon: https://merveilles.town/@jryans
55 | twitter: jryans
56 | ptchernavskij:
57 | name: Philip Tchernavskij
58 | affiliation: Aarhus University
59 | avatar: /avatars/ptchernavskij.jpg
60 | website: https://tcher.tech
61 | twitter: ptchernavskij
62 |
--------------------------------------------------------------------------------
/data/catalog/a-future-of-programming.yaml:
--------------------------------------------------------------------------------
1 | kind: post
2 | authors:
3 | - Stefan Lesser
4 | title: A Future of Programming
5 | year: 2019
6 | location: https://stefan-lesser.com/2019/12/24/a-future-of-programming/
7 | suggesters:
8 | - jryans
9 | curators:
10 | - 7h3kk1d
11 | quotes:
12 | - Enable everyone, especially people from other domains outside programming,
13 | to take advantage of computation. Empower people to build their own systems
14 | and tools, giving them more of the powers that have only been available to
15 | programmers through writing code, so they can augment their own workflows in
16 | their own areas of expertise.
17 | - Blur the line between developers and users. Enable people to modify the
18 | systems and tools they use and adapt them to their needs.
19 |
--------------------------------------------------------------------------------
/data/catalog/a-world-without-apps.yaml:
--------------------------------------------------------------------------------
1 | kind: talk
2 | authors:
3 | - Michel Beaudouin-Lafon
4 | title: A World Without Apps
5 | year: 2019
6 | location: https://www.youtube.com/watch?v=ntaudUum06E
7 | image: https://forum-cdn.malleable.systems/uploads/default/original/1X/3939fdea6aebe6e2316edcab863cf223dd1bc888.jpeg
8 | suggesters:
9 | - jryans
10 | curators:
11 | - jryans
12 | quotes:
13 | - ...with apps today, you are given full, complex software where you don't
14 | have a choice. You have to have all of it or none of it, and you have to
15 | learn it, and you have relearn it at each update, and you have learn a
16 | different version when you shift from one vendor to another. (7:35)
17 | - ...the key idea here is to make tools more generic, general, and independent
18 | of the environment in which they are going to be used. (12:50)
19 | - "I often think about this [Samuel Johnson] quote from my late stepfather's
20 | desk: 'Nothing will ever be attempted if all possible objections must first
21 | be overcome.' (20:51)"
22 | - I also strongly believe that users should have a bit more control over
23 | security and the risks they are willing to take. We learn by doing, we learn
24 | by failing, we learn by doing mistakes, we learn by breaking things. And
25 | sometimes I want a secure environment and sometimes I want to see what
26 | happens if I put my fingers in the plug. (21:17)
27 | - I don't think it is incompatible to have more flexible environments and
28 | security. What I'm advocating for is the ability for people to make choices.
29 | (23:24)
30 | - I do not believe that this type of change will come from the companies that
31 | dominate computing at the moment, in the same way that GUIs didn't come out
32 | of IBM at the time. (30:43)
33 | - My take is not to try to directly address the wider audience, but to try
34 | with niche markets. (31:20)
35 |
--------------------------------------------------------------------------------
/data/catalog/an-app-can-be-a-home-cooked-meal.yaml:
--------------------------------------------------------------------------------
1 | kind: post
2 | authors:
3 | - Robin Sloan
4 | title: An app can be a home-cooked meal
5 | year: 2020
6 | location: https://www.robinsloan.com/notes/home-cooked-app/
7 | suggesters:
8 | - jryans
9 | curators:
10 | - akkartik
11 | additional_resources:
12 | - label: Clay Shirky's Situated Software (2004)
13 | url: https://www.gwern.net/docs/technology/2004-03-30-shirky-situatedsoftware.html
14 | - label: Hillel Wayne's take on Situated Software (2020)
15 | url: https://buttondown.email/hillelwayne/archive/situated-software
16 | quotes:
17 | - I made a messaging app for, and with, my family. It is ruthlessly simple; we
18 | love it; no one else will ever use it.
19 | - In a better world, I would have built this in a day using some kind of
20 | modern, flexible HyperCard for iOS, exporting a sturdy, standalone app that
21 | did exactly what I wanted and nothing else.
22 | - People don’t only learn to cook so they can become chefs. Some do! But far
23 | more people learn to cook so they can eat better, or more affordably, or in
24 | a specific way. Or because they want to carry on a tradition. Sometimes they
25 | learn just because they’re bored! Or even because — get this — they love
26 | spending time with the person who’s teaching them... I will gently suggest
27 | that perhaps coding might be entangled the same way... with our domesticity
28 | and comfort, nerdiness and curiosity, health and love.
29 |
--------------------------------------------------------------------------------
/data/catalog/armories-for-tool-maker-tool-user-collaborations.yaml:
--------------------------------------------------------------------------------
1 | kind: post
2 | authors:
3 | - Andy Matuschak
4 | title: Armories for tool-maker/tool-user collaborations
5 | year: 2021
6 | location: https://www.patreon.com/posts/armories-for-52549432
7 | description: Describes a deeper, more intense 2-person alternative to ecologies
8 | for tailorable software (summarized in Philip Tchernavskij's [Designing and
9 | Programming Malleable
10 | Software](#designing-and-programming-malleable-software).
11 | suggesters:
12 | - jryans
13 | curators:
14 | - akkartik
15 | quotes:
16 | - Great tools for thought rarely come from contexts focused on creating tools.
17 | They’re usually created in the course of deep creative work in some domain,
18 | almost as a byproduct. And they’re usually made by people with significant
19 | expertise and investment in those creative problems.
20 | - "In most domains, great tool-makers are rarely great tool-users, and
21 | vice-versa. There might be advantages to separating the work: the tool-maker
22 | could constantly consider abstraction and generalization, and the tool-user
23 | could focus on meaningful problems at hand without being distracted by
24 | issues of systematization."
25 | - There’s a tricky chicken-and-egg problem here. If great creative work should
26 | drive the invention of new mediums, how can the initial idea driving the
27 | creative work get started in the first place?
28 | - The pair must proactively develop an _armory_ of tool ideas to equip the
29 | tool-user’s explorations. Tool ideas in the armory don’t have to be working
30 | software. They just have to be understood well enough that the tool-user can
31 | tinker with them in emerging creative projects.
32 | - This conception is mostly useful in the context of repeated collaborations,
33 | particularly across distinct projects.
34 |
--------------------------------------------------------------------------------
/data/catalog/beta-programming-language.yaml:
--------------------------------------------------------------------------------
1 | kind: tool
2 | authors:
3 | - Kristen Nygaard
4 | title: BETA (programming language)
5 | year: 1993
6 | location: https://beta.cs.au.dk/
7 | description: Kristen Nygaard, the author of the first object-oriented language
8 | (SIMULA), went on to develop an interesting early OOP language called BETA.
9 | suggesters:
10 | - natecull
11 | curators:
12 | - natecull
13 | additional_resources:
14 | - label: Wikipedia
15 | url: https://en.wikipedia.org/wiki/BETA_(programming_language)
16 | - label: HOPL paper (2007)
17 | url: https://web.archive.org/web/20170808220531id_/https://users-cs.au.dk/olm/index.html/PUB/BETA-HOPL-V4.7_ref.pdf
18 | quotes:
19 | - "This paper tells the story of the development of BETA: a programming
20 | language with just one abstraction mechanism, instead of one abstraction
21 | mechanism for each kind of program element (classes, types, procedures,
22 | functions, etc.). The paper explains how this single abstraction mechanism,
23 | the pattern, came about and how it was designed to be so powerful that it
24 | covered the other mechanisms."
25 | - The BETA project was started in 1976 and was originally supposed to be
26 | completed in a year or two. For many reasons, it evolved into an almost
27 | lifelong activity involving Nygaard, the authors of this paper and many
28 | others. The BETA project became an endeavor for discussing issues related to
29 | programming languages, programming and informatics in general.
30 |
--------------------------------------------------------------------------------
/data/catalog/boxer-a-reconstructible-computational-medium.yaml:
--------------------------------------------------------------------------------
1 | kind: paper
2 | authors:
3 | - Andrea A. diSessa
4 | - Harold Abelson
5 | title: "Boxer: a reconstructible computational medium"
6 | year: 1986
7 | location: https://dl.acm.org/doi/abs/10.1145/6592.6595
8 | image: https://forum-cdn.malleable.systems/uploads/default/optimized/1X/f4e35bb7c66e1b767c78c65f06545079666a8599_2_540x499.png
9 | suggesters:
10 | - geoffreylitt
11 | - cklokmose
12 | curators:
13 | - jryans
14 | quotes:
15 | - One major benefit of programmability is that even professionally produced
16 | items become changeable, adaptable, fragmentable, and quotable in ways that
17 | present software is not.
18 | - ... a reconstructible medium should allow people to build personalized
19 | computational tools and easily modify tools they have gotten from others.
20 | This concept is in strong contrast to the current situation in applications
21 | software — professionals are designing tools only for large populations with
22 | a common need.
23 | - Boxer challenges, in a small way, the current view of programming languages.
24 | More significantly, it challenges the current view of what programming might
25 | be like, and for whom and for what purposes programming languages should be
26 | created. We have argued that some computer languages should be designed for
27 | laypeople, and have presented an image of how computation could be used as
28 | the basis for a popular, expressive, and reconstructible medium. Computers
29 | will become substantially more powerful instruments of educational and
30 | social change to the extent that such an image can be realized.
31 |
--------------------------------------------------------------------------------
/data/catalog/bring-your-own-client.yaml:
--------------------------------------------------------------------------------
1 | kind: post
2 | authors:
3 | - geoffreylitt
4 | title: Bring Your Own Client
5 | year: 2021
6 | location: https://www.geoffreylitt.com/2021/03/05/bring-your-own-client.html
7 | suggesters:
8 | - karlicoss
9 | - 7h3kk1d
10 | - jryans
11 | curators:
12 | - jryans
13 | quotes:
14 | - Today we generally think about BYOC at the "app" level. But can we go
15 | finer-grained than that, picking individual interface elements? Instead of
16 | needing to pick a single email client, can I compose my favorite email
17 | client out of an inbox, a compose window, and a spam filter?
18 |
--------------------------------------------------------------------------------
/data/catalog/browser-extensions-are-underrated-the-promise-of-hackable-software.yaml:
--------------------------------------------------------------------------------
1 | kind: post
2 | authors:
3 | - geoffreylitt
4 | title: "Browser extensions are underrated: the promise of hackable software"
5 | year: 2019
6 | location: https://www.geoffreylitt.com/2019/07/29/browser-extensions.html
7 | suggesters:
8 | - jryans
9 | curators:
10 | - jryans
11 | quotes:
12 | - Among major software platforms today, browser extensions are the rare
13 | exception that allow and encourage users to modify the apps that we use, in
14 | creative ways not intended by their original developers. On smartphone and
15 | desktop platforms, this sort of behavior ranges from unusual to impossible,
16 | but in the browser it’s an everyday activity.
17 | - Since the beginning of personal computing, there’s been a philosophical
18 | tradition that encourages using computers as an interactive medium where
19 | people contribute their own ideas and build their own tools—authorship over
20 | consumption.
21 |
--------------------------------------------------------------------------------
/data/catalog/brutalist-html-quine.yaml:
--------------------------------------------------------------------------------
1 | kind: idea
2 | authors:
3 | - Leon Bambrick
4 | title: Brutalist HTML quine
5 | year: 2019
6 | location: https://secretgeek.github.io/html_wysiwyg/html.html
7 | description: "This technique uses CSS magic to expose the full tag structure
8 | underlying the page. "
9 | suggesters:
10 | - cben
11 | curators:
12 | - cben
13 | quotes:
14 | - >-
15 | `
`Another common theme in Brutalist designs is the exposure of the building's functions.`
`
20 |
21 | `
`...the tendency to **``make the internal external``**, and reveal the secrets of the building, in a somehow.... *``brutaful``* way. ;-).`
`
22 |
--------------------------------------------------------------------------------
/data/catalog/convivial-design-heuristics-for-software-systems.yaml:
--------------------------------------------------------------------------------
1 | kind: paper
2 | authors:
3 | - stephenrkell
4 | title: Convivial Design Heuristics for Software Systems
5 | year: 2020
6 | location: https://www.humprog.org/~stephen/research/papers/kell20convivial.pdf
7 | suggesters:
8 | - jryans
9 | curators:
10 | - jryans
11 | quotes:
12 | - Consider how many web applications contain their own embedded 'rich text'
13 | editing widget. If linking were truly at the heart of the web’s design, a
14 | user (not just a developer) could supply their own preferred editor easily,
15 | but such a feat is almost always impossible. A convivial system should not
16 | contain multitudes; it should permit linking to them.
17 | - "The battle for convivial software in this sense appears similar to other
18 | modern struggles, such as the battle to avert climate disaster. Relying on
19 | local, individual rationality alone is a losing game: humans lack the
20 | collective consciousness that collective rationality would imply, and much
21 | human activity happens as the default result of 'normal behaviour'. To shift
22 | this means to shift what is normal. Local incentives will play their part,
23 | but social doctrines, whether relatively transactional notions such as
24 | intergenerational contract, or quasi-spiritual notions of our evolved bond
25 | with the planet, also seem essential if there is to be hope of steering
26 | humans away from collective destruction."
27 |
--------------------------------------------------------------------------------
/data/catalog/crochet.yaml:
--------------------------------------------------------------------------------
1 | kind: tool
2 | authors:
3 | - Q
4 | title: Crochet
5 | years:
6 | - 2021
7 | - present
8 | location: https://crochet.qteati.me/
9 | description: Crochet is a tool for creating and remixing interactive stories, safely.
10 | suggesters:
11 | - jryans
12 | - 7h3kk1d
13 | curators:
14 | - 7h3kk1d
15 | additional_resources:
16 | - label: What's Crochet
17 | url: https://crochet.qteati.me/docs/reference/system/whats-crochet.html
18 | description: A general description of the Crochet programming system
19 | - label: Design Philosophy
20 | url: https://crochet.qteati.me/docs/reference/system/design-philosophy.html
21 | description: Principles that guide Crochet
22 | quotes:
23 | - Crochet goes to great lengths to make creating, running and remixing content
24 | as safe and privacy respecting as possible. Content built with Crochet can
25 | only use your computer and your data in ways you explicitly consent to---it
26 | can't change your files or send your information over the internet without
27 | your knowledge and consent.
28 | - 'One of the core principles of Crochet is that you should feel safe to
29 | experiment with your computer as much as you want, without having to worry
30 | about questions like: "If I install this application, will it try to steal
31 | my files?" or "What if I try this and it breaks my computer?"'
32 | - Crochet is a "language-driven" system, through the lenses that we interact
33 | with computational concepts through languages; Even "direct manipulation"
34 | forms a language, where the ways in which we can manipulate things is
35 | dictated by a set of composable rules. A system like this, heavily dependent
36 | on tooling, needs ways in which users can extend the system to fit their own
37 | context. This means that Crochet has to support user-extensible IDEs,
38 | user-extensible Debuggers, user-extensible REPLs, etc. And these users
39 | should be able to modify any aspect of these tools to fit new languages
40 | (interactions, manipulations, rules, etc).
41 |
--------------------------------------------------------------------------------
/data/catalog/decker.yaml:
--------------------------------------------------------------------------------
1 | kind: tool
2 | authors:
3 | - John Earnest
4 | title: Decker
5 | years:
6 | - 2022
7 | - present
8 | location: https://beyondloom.com/decker/
9 | description: A multimedia platform for creating and sharing interactive
10 | documents, with sound, images, hypertext, and scripted behavior.
11 | image: https://forum-cdn.malleable.systems/uploads/default/original/1X/a464a823974d0aa05d948693912a4825cc02a47d.gif
12 | suggesters:
13 | - johnearnest
14 | curators:
15 | - johnearnest
16 | additional_resources:
17 | - label: Github Repository
18 | url: https://github.com/JohnEarnest/Decker
19 | - label: Decker Community Forum
20 | url: https://internet-janitor.itch.io/decker/community
21 | quotes:
22 | - Decker builds on the legacy of
23 | [HyperCard](https://en.wikipedia.org/wiki/HyperCard) and the visual
24 | aesthetic of classic macOS. It retains the simplicity and ease of learning
25 | that HyperCard provided, while adding many subtle and overt quality-of-life
26 | improvements, like deep undo history, support for scroll wheels and
27 | touchscreens, more modern keyboard navigation, and bulk editing operations.
28 | - Anyone can use Decker to create E-Zines, organize their notes, give
29 | presentations, build adventure games, or even just doodle some 1-bit pixel
30 | art. The holistic "ditherpunk" aesthetic is cozy, a bit nostalgic, and
31 | provides fun and distinctive creative constraints. As a prototyping tool,
32 | Decker encourages embracing a sketchy, imperfect approach. Finished decks
33 | can be saved as standalone .html documents which self-execute in a web
34 | browser and can be shared anywhere you can host or embed a web page. Decker
35 | also runs natively on macOS, Windows, and Linux.
36 |
--------------------------------------------------------------------------------
/data/catalog/designing-and-programming-malleable-software.yaml:
--------------------------------------------------------------------------------
1 | kind: thesis
2 | authors:
3 | - ptchernavskij
4 | title: Designing and Programming Malleable Software
5 | year: 2019
6 | location: https://theses.hal.science/tel-02612943/
7 | suggesters:
8 | - jryans
9 | curators:
10 | - jryans
11 | quotes:
12 | - The contemporary landscape of interactive software operates as a
13 | "designer-knows-best" model that gives users very few opportunities to
14 | change their software or to make different pieces of software work together
15 | as they see fit.
16 | - I introduce malleable software as a design vision that reconstructs the
17 | goals of tailorable systems with pluralism as a guiding value. Malleable
18 | software is made up of interface elements untangled from the closed worlds
19 | of apps, which can be developed by different authors and (re-)combined by
20 | end users.
21 |
--------------------------------------------------------------------------------
/data/catalog/dynamicland.yaml:
--------------------------------------------------------------------------------
1 | kind: tool
2 | authors:
3 | - Bret Victor
4 | - Josh Horowitz
5 | - Luke Iannini
6 | - Toby Schachman
7 | - Paula Te
8 | - Virginia McArthur
9 | title: Dynamicland
10 | years:
11 | - 2017
12 | - present
13 | location: https://dynamicland.org/
14 | suggesters:
15 | - geoffreylitt
16 | curators:
17 | - jryans
18 | quotes:
19 | - Dynamicland is a communal computer, designed for agency, not apps, where
20 | people can think like whole humans.
21 | - No normal person sees an app and thinks 'I can make that myself.' Or even 'I
22 | can modify that to do what I actually need.' Computational media in
23 | Dynamicland feels like stuff anyone can make. ... A humane dynamic medium
24 | gently leads people down a path from playing, to crafting, to remixing, to
25 | programming.
26 | - Dynamicland is an authoring environment, and everyone is an author. People
27 | make what they need for themselves. They learn through immersion. The true
28 | power of the dynamic medium — programmability — is for everyone.
29 |
--------------------------------------------------------------------------------
/data/catalog/encoding-for-robust-immutable-storage-eris.yaml:
--------------------------------------------------------------------------------
1 | kind: tool
2 | authors:
3 | - Endo Renberg
4 | title: Encoding for Robust Immutable Storage (ERIS)
5 | year: 2022
6 | location: http://eris.codeberg.page
7 | suggesters: []
8 | curators:
9 | - emery
10 | quotes:
11 | - ERIS is an encoding of arbitrary content into a set of uniformly sized,
12 | encrypted and content-addressed blocks as well as a short identifier that
13 | can be encoded as an URN. The content can be reassembled from the blocks
14 | only with this identifier. The encoding is defined independent of any
15 | storage and transport layer or any specific application.
16 |
--------------------------------------------------------------------------------
/data/catalog/end-user-programming.yaml:
--------------------------------------------------------------------------------
1 | kind: paper
2 | authors:
3 | - inkandswitch
4 | title: End-user programming
5 | year: 2019
6 | location: https://www.inkandswitch.com/end-user-programming.html
7 | suggesters:
8 | - jryans
9 | curators:
10 | - jryans
11 | quotes:
12 | - Desktop programs, web apps, and smartphone apps are to various degrees like
13 | appliances with a hermetic seal to keep users out of their interior. If
14 | there is not already a button for a given function, the only option for
15 | users is to petition the developer.
16 | - There shouldn’t be a chasm that the user has to cross in order to customize
17 | the behavior of their software. Going from using to inspecting to modifying
18 | the system should be a gradual process where each of the steps is small
19 | enough to be easily discoverable. The user should not need to switch to
20 | “programmer mindset” but instead stay within the context of the application.
21 | They can stay close to their work and their ideas.
22 |
--------------------------------------------------------------------------------
/data/catalog/folk-computer.yaml:
--------------------------------------------------------------------------------
1 | kind: tool
2 | authors:
3 | - Omar Rizwan
4 | - collaborators
5 | title: folk.computer
6 | years:
7 | - 2023
8 | - present
9 | location: https://folk.computer
10 | description: "Folk is a physical computing system: reactive database,
11 | programming environment, projection mapping. Instead of a
12 | phone/laptop/touchscreen/mouse/keyboard, your computational objects are
13 | physical objects in the real world, and you can program them inside the system
14 | itself. Folk is [written in a mix of C and
15 | Tcl](https://github.com/FolkComputer/folk/blob/main/docs/design.md)."
16 | suggesters:
17 | - apostolis
18 | curators: []
19 | additional_resources:
20 | - label: Examples
21 | url: https://folk.computer/notes/tableshots
22 |
--------------------------------------------------------------------------------
/data/catalog/glamorous-toolkit.yaml:
--------------------------------------------------------------------------------
1 | kind: tool
2 | authors:
3 | - "[feenk](https://feenk.com/)"
4 | title: Glamorous Toolkit
5 | years:
6 | - 2017
7 | - present
8 | location: https://gtoolkit.com/
9 | description: A development environment built on top of
10 | [Pharo](https://pharo.org/), a modern successor of [Smalltalk](#smalltalk).
11 | image: https://forum-cdn.malleable.systems/uploads/default/optimized/1X/aed4cc46e8e19bf54fa6b87b7f0d180a09fd0a1c_2_690x423.png
12 | suggesters:
13 | - jryans
14 | curators:
15 | - jryans
16 | quotes:
17 | - Glamorous Toolkit is the moldable development environment. It is a live
18 | notebook. It is a flexible search interface. It is a fancy code editor. It
19 | is a software analysis platform. It is a data visualization engine. All in
20 | one. And it is free and open-source under an MIT license.
21 | - We want the environment to fit the context of the current system and when it
22 | does not, we want to be able to mold it live. This seemingly small change is
23 | transformational and can be utilized in many ways.
24 | - Whatever is shown on the screen is rendered in one single rendering tree. No
25 | canvas in between. That means that all layouts are regular layouts,
26 | including the graph layouts and text-editor layouts. That means that text is
27 | made of regular elements. And that means that all elements can be combinable
28 | without imposing a technical limit.
29 |
--------------------------------------------------------------------------------
/data/catalog/gnu-emacs.yaml:
--------------------------------------------------------------------------------
1 | kind: tool
2 | authors:
3 | - Richard Stallman
4 | - "[contributors](https://www.gnu.org/software/emacs/manual/html_node/emacs/A\
5 | cknowledgments.html)"
6 | title: GNU Emacs
7 | years:
8 | - 1976
9 | - present
10 | location: https://www.gnu.org/software/emacs/
11 | image: https://forum-cdn.malleable.systems/uploads/default/optimized/1X/1844f611adf303cdf3539cffc3866f277ca79c3f_2_690x472.png
12 | suggesters:
13 | - khinsen
14 | curators:
15 | - khinsen
16 | quotes:
17 | - Extensible means that you can go beyond simple customization and create
18 | entirely new commands. New commands are simply programs written in the Lisp
19 | language, which are run by Emacs's own Lisp interpreter. Existing commands
20 | can even be redefined in the middle of an editing session, without having to
21 | restart Emacs. Most of the editing commands in Emacs are written in Lisp;
22 | the few exceptions could have been written in Lisp but use C instead for
23 | efficiency. — _[GNU Emacs manual,
24 | Introduction](https://www.gnu.org/software/emacs/manual/html_node/emacs/Intro.html#Intro)_
25 | - Org can be used as a TODO lists manager and as a planner. Org is a great
26 | plain-text table editor. Org is an authoring and publication tool. Org makes
27 | literate programming a handy and natural way to deal with code. — _[Org mode
28 | feature list](https://orgmode.org/features.html)_
29 | - This appendix covers some areas where users can extend the functionality of
30 | Org. — _[Org mode manual, Appendix A
31 | Hacking](https://www.gnu.org/software/emacs/manual/html_mono/org.html#Hacking)_
32 |
--------------------------------------------------------------------------------
/data/catalog/hypercard.yaml:
--------------------------------------------------------------------------------
1 | kind: tool
2 | authors:
3 | - Bill Atkinson
4 | - Dan Winkler
5 | - HyperCard team at Apple
6 | title: HyperCard
7 | years:
8 | - 1987
9 | - 2004
10 | location: https://en.wikipedia.org/wiki/HyperCard
11 | image: https://forum-cdn.malleable.systems/uploads/default/original/1X/aa5ecaa11bd8384e3228cad9da677661cf0063d1.png
12 | suggesters:
13 | - geoffreylitt
14 | - jryans
15 | curators:
16 | - jryans
17 | quotes:
18 | - HyperCard is a software erector set that lets non-programmers put together
19 | interactive information — _Bill Atkinson, [Computer
20 | Chronicles](https://archive.org/details/CC501_hypercard) (1987)_
21 | - HyperCard's biggest win was a very low entry threshold for those who wanted
22 | to build their own 'stacks' - combinations of user interface, code, and
23 | persistent data. There were plenty of examples to suggest ideas, and all the
24 | code was open for tweaking. — _Tim Oren, [A Eulogy for
25 | HyperCard](https://due-diligence.typepad.com/blog/2004/03/a_eulogy_for_hy.html)
26 | (2004)_
27 |
--------------------------------------------------------------------------------
/data/catalog/liballocs.yaml:
--------------------------------------------------------------------------------
1 | kind: library
2 | authors:
3 | - name: stephenrkell
4 | type: owner
5 | - name: jryans
6 | type: contributor
7 | title: liballocs
8 | years:
9 | - 2011
10 | - present
11 | location: https://github.com/stephenrkell/liballocs
12 | description: Meta-level run-time services for Unix processes... a.k.a. dragging
13 | Unix into the 1980s
14 | suggesters:
15 | - jryans
16 | curators:
17 | - jryans
18 | quotes:
19 | - Unix abstractions are fairly simple and fairly general, but they are not
20 | humane, and they invite fragmentation. By 'not humane', I mean that they are
21 | error-prone and difficult to experiment with interactively. By
22 | 'fragmentation', I mean they invite building higher-level abstractions in
23 | mutually opaque and incompatible ways (think language VMs, file formats,
24 | middlewares...). To avoid these, liballocs is a minimal extension of
25 | Unix-like abstractions broadly in the spirit of Smalltalk-style dynamism,
26 | designed to counter both of these problems.
27 |
--------------------------------------------------------------------------------
/data/catalog/lopecode-self-editing-humanely-embeddable-observable-notebooks.yaml:
--------------------------------------------------------------------------------
1 | kind: tool
2 | authors:
3 | - Tom Larkworthy
4 | title: "Lopecode: Self-editing, humanely embeddable Observable notebooks"
5 | year: 2025
6 | location: https://tomlarkworthy.github.io/lopecode/webpage.html
7 | description: Announced by Chris Shank in this [Bluesky
8 | posting](https://bsky.app/profile/chrisshank.com/post/3llmhyr33q22x)
9 | suggesters:
10 | - Bosmon
11 | curators:
12 | - Bosmon
13 | additional_resources:
14 | - label: Hacking Observable Notebooks from the Inside (2025)
15 | url: https://www.hytradboi.com/2025/5fc19c84-9ad9-49b5-9433-9f83b68a495b-hacking-observable-notebooks-from-within
16 | quotes:
17 | - The hermetic, self-hosted, self-sustainable, recursively exportable,
18 | offline-first, file-first, web-based reactive open-source programming
19 | substrate built on observable runtime is online finally!
20 | - The editing experience is not there yet. Probably wiser to fork the
21 | [original
22 | Observable](https://observablehq.com/@tomlarkworthy/moldable-webpage)
23 | notebook if you seriously want to create a webpage.
24 |
--------------------------------------------------------------------------------
/data/catalog/mcculloch-pitts-neural-nets.yaml:
--------------------------------------------------------------------------------
1 | kind: post
2 | authors:
3 | - Devine Lu Linvega
4 | title: McCulloch-Pitts Neural Nets
5 | year: 2025
6 | location: https://wiki.xxiivv.com/site/neural_nets.html
7 | description: In exploring parallel rewriting systems, I stumbled onto something
8 | like neural networks and it pushed me to dive deeper into the topic and
9 | learning how they worked. I was surprised how capable this nice little OISC
10 | was. I implemented a textual graph representation language and runtime in
11 | about [150 lines of C89](https://wiki.xxiivv.com/etc/neur.c.txt), or about
12 | [300 lines of Uxn](https://wiki.xxiivv.com/etc/neur.tal.txt). I think this is
13 | relevant to the Malleable community due to it being a symbolic system which is
14 | popular with malleable systems, as well as people exploring portable and
15 | parallel computation models.
16 | image: https://wiki.xxiivv.com/media/refs/neuron.png
17 | suggesters:
18 | - neauoire
19 | curators:
20 | - neauoire
21 |
--------------------------------------------------------------------------------
/data/catalog/micro-prolog.yaml:
--------------------------------------------------------------------------------
1 | kind: tool
2 | authors:
3 | - Sinclair Research
4 | title: Micro-PROLOG
5 | year: 1983
6 | location: https://worldofspectrum.net/item/0008429/
7 | description: A Prolog implementation for the 48K Sinclair ZX Spectrum, with no
8 | disk drive and only cassette tape for storage, in 1983.
9 | image: https://forum-cdn.malleable.systems/uploads/default/optimized/1X/068c448bd0757d79335832ae6437f52d30347a2b_2_350x500.jpeg
10 | suggesters:
11 | - natecull
12 | curators:
13 | - natecull
14 | additional_resources:
15 | - label: Spectrum Computing database entry
16 | url: https://spectrumcomputing.co.uk/entry/8429/ZX-Spectrum/Micro-PROLOG
17 | - label: Disassembled code
18 | url: https://github.com/oldcompcz/micro-PROLOG
19 | - label: Introduction to Micro-PROLOG
20 | url: https://worldofspectrum.org/pub/sinclair/games-info/m/Micro-PROLOG.pdf
21 | - label: Micro-PROLOG Primer
22 | url: https://worldofspectrum.org/pub/sinclair/games-info/m/Micro-PROLOGPrimer.pdf
23 |
--------------------------------------------------------------------------------
/data/catalog/milliforth-forth-in-380-bytes-on-x86.yaml:
--------------------------------------------------------------------------------
1 | kind: tool
2 | authors:
3 | - fuzzballcat
4 | title: "milliForth: Forth in 380 bytes (on x86)"
5 | year: 2023
6 | location: https://github.com/fuzzballcat/milliForth
7 | suggesters:
8 | - natecull
9 | curators:
10 | - natecull
11 | - akkartik
12 | additional_resources:
13 | - label: Hacker News discussion
14 | url: https://news.ycombinator.com/item?id=38158309
15 | quotes:
16 | - A FORTH in 336 bytes — the smallest real programming language ever, as of
17 | yet.
18 |
--------------------------------------------------------------------------------
/data/catalog/myths-and-mythconceptions-what-does-it-mean-to-be-a-programming-language-anyhow.yaml:
--------------------------------------------------------------------------------
1 | kind: paper
2 | authors:
3 | - Mary Shaw
4 | title: "Myths and mythconceptions: What does it mean to be a programming
5 | language, anyhow?"
6 | year: 2022
7 | location: https://dl.acm.org/doi/10.1145/3480947
8 | suggesters:
9 | - jryans
10 | - khinsen
11 | curators:
12 | - jryans
13 | quotes:
14 | - The steep learning curve for these languages is a barrier to entry for many
15 | people. Part of the reward for this effort is an associated mystique about
16 | having mastered the special knowledge.
17 | - As computation has become pervasive, more and more people who are not
18 | professionally trained as programmers are creating and tailoring software as
19 | a means to achieve goals of their own. These vernacular software developers
20 | are principally interested in their own tasks, not in the software as a
21 | primary objective.
22 | - Many *vernacular software developers* are highly trained in their own
23 | domains and only lightly trained in traditional programming. They use a
24 | variety of tools and notations including spreadsheets, scripting, data
25 | schemas, markups, domain-specific languages, visual web development tools,
26 | and scientific libraries.
27 | - Without adequate specifications for the components, there’s no way to reason
28 | formally about the result. When owners of components can change them without
29 | notice, users have no assurances. As a result, formal verification is, on
30 | the whole, a minor player for real software.
31 |
--------------------------------------------------------------------------------
/data/catalog/nova-multiset-rewriting-language.yaml:
--------------------------------------------------------------------------------
1 | kind: tool
2 | authors:
3 | - Wryl
4 | title: "Nova: Multiset Rewriting Language"
5 | year: 2024
6 | location: https://nova-lang.net/
7 | description: Nova is a rewriting language with a very simple core that holds a
8 | fantastically comfy UX to program in, to extend, to communicate with over a
9 | wire, take dynamic notes in, etc.
10 | suggesters:
11 | - neauoire
12 | curators:
13 | - neauoire
14 | additional_resources:
15 | - label: Handmade Seattle talk (2024)
16 | url: https://www.youtube.com/live/OfnEfFb8yks?si=ym_7hTF6UU0KzJAe&t=6315
17 |
--------------------------------------------------------------------------------
/data/catalog/pad-a-zooming-graphical-interface-for-exploring-alternate-interface-physics.yaml:
--------------------------------------------------------------------------------
1 | kind: paper
2 | authors:
3 | - Benjamin B. Bederson
4 | - James D. Hollan
5 | title: "Pad++: a zooming graphical interface for exploring alternate interface
6 | physics"
7 | year: 1994
8 | location: https://www.cs.umd.edu/hcil/pad%2B%2B/papers/uist-94-pad/uist-94-pad.pdf
9 | description: A zoomable graphical sketchpad. Documentation and more information
10 | can be found [here](https://www.cs.umd.edu/hcil/pad++/).
11 | suggesters:
12 | - cklokmose
13 | curators:
14 | - 7h3kk1d
15 | quotes:
16 | - ... Pad++, an infinite resolution sketchpad that we are exploring as an
17 | alternative to traditional window and icon-based approaches to interface
18 | design.
19 | - There are numerous benefits to metaphor-based approaches, but they also lead
20 | designers to employ computation primarily to mimic mechanisms of older
21 | media. While there are important cognitive, cultural, and engineering
22 | reasons to exploit earlier successful representations, this approach has the
23 | potential of underutilizing the mechanisms of new media.
24 | - We envision a much richer world of dynamic persistent informational entities
25 | that operate according to multiple physics specifically designed to provide
26 | cognitively facile access. The physics need to be designed to exploit
27 | semantic relationships explicit and implicit in information-intensive tasks
28 | and in our interaction with these new kinds of computationally-based work
29 | materials.
30 |
--------------------------------------------------------------------------------
/data/catalog/pinocchioverse.yaml:
--------------------------------------------------------------------------------
1 | kind: idea
2 | authors:
3 | - Jan Niklas Bingemann
4 | title: Pinocchioverse
5 | year: 2023
6 | location: https://pinocchioverse.org/
7 | suggesters:
8 | - neauoire
9 | curators:
10 | - neauoire
11 | - akkartik
12 | quotes:
13 | - Pinocchioverse is a fictional, educational programming language based on the
14 | idea of coding with marbles. It is defined by a fictional universe, in
15 | which, due to the natural laws of the universe, programs can be “built” with
16 | marble runs.
17 |
--------------------------------------------------------------------------------
/data/catalog/sliding-blocks-computing.yaml:
--------------------------------------------------------------------------------
1 | kind: paper
2 | authors:
3 | - Robert A. Hearn
4 | title: Sliding Blocks Computing
5 | year: 2003
6 | location: https://groups.csail.mit.edu/mac/users/bob/sliding-blocks.pdf
7 | image: https://forum-cdn.malleable.systems/uploads/default/original/1X/7763a5312ae68362a5e4ea33d70404832140f25a.png
8 | suggesters: []
9 | curators: []
10 | quotes:
11 | - Consider the AND mini-puzzle. Suppose the goal is to slide the upper
12 | protruding block into the box? The answer is that first the left block and
13 | the bottom block must both be slid out one unit. This will let the internal
14 | blocks slide to free up space for the upper block to slide in.
15 |
--------------------------------------------------------------------------------
/data/catalog/smallscript-a-smalltalk-inspired-scripting-language.yaml:
--------------------------------------------------------------------------------
1 | kind: post
2 | authors:
3 | - Łukasz Bownik
4 | title: "Smallscript: A Smalltalk-inspired Scripting Language"
5 | year: 2024
6 | location: https://www.codeproject.com/Articles/5373567/Smallscript-A-Smalltalk-Inspired-Scripting-Language
7 | description: The interesting feature of Smallscript is the set of slight changes
8 | and modernizations it makes to classic Smalltalk syntax.
9 | suggesters:
10 | - natecull
11 | curators:
12 | - natecull
13 |
--------------------------------------------------------------------------------
/data/catalog/smalltalk.yaml:
--------------------------------------------------------------------------------
1 | kind: tool
2 | authors:
3 | - Alan Kay
4 | - Dan Ingalls
5 | - Adele Goldberg
6 | - Learning Research Group of Xerox PARC
7 | title: Smalltalk
8 | years:
9 | - 1972
10 | - present
11 | location: https://en.wikipedia.org/wiki/Smalltalk
12 | description: A programming language and in-context development environment with
13 | powerful built-in tools like a class browser, object inspector, and debugger.
14 | suggesters:
15 | - geoffreylitt
16 | - jryans
17 | curators:
18 | - jryans
19 | quotes:
20 | - The message is the most fundamental language construct in Smalltalk. Even
21 | control structures are implemented as message sends. —
22 | [Wikipedia](https://en.wikipedia.org/wiki/Smalltalk)
23 | - "The late-bound, message-based interfaces of objects provide strong
24 | interposability properties: clients remain oblivious of the specific
25 | implementation they are talking to. In turn, this simplifies the
26 | customisation, extension or replacement of parts of a system, all of which
27 | can be rendered as interposition of a different object on the same client. —
28 | _Stephen Kell, [The operating system: should there be
29 | one?](https://www.cs.kent.ac.uk/people/staff/srk21/research/papers/kell13op\
30 | erating.pdf) (2013)_"
31 |
--------------------------------------------------------------------------------
/data/catalog/software-as-a-place.yaml:
--------------------------------------------------------------------------------
1 | kind: tweet
2 | authors:
3 | - yoshikischmitz
4 | title: Software as a "place"
5 | year: 2019
6 | location: https://twitter.com/yoshikischmitz/status/1208625526966902784
7 | suggesters:
8 | - jryans
9 | curators:
10 | - jryans
11 | quotes:
12 | - 'What makes a piece of software a "place" vs a "tool" or an "appliance"? ...
13 | I think some notion of **limitlessness and nesting** are necessary. [The
14 | feeling of a "place"] seems to come from some kind of limitlessness: Notion
15 | has infinite hierarchies, Figma has an infinite canvas. ... This definition
16 | matters to me because appliances are static, but places can be occupied and
17 | changed. You can have memories and experiences in them. Things can grow in
18 | them. New stuff can emerge. Communities can form. I want more software to be
19 | like that.'
20 |
--------------------------------------------------------------------------------
/data/catalog/syntropize-an-operating-environment-for-malleable-software.yaml:
--------------------------------------------------------------------------------
1 | kind: tool
2 | authors:
3 | - Rahul Gupta
4 | title: "Syntropize: An Operating Environment for Malleable Software"
5 | years:
6 | - 2022
7 | - present
8 | location: https://syntropize.com
9 | description: Syntropize is a proposal for a malleable software operating
10 | environment, an attempt to reclaim the original vision of personal computing
11 | as the means to augment human intellect.
12 | suggesters: []
13 | curators:
14 | - cxres
15 | additional_resources:
16 | - label: Documentation
17 | url: https://syntropize.com/docs/
18 | - label: Repository
19 | url: https://gitlab.com/syntropize/syntropize
20 | - label: Downloads
21 | url: https://gitlab.com/syntropize/syntropize/-/releases
22 |
--------------------------------------------------------------------------------
/data/catalog/tangible-functional-programming.yaml:
--------------------------------------------------------------------------------
1 | kind: paper
2 | authors:
3 | - Conal Elliott
4 | title: Tangible Functional Programming
5 | year: 2007
6 | location: http://conal.net/papers/Eros/
7 | suggesters:
8 | - Apostolis
9 | curators:
10 | - Apostolis
11 | additional_resources:
12 | - label: Blog post
13 | url: http://conal.net/blog/posts/tangible-functional-programming-a-modern-marriage-of-usability-and-composability
14 | - label: Talk at Google
15 | url: https://youtu.be/faJ8N0giqzw
16 | - label: Talk slides
17 | url: http://conal.net/talks/tangible-functional-programming-2007-11.pdf
18 | quotes:
19 | - We present a user-friendly approach to unifying program creation and
20 | execution, based on a notion of “tangible values” (TVs), which are visual
21 | and interactive manifestations of pure values, including functions.
22 | Programming happens by gestural composition of TVs. Our goal is to give
23 | end-users the ability to create parameterized, composable content without
24 | imposing the usual abstract and linguistic working style of programmers. We
25 | hope that such a system will put the essence of programming into the hands
26 | of many more people, and in particular people with artistic/visual creative
27 | style.
28 |
--------------------------------------------------------------------------------
/data/catalog/the-future-of-software-the-end-of-apps-and-why-ux-designers-should-care-about-type-theory.yaml:
--------------------------------------------------------------------------------
1 | kind: post
2 | authors:
3 | - Paul Chiusano
4 | title: The future of software, the end of apps, and why UX designers should care
5 | about type theory
6 | year: 2013
7 | location: https://pchiusano.github.io/2013-05-22/future-of-software.html
8 | suggesters:
9 | - computably
10 | - jryans
11 | curators:
12 | - jryans
13 | quotes:
14 | - '**Software is now organized into static machines called *applications***.
15 | These applications ("appliances" is a better word) come equipped with a
16 | fixed vocabulary of actions, speak no common language, and [cannot be
17 | extended, composed, or combined](http://www.youtube.com/watch?v=faJ8N0giqzw)
18 | with other applications except with enormous friction.'
19 | - Applications can and ultimately should be replaced by *programming
20 | environments*, explicitly recognized as such, in which the user
21 | interactively creates, executes, inspects and *composes* programs.
22 | - Applications are failing at even their stated goal, but they do worse than
23 | that. Yes, an application is an (often terrible) interface to some library
24 | of functions, but it also traps this wonderful collection of potential
25 | building blocks in a mess of bureaucratic red tape.
26 | - No one piece of software 'does it all', and so individuals and businesses
27 | looking to automate or partially automate various tasks are often put in the
28 | position of having to integrate functionality across multiple applications,
29 | which is often painful or flat out impossible. The amount of lost
30 | productivity (or lost leisure time) on a global scale, both for individuals
31 | and business, is absolutely staggering.
32 | - As a civilization, we would be better off if software could be developed by
33 | small, unrelated groups, with an open standard that allowed for these groups
34 | to trivially combine functionality produced anywhere on the network.
35 | - The problem is, I don’t want a machine, I want a toolkit, and Google keeps
36 | trying to sell me machines. Perhaps these machines are exquisitely crafted,
37 | with extensive tuning and so forth, but a machine with a fixed set of
38 | actions can never do all the things that *I* can imagine might be useful,
39 | and I *don’t* want to wait around for Google to implement the functionality
40 | I desire as another awkward one-off 'feature' that’s poorly integrated and
41 | just adds more complexity to an already bloated application.
42 |
--------------------------------------------------------------------------------
/data/catalog/the-mythical-matched-modules-overcoming-the-tyranny-of-inflexible-software-construction.yaml:
--------------------------------------------------------------------------------
1 | kind: paper
2 | authors:
3 | - stephenrkell
4 | title: "The mythical matched modules: overcoming the tyranny of inflexible
5 | software construction"
6 | year: 2009
7 | location: https://www.humprog.org/~stephen/research/papers/kell09mythical.pdf
8 | suggesters:
9 | - jryans
10 | curators:
11 | - jryans
12 | quotes:
13 | - 'Conventional tools yield expensive and inflexible software. ... I propose
14 | that a solution must radically separate the concern of integration in
15 | software: firstly by using novel tools specialised towards integration (the
16 | "**integration domain**"), and secondly by prohibiting use of preexisting
17 | interfaces ("interface hiding") outside that domain.'
18 | - Placing high-level tool support for integration and adaptation close to the
19 | user, for example within web application mashup platforms and browser
20 | extensions has already led to added-value innovations which could not have
21 | been anticipated by the creators of the underlying software.
22 |
--------------------------------------------------------------------------------
/data/catalog/the-space-of-computing.yaml:
--------------------------------------------------------------------------------
1 | kind: thesis
2 | authors:
3 | - weiwei
4 | title: The "Space" of Computing
5 | year: 2018
6 | location: https://www.youtube.com/watch?v=nVFS85Zx6uw
7 | description: Our conception of "computing" has changed and continues to change.
8 | This work identifies dimensions that constitute the "space of computing".
9 | image: https://forum-cdn.malleable.systems/uploads/default/original/1X/9c50d7b19e521d613bf6927d6c386a4ae906bb45.png
10 | suggesters:
11 | - jryans
12 | curators:
13 | - jryans
14 | quotes:
15 | - Currently, only those who have a programming background or resources have
16 | the ability to create digital artifacts. This forces the rest of the world
17 | to be consumers, rather than creators or authors. When creating digital
18 | products, our conception of target audience is "users". The notion of
19 | "users" sometimes assumes that their main goal is consuming instead of
20 | playing, creating, or conversing. What if the digital environment was
21 | inclusive enough for anyone to create? How can we provide the tools that
22 | will enable everyone to become authors?
23 |
--------------------------------------------------------------------------------
/data/catalog/the-syndicated-actor-model.yaml:
--------------------------------------------------------------------------------
1 | kind: idea
2 | authors:
3 | - Tony Garnock-Jones
4 | title: The Syndicated Actor Model
5 | years:
6 | - 2012
7 | - present
8 | location: https://syndicate-lang.org/
9 | suggesters:
10 | - emery
11 | curators:
12 | - emery
13 | additional_resources:
14 | - label: About
15 | url: https://syndicate-lang.org/about/
16 | - label: Repo
17 | url: https://git.syndicate-lang.org/syndicate-lang
18 | quotes:
19 | - >-
20 | Functional programs are easy to write, but programs that interact with each
21 | other and the outside world are much harder.
22 |
23 | Programming models like the Actor model and the Tuplespace model make great strides toward simplifying programs that communicate. However, a few key difficulties remain.
24 |
25 | The Syndicated Actor model addresses these difficulties. It is closely related to both Actors and Tuplespaces, but builds on a different underlying primitive: *eventually-consistent replication of state* among actors. Its design also draws on widely deployed but informal ideas like publish/subscribe messaging.
26 |
--------------------------------------------------------------------------------
/data/catalog/tote-multiset-rewriting-language.yaml:
--------------------------------------------------------------------------------
1 | kind: tool
2 | authors:
3 | - Rek Bellum
4 | - Devine Lu Linvega
5 | title: "Tote: Multiset Rewriting Language"
6 | year: 2025
7 | location: https://hundredrabbits.itch.io/tote
8 | description: I've been interested for a while in symbolic visual programming,
9 | and I made a IDE to test some ideas around writing GUIs entirely in [multiset
10 | rewrite rules](https://wiki.xxiivv.com/site/fractran.html). Tote is a
11 | playground that lets me play with some of these ideas. I think it's relevant
12 | to malleable systems because it presents programming in its most elementary
13 | form (a single while loop), and can be implemented easily on near anything at
14 | all, in fact, all you need for this is a bag with marbles of different shapes
15 | or color.
16 | image: https://forum-cdn.malleable.systems/uploads/default/optimized/1X/be2f1682ea79f2d2ce32697bd4edf5163ee19c23_2_690x243.png
17 | suggesters:
18 | - neauoire
19 | curators:
20 | - neauoire
21 |
--------------------------------------------------------------------------------
/data/catalog/user-tailorable-systems-pressing-the-issues-with-buttons.yaml:
--------------------------------------------------------------------------------
1 | kind: paper
2 | authors:
3 | - Allan MacLean
4 | - Kathleen Carter
5 | - Lennart Lövstrand
6 | - Thomas Moran
7 | title: "User-tailorable systems: pressing the issues with buttons"
8 | year: 1990
9 | location: https://dl.acm.org/doi/abs/10.1145/97243.97271
10 | suggesters:
11 | - jryans
12 | curators:
13 | - jryans
14 | quotes:
15 | - It is impossible to design systems which are appropriate for all users and
16 | all situations. We believe that a useful technique is to have end users
17 | tailor their systems to match their personal work practices. This requires
18 | not only systems which can be tailored, but a culture within which users
19 | feel in control of the system and in which tailoring is the norm.
20 | - It is worth emphasising that we are interested here in skills required for
21 | tailoring. We do not intend to suggest that a 'programmer' is more skilled
22 | than a 'worker' in any absolute sense. If we were to focus on skills in the
23 | work domain, we would find that the worker was most skilled and the
24 | programmer least skilled.
25 | - As a first step in growing a tailoring culture, we claim that **it should be
26 | as easy to change the environment as it is to use it** (clearly all changes
27 | one might want to make will not be so easy - but it is important that some
28 | should be).
29 | - A remarkable amount of tailoring can be done by relying on buttons produced
30 | by other people. Buttons can be kept in documents and can be easily passed
31 | around by email, thus they are a tool for the user community to augment the
32 | Xerox Lisp environment by combining individual innovation and by sharing
33 | improvements with others. The fact that small-grain improvements can easily
34 | 'diffuse' throughout the user community is a powerful principle for
35 | supporting user-driven evolution of systems.
36 |
--------------------------------------------------------------------------------
/data/catalog/using-computers-more-freely-and-safely.yaml:
--------------------------------------------------------------------------------
1 | kind: talk
2 | authors:
3 | - Kartik Agaram
4 | title: Using computers more freely and safely
5 | year: 2023
6 | location: http://akkartik.name/freewheeling
7 | description: Manifesto for [Freewheeling
8 | Apps](https://forum.malleable.systems/t/freewheeling-apps/52) and experience
9 | report in trying to create situated software. Argues for building situated
10 | software out of situated tools that are parsimonious in dependencies and
11 | infrequently updated.
12 | image: https://forum-cdn.malleable.systems/uploads/default/optimized/1X/e8d4f16ed1229199c5c67095063bbff8103110b0_2_690x378.png
13 | suggesters:
14 | - akkartik
15 | curators:
16 | - jryans
17 | - akkartik
18 | quotes:
19 | - |-
20 | Prefer software:
21 | * with thousands rather than millions of users
22 | * that seldom requires updates
23 | * that spawns lots of forks
24 | * that is easy to modify
25 | * that _you_ can modify
26 |
--------------------------------------------------------------------------------
/data/catalog/wang-tiles-computing.yaml:
--------------------------------------------------------------------------------
1 | kind: post
2 | authors:
3 | - Graham Shawcross
4 | title: Wang Tiles Computing
5 | year: 2012
6 | location: https://grahamshawcross.com/2012/10/12/wang-tiles-and-turing-machines/
7 | image: https://forum-cdn.malleable.systems/uploads/default/optimized/1X/cce371e4bebde5859b52cf66c065f14f36ee2797_2_322x499.jpeg
8 | suggesters:
9 | - neauoire
10 | curators:
11 | - neauoire
12 | quotes:
13 | - >-
14 | Wang pointed out that it is possible to find sets of Wang tiles that mimic
15 | the behaviour of any Turing Machine (Wang 1975).
16 |
17 | A Turing machine can compute all recursive functions, that is functions whose values can be calculated in a finite number of steps. That is to do, however inefficiently, what any conceivable computer can do.
18 |
19 | The basic idea is to use rows of tiles to simulate the tape in the machine, with successive rows corresponding to consecutive states of the machine.
20 |
--------------------------------------------------------------------------------
/data/catalog/webstrates-shareable-dynamic-media.yaml:
--------------------------------------------------------------------------------
1 | kind: paper
2 | authors:
3 | - cklokmose
4 | - eagan
5 | - Siemen Baader
6 | - Wendy Mackay
7 | - Michel Beaudouin-Lafon
8 | title: "Webstrates: Shareable Dynamic Media"
9 | year: 2015
10 | location: https://www.klokmose.net/clemens/wp-content/uploads/2015/08/webstrates.pdf
11 | image: https://forum-cdn.malleable.systems/uploads/default/original/1X/5adedba76258218e4548b4059c398e53d329df45.png
12 | suggesters:
13 | - jryans
14 | curators:
15 | - jryans
16 | quotes:
17 | - Webstrates offer a novel approach for creating shareable dynamic media that
18 | blur the distinction between documents and applications. Our vision requires
19 | software to be malleable by users, so they can appropriate documents and
20 | tools to meet individual needs; shareable among users, so they can
21 | collaborate on multiple aspects of the media; and distributable across
22 | heterogeneous devices and platforms.
23 | - By sharing embedded code, behavior typically associated with application
24 | software can also be (collaboratively) manipulated, opening the way to novel
25 | possibilities for combining content, computation and interaction. Webstrates
26 | can be composed by embedding one webstrate within another, a process called
27 | transclusion [Nelson 1995], that lets users truly share, rather than copy,
28 | content.
29 |
--------------------------------------------------------------------------------
/data/catalog/what-lies-in-the-path-of-the-revolution.yaml:
--------------------------------------------------------------------------------
1 | kind: paper
2 | authors:
3 | - basman
4 | - ptchernavskij
5 | title: What Lies in the Path of the Revolution
6 | year: 2018
7 | location: https://github.com/amb26/papers/blob/master/ppig-2018/What_Lies_in_the_Path_of_the_Revolution.pdf
8 | suggesters:
9 | - jryans
10 | curators:
11 | - jryans
12 | quotes:
13 | - We argue that a form of "**digital serfdom**" has rapidly grown up around
14 | us, where various important classes of artefacts, increasingly essential for
15 | everyday life, including participation in political and economic life,
16 | cannot be effectively owned by ordinary individuals.
17 | - Many of the technological barriers to ownership, especially as regards
18 | software, can be seen as embedded in certain questions of "reuse" — one of
19 | the central affordances of ownership is the ability to transplant a thing
20 | from its original location to a different one, following the desires or
21 | person of the owner. For most kinds of software this is possible in only a
22 | crude way — an "application" can be installed on one machine rather than
23 | another — and with the rising prevalence of rental or cloud-based models for
24 | the deployment of software, it is decreasingly possible at all.
25 | - If you find a piece of software that does something of value to you, **it
26 | should be possible to make it your own**. This implies that you can keep
27 | using it as part of the collection of tools you carry with you, in familiar
28 | contexts, or experiment with using it in novel contexts.
29 |
--------------------------------------------------------------------------------
/data/catalog/wildcard-spreadsheet-driven-customization-of-web-applications.yaml:
--------------------------------------------------------------------------------
1 | kind: paper
2 | authors:
3 | - geoffreylitt
4 | - Daniel Jackson
5 | title: "Wildcard: Spreadsheet-Driven Customization of Web Applications"
6 | year: 2020
7 | location: https://www.geoffreylitt.com/wildcard/salon2020/
8 | image: https://forum-cdn.malleable.systems/uploads/default/optimized/1X/82018fc7c6bf92ac1c15a2c05bfbe45115c70a14_2_657x500.png
9 | suggesters:
10 | - jryans
11 | curators:
12 | - jryans
13 | quotes:
14 | - In this paper, we present spreadsheet-driven customization, a technique that
15 | enables end users to customize software without doing any traditional
16 | programming. The idea is to augment an application’s UI with a spreadsheet
17 | that is synchronized with the application’s data. When the user manipulates
18 | the spreadsheet, the underlying data is modified and the changes are
19 | propagated to the UI, and vice versa.
20 | - Generic tools are especially important for software customization, because a
21 | common barrier to customizing software is not having enough time [Mackay
22 | 1991]—it’s more likely that people will customize software frequently if
23 | they can reuse the same tools across many applications.
24 | - One of the most interesting properties of spreadsheets is that users
25 | familiar with only a tiny sliver of their functionality (e.g., storing
26 | tables of numbers and computing simple sums) can still use them in valuable
27 | ways. This supports the user’s natural motivation to continue using the
28 | tool, and to eventually learn its more powerful features if needed [Nardi
29 | and Miller 1991].
30 |
--------------------------------------------------------------------------------
/data/contributors.yaml:
--------------------------------------------------------------------------------
1 | contributors:
2 | khinsen:
3 | name: Konrad Hinsen
4 | roles:
5 | - Catalog suggester
6 | - Catalog curator
7 | - Blog post author
8 | avatar: /avatars/khinsen.jpg
9 | website: https://khinsen.net
10 | mastodon: https://scholar.social/@khinsen
11 | twitter: khinsen
12 | cklokmose:
13 | name: Clemens N. Klokmose
14 | affiliation: Aarhus University
15 | roles:
16 | - Catalog suggester
17 | avatar: /avatars/cklokmose.jpg
18 | website: https://cs.au.dk/~clemens/
19 | mastodon: https://social.multiverset.net/@clemens
20 | twitter: cklokmose
21 | geoffreylitt:
22 | name: Geoffrey Litt
23 | affiliation: MIT
24 | roles:
25 | - Catalog suggester
26 | avatar: /avatars/geoffreylitt.jpg
27 | website: https://www.geoffreylitt.com
28 | mastodon: https://mastodon.social/@geoffreylitt
29 | twitter: geoffreylitt
30 | jryans:
31 | name: J. Ryan Stinnett
32 | roles:
33 | - Collective organiser
34 | - Catalog suggester
35 | - Catalog curator
36 | - Blog post author
37 | avatar: /avatars/jryans.jpg
38 | website: https://convolv.es
39 | mastodon: https://merveilles.town/@jryans
40 | twitter: jryans
41 | 7h3kk1d:
42 | name: Alexander Bandukwala
43 | roles:
44 | - Catalog curator
45 | - Catalog suggester
46 | avatar: /avatars/7h3kk1d.jpg
47 | website: https://bandukwala.me
48 | mastodon: https://fosstodon.org/@thekkid
49 | twitter: abanduk
50 | karlicoss:
51 | roles:
52 | - Catalog suggester
53 | avatar: /avatars/karlicoss.jpg
54 | website: https://beepb00p.xyz
55 | mastodon: https://merveilles.town/@karlicoss
56 | twitter: karlicoss
57 | computably:
58 | name: Jimmy Ye
59 | roles:
60 | - Catalog suggester
61 | avatar: /avatars/computably.jpg
62 | website: https://rationalis.github.io
63 | github: rationalis
64 | akkartik:
65 | name: Kartik Agaram
66 | roles:
67 | - Catalog curator
68 | avatar: /avatars/akkartik.jpg
69 | website: http://akkartik.name
70 | mastodon: https://merveilles.town/@akkartik
71 | twitter: akkartik
72 |
--------------------------------------------------------------------------------
/flake.lock:
--------------------------------------------------------------------------------
1 | {
2 | "nodes": {
3 | "nixpkgs": {
4 | "locked": {
5 | "lastModified": 1743975612,
6 | "narHash": "sha256-o4FjFOUmjSRMK7dn0TFdAT0RRWUWD+WsspPHa+qEQT8=",
7 | "owner": "NixOS",
8 | "repo": "nixpkgs",
9 | "rev": "a880f49904d68b5e53338d1e8c7bf80f59903928",
10 | "type": "github"
11 | },
12 | "original": {
13 | "owner": "NixOS",
14 | "ref": "nixos-24.11",
15 | "repo": "nixpkgs",
16 | "type": "github"
17 | }
18 | },
19 | "nixpkgsHugo": {
20 | "locked": {
21 | "lastModified": 1620015740,
22 | "narHash": "sha256-kNQsw1pCzJM4EPIJEhCi17NMpDE8pwqHamS6ad83rmc=",
23 | "owner": "NixOS",
24 | "repo": "nixpkgs",
25 | "rev": "df23c968285f443cca67600e91a2724fa3166c34",
26 | "type": "github"
27 | },
28 | "original": {
29 | "owner": "NixOS",
30 | "repo": "nixpkgs",
31 | "rev": "df23c968285f443cca67600e91a2724fa3166c34",
32 | "type": "github"
33 | }
34 | },
35 | "root": {
36 | "inputs": {
37 | "nixpkgs": "nixpkgs",
38 | "nixpkgsHugo": "nixpkgsHugo",
39 | "systems": "systems"
40 | }
41 | },
42 | "systems": {
43 | "locked": {
44 | "lastModified": 1681028828,
45 | "narHash": "sha256-Vy1rq5AaRuLzOxct8nz4T6wlgyUR7zLU309k9mBC768=",
46 | "owner": "nix-systems",
47 | "repo": "default",
48 | "rev": "da67096a3b9bf56a91d16901293e51ba5b49a27e",
49 | "type": "github"
50 | },
51 | "original": {
52 | "owner": "nix-systems",
53 | "repo": "default",
54 | "type": "github"
55 | }
56 | }
57 | },
58 | "root": "root",
59 | "version": 7
60 | }
61 |
--------------------------------------------------------------------------------
/flake.nix:
--------------------------------------------------------------------------------
1 | {
2 | inputs = {
3 | nixpkgs.url = "github:NixOS/nixpkgs/nixos-24.11";
4 | systems.url = "github:nix-systems/default";
5 | # Hugo 0.83.1
6 | nixpkgsHugo.url = "github:NixOS/nixpkgs/df23c968285f443cca67600e91a2724fa3166c34";
7 | };
8 |
9 | outputs =
10 | {
11 | nixpkgs,
12 | systems,
13 | nixpkgsHugo,
14 | ...
15 | }:
16 | let
17 | forEachSystem =
18 | f:
19 | nixpkgs.lib.genAttrs (import systems) (
20 | system:
21 | f {
22 | pkgs = import nixpkgs {
23 | inherit system;
24 | };
25 | pkgsHugo = import nixpkgsHugo {
26 | inherit system;
27 | };
28 | }
29 | );
30 | in
31 | {
32 | devShells = forEachSystem (
33 | { pkgs, pkgsHugo }:
34 | {
35 | default = pkgs.mkShell {
36 | packages = with pkgs; [
37 | pkgsHugo.hugo
38 | nodejs_22
39 | ];
40 | };
41 | }
42 | );
43 | };
44 | }
45 |
--------------------------------------------------------------------------------
/layouts/_default/baseof.html:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
6 | {{/* NOTE: the Site's title, and if there is a page title, that is set too */}}
7 | {{ block "title" . }}{{ with .Params.Title }}{{ . }} | {{ end }}{{ .Site.Title }}{{ end }}
8 |
9 | {{ hugo.Generator }}
10 | {{/* NOTE: For Production make sure you add `HUGO_ENV="production"` before your build command */}}
11 | {{ if eq (getenv "HUGO_ENV") "production" | or (eq .Site.Params.env "production") }}
12 |
13 | {{ else }}
14 |
15 | {{ end }}
16 |
17 | {{ $stylesheet := .Site.Data.webpack_assets.app }}
18 | {{ with $stylesheet.css }}
19 |
20 | {{ end }}
21 |
22 | {{ range .Site.Params.custom_css }}
23 |
24 | {{ end }}
25 |
26 | {{ block "favicon" . }}
27 | {{ partialCached "site-favicon.html" . }}
28 | {{ end }}
29 |
30 | {{ if .IsHome }}
31 |
32 |
33 | {{ else }}
34 | {{ if .OutputFormats.Get "RSS" }}
35 | {{ with .OutputFormats.Get "RSS" }}
36 |
37 |
38 | {{ end }}
39 | {{ end }}
40 | {{ end }}
41 |
42 | {{/* NOTE: These Hugo Internal Templates can be found starting at https://github.com/spf13/hugo/blob/master/tpl/tplimpl/template_embedded.go#L158 */}}
43 | {{ partial "opengraph.html" . }}
44 | {{ template "_internal/schema.html" . }}
45 | {{ partial "twitter-cards.html" . }}
46 |
47 |
48 |
49 |
50 | {{ block "header" . }}{{ partial "site-header.html" .}}{{ end }}
51 |
52 | {{ block "main" . }}{{ end }}
53 |
54 | {{ block "footer" . }}{{ partialCached "site-footer.html" . }}{{ end }}
55 | {{ block "scripts" . }}{{ partialCached "site-scripts.html" . }}{{ end }}
56 |
57 |
58 |
--------------------------------------------------------------------------------
/layouts/_default/list.html:
--------------------------------------------------------------------------------
1 | {{ define "main" }}
2 |
3 | {{ with .Content }}
4 |
5 | {{- . -}}
6 |
7 | {{ end }}
8 |
9 | {{ range .Paginator.Pages }}
10 |
19 | {{ end }}
20 | {{/* Hugo uses Go's date formatting is set by example. Here are two
21 | formats */}}
22 | {{ if .Date }}
23 |
26 | {{ end }}
27 | {{/*
28 | Show "reading time" and "word count" but only if one of the following are true:
29 | 1) A global config `params` value is set `show_reading_time = true`
30 | 2) A section front matter value is set `show_reading_time = true`
31 | 3) A page front matter value is set `show_reading_time = true`
32 | */}}
33 | {{ if (or (eq (.Param "show_reading_time") true) (eq $section.Params.show_reading_time true) )}}
34 | - {{ .ReadingTime}} minutes read
35 | - {{ .WordCount}} words
36 | {{ end }}
37 |
38 |
39 |
41 | {{- .Content -}}
42 |
43 |
19 | {{ range $value.Pages }}
20 | {{ partial "summary.html" . }}
21 | {{ end }}
22 | {{ end }}
23 |
24 |
25 | {{ end }}
26 |
--------------------------------------------------------------------------------
/layouts/blog/list.xml:
--------------------------------------------------------------------------------
1 | {{- $pctx := . -}}
2 | {{- if .IsHome -}}{{ $pctx = .Site }}{{- end -}}
3 | {{- $pages := $pctx.RegularPages -}}
4 | {{- $limit := .Site.Config.Services.RSS.Limit -}}
5 | {{- if ge $limit 1 -}}
6 | {{- $pages = $pages | first $limit -}}
7 | {{- end -}}
8 | {{- printf "" | safeHTML }}
9 |
10 |
11 | {{/* Drop the section name for the blog */}}
12 | {{ .Site.Title }}
13 | {{ .Permalink }}
14 | Recent content on {{ .Site.Title }}
15 | Hugo -- gohugo.io{{ with .Site.LanguageCode }}
16 | {{.}}{{end}}{{ with .Site.Author.email }}
17 | {{.}}{{ with $.Site.Author.name }} ({{.}}){{end}}{{end}}{{ with .Site.Author.email }}
18 | {{.}}{{ with $.Site.Author.name }} ({{.}}){{end}}{{end}}{{ with .Site.Copyright }}
19 | {{.}}{{end}}{{ if not .Date.IsZero }}
20 | {{ .Date.Format "Mon, 02 Jan 2006 15:04:05 -0700" | safeHTML }}{{ end }}
21 | {{ with .OutputFormats.Get "RSS" }}
22 | {{ printf "" .Permalink .MediaType | safeHTML }}
23 | {{ end }}
24 | {{ range $pages }}
25 |
26 | {{ .Title }}
27 | {{ .Permalink }}
28 | {{ .Date.Format "Mon, 02 Jan 2006 15:04:05 -0700" | safeHTML }}
29 | {{ with .Site.Author.email }}{{.}}{{ with $.Site.Author.name }} ({{.}}){{end}}{{end}}
30 | {{ .Permalink }}
31 | {{ .Content | html }}
32 |
33 | {{ end }}
34 |
35 |
36 |
--------------------------------------------------------------------------------
/layouts/blog/single.html:
--------------------------------------------------------------------------------
1 | {{ define "header" }}
2 | {{ partial "page-header.html" . }}
3 | {{ end }}
4 |
5 | {{ define "main" }}
6 | {{ $section := .Site.GetPage "section" .Section }}
7 |
8 | {{ $hasAside := or (.Params.toc) (.Site.RegularPages.Related .)}}
9 |
10 |
12 |
13 | {{- .Title -}}
14 |
15 | {{ if .Params.author }}
16 |
17 | By
18 | {{ with .Params.authorAvatar }}
19 |
20 | {{ end }}
21 | {{ .Params.author | markdownify }}
22 |
23 | {{ end }}
24 | {{/* Hugo uses Go's date formatting is set by example. Here are two
25 | formats */}}
26 | {{ if .Date }}
27 |
30 | {{ end }}
31 | {{/*
32 | Show "reading time" and "word count" but only if one of the following are true:
33 | 1) A global config `params` value is set `show_reading_time = true`
34 | 2) A section front matter value is set `show_reading_time = true`
35 | 3) A page front matter value is set `show_reading_time = true`
36 | */}}
37 | {{ if (or (eq (.Param "show_reading_time") true) (eq $section.Params.show_reading_time true) )}}
38 | - {{ .ReadingTime}} minutes read
39 | - {{ .WordCount}} words
40 | {{ end }}
41 |
42 |
43 |
45 | {{- .Content -}}
46 |
47 |
{{ end }}
82 | {{ with .image }}
83 |
84 |
85 |
86 | {{ end }}
87 | {{ with .additional_resources }}
88 |
89 | Additional Resources
90 |
91 | {{ range . }}
92 |
{{ .label }}{{ if .description }}: {{ .description }} {{ end }}
93 | {{ end }}
94 |
95 |
96 | {{ end }}
97 | {{ with .quotes }}
98 |
99 | {{ range . }}
100 |
{{ . | markdownify }}
101 | {{ end }}
102 |
103 | {{ end }}
104 |
105 |
106 | {{ end }}
107 |
108 |
109 |
110 | People and groups
111 |
112 |
113 |
114 | The following people and groups are some of the key actors in this space
115 | due to their work highlighted above, which has been curated through
116 | contributions to the catalog from the community. Please note that you
117 | should not assume that they have endorsed the community's actions —
118 | we simply admire their work.
119 |
27 |
28 | {{/* Define a section to pull recent posts from. For Hugo 0.20 this will default to the section with the most number of pages. */}}
29 | {{ $mainSections := .Site.Params.mainSections | default (slice "post") }}
30 | {{/* Create a variable with that section to use in multiple places. */}}
31 | {{ $section := where .Site.RegularPages "Section" "in" $mainSections }}
32 | {{/* Check to see if the section is defined for ranging through it */}}
33 | {{ $section_count := len $section }}
34 | {{ if ge $section_count 1 }}
35 | {{/* Derive the section name */}}
36 | {{ $section_name := index (.Site.Params.mainSections) 0 }}
37 |
38 |
39 | {{/* Use $section_name to get the section title. Use "with" to only show it if it exists */}}
40 | {{ with .Site.GetPage "section" $section_name }}
41 |
77 | The Malleable Systems Collective is a virtual community where anyone can
78 | participate. The following people have contributed to the community in
79 | various ways as noted by the roles under their names.
80 |
88 | {{ with .website }}
89 |
92 |
93 |
94 | {{ end }}
95 | {{ with .mastodon }}
96 |
99 |
100 |
101 | {{ end }}
102 | {{ with .twitter }}
103 |
106 |
107 |
108 | {{ end }}
109 | {{ with (.github | default $key) }}
110 |
113 |
114 |
115 | {{ end }}
116 |
117 |
118 | {{ range .roles }}
119 | {{ . }}
122 | {{ end }}
123 |
124 |
125 | {{ end }}
126 |
127 |
128 | {{ end }}
129 |
--------------------------------------------------------------------------------
/layouts/partials/menu-contextual.html:
--------------------------------------------------------------------------------
1 | {{/*
2 | Use Hugo's native Table of contents feature. You must set `toc: true` in your parameters for this to show.
3 | https://gohugo.io/content-management/toc/
4 | */}}
5 |
6 | {{- if .Params.toc -}}
7 |
8 |
Contents
9 | {{ .TableOfContents }}
10 |
11 | {{- end -}}
12 |
13 | {{/*
14 | Use Hugo's native related content feature to pull in content that may have similar parameters, like tags. etc.
15 | https://gohugo.io/content-management/related/
16 | */}}
17 |
18 | {{ $related := .Site.RegularPages.Related . | first 15 }}
19 |
20 | {{ with $related }}
21 |
5 | {{ if .Params.featured_image }}
6 | {{/* Trimming the slash and adding absURL make sure the image works no matter where our site lives */}}
7 | {{ $featured_image := (trim $featured_image "/") | absURL }}
8 |
20 | {{ end }}
21 | {{ .Params.author | markdownify }}
22 |