![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
brainwaneI am trying out a bunch of thoughts on what some different approaches to software are... beyond waterfall/agile, free software/open source, and FLOSS/proprietary, and beyond shrinkwrap/internal/embedded/games/throwaway....
* Deliberately ephemeral
* Accidentally ephemeral (like some Minecraft mods or personal one-off scripts)
* Enterprisey, scale-centric
* Artisanal/personal/couture
* Educational (as in, writing source code specifically to be read as an aid to learning, as in a presentation, test, blog post, or textbook)
* Angry, competitive, insulting
* Cheery, collaborative, complimenting
* Innovative
* Stable
* Mimetic (copying functionality/approach of other existing software)
* Particularly amenable to any one of the Felder-Silverman engineering learning styles (and not to its opposite)
* Social norms (especially around permission, redistribution, reuse) taking the place of copyright when in a copyright grey area
* Voluntary
* Paid
* School project
* Taking donations, but passing some of them to upstream
* Gift culture
* For-profit proprietary
* For-profit open source
* Copyleft licensing + charging extortionate fees to license differently
* Corporate non-profit open source
* Free software
* Specifically playful, alternative, queer free software
* Copyright abolitionist or nearly so
* No license out of neglect/convenience (the "GitHub License", sort of formalized as WTFPL)
* Piracy, open and proud
* Piracy, furtive and/or (interally seen as) hypocritical
* Grey market (like Minecraft mods)
* Despotism by founder
* Willingness to hand maintainership over
* Benign neglect by owner/maintainer of core infrastructure
* Monolithic
* All the different ways "not monolithic" can look (plugins, APIs, scriptability, portability, content/logic/presentation...)
I'm brain-dumping this as I think noodly rambly thoughts about open source software communities and abstractions we might borrow from other software communities. I absorbed some assumptions fifteen to thirty years ago, of how to use and make software, how open source citizens should act in open source communities, about what the rules are, and about the sets of expectations we have about how we talk and work with each other. And I'm wondering what a genuinely different approach would look like.
* Deliberately ephemeral
* Accidentally ephemeral (like some Minecraft mods or personal one-off scripts)
* Enterprisey, scale-centric
* Artisanal/personal/couture
* Educational (as in, writing source code specifically to be read as an aid to learning, as in a presentation, test, blog post, or textbook)
* Angry, competitive, insulting
* Cheery, collaborative, complimenting
* Innovative
* Stable
* Mimetic (copying functionality/approach of other existing software)
* Particularly amenable to any one of the Felder-Silverman engineering learning styles (and not to its opposite)
* Social norms (especially around permission, redistribution, reuse) taking the place of copyright when in a copyright grey area
* Voluntary
* Paid
* School project
* Taking donations, but passing some of them to upstream
* Gift culture
* For-profit proprietary
* For-profit open source
* Copyleft licensing + charging extortionate fees to license differently
* Corporate non-profit open source
* Free software
* Specifically playful, alternative, queer free software
* Copyright abolitionist or nearly so
* No license out of neglect/convenience (the "GitHub License", sort of formalized as WTFPL)
* Piracy, open and proud
* Piracy, furtive and/or (interally seen as) hypocritical
* Grey market (like Minecraft mods)
* Despotism by founder
* Willingness to hand maintainership over
* Benign neglect by owner/maintainer of core infrastructure
* Monolithic
* All the different ways "not monolithic" can look (plugins, APIs, scriptability, portability, content/logic/presentation...)
I'm brain-dumping this as I think noodly rambly thoughts about open source software communities and abstractions we might borrow from other software communities. I absorbed some assumptions fifteen to thirty years ago, of how to use and make software, how open source citizens should act in open source communities, about what the rules are, and about the sets of expectations we have about how we talk and work with each other. And I'm wondering what a genuinely different approach would look like.
