Browse Source

More links

master
David Larlet 2 years ago
parent
commit
a019624b80
37 changed files with 7014 additions and 0 deletions
  1. 443
    0
      cache/2022/0dc625e86fb8e680308250b1245f1086/index.html
  2. 274
    0
      cache/2022/0dc625e86fb8e680308250b1245f1086/index.md
  3. 210
    0
      cache/2022/47b228aca2d77bc5e7eee35437655a8e/index.html
  4. 81
    0
      cache/2022/47b228aca2d77bc5e7eee35437655a8e/index.md
  5. 264
    0
      cache/2022/571d5d3f9d63d9ec4a8107e5abd15941/index.html
  6. 97
    0
      cache/2022/571d5d3f9d63d9ec4a8107e5abd15941/index.md
  7. 202
    0
      cache/2022/6e3580538a14b52ac9cb5fd54dfa1384/index.html
  8. 65
    0
      cache/2022/6e3580538a14b52ac9cb5fd54dfa1384/index.md
  9. 325
    0
      cache/2022/850c5e99f499d9703c9b9bc116914429/index.html
  10. 158
    0
      cache/2022/850c5e99f499d9703c9b9bc116914429/index.md
  11. 280
    0
      cache/2022/891705d1555d09a941fd1f7685de9370/index.html
  12. 141
    0
      cache/2022/891705d1555d09a941fd1f7685de9370/index.md
  13. 184
    0
      cache/2022/8d9cffcd9bdc116b8934310706def4bc/index.html
  14. 17
    0
      cache/2022/8d9cffcd9bdc116b8934310706def4bc/index.md
  15. 209
    0
      cache/2022/985e33814839a9c113720a5142caec0e/index.html
  16. 8
    0
      cache/2022/985e33814839a9c113720a5142caec0e/index.md
  17. 262
    0
      cache/2022/9ad9f5ea367dbd74e4aeeb8471747247/index.html
  18. 95
    0
      cache/2022/9ad9f5ea367dbd74e4aeeb8471747247/index.md
  19. 199
    0
      cache/2022/9eac0872e78f3de333ff5df423060de2/index.html
  20. 32
    0
      cache/2022/9eac0872e78f3de333ff5df423060de2/index.md
  21. 207
    0
      cache/2022/a400ea6d0c196bbcaefbe1cc9af84fbb/index.html
  22. 40
    0
      cache/2022/a400ea6d0c196bbcaefbe1cc9af84fbb/index.md
  23. 243
    0
      cache/2022/acd4b5cdd3ebf13e74a102563aa90b9a/index.html
  24. 77
    0
      cache/2022/acd4b5cdd3ebf13e74a102563aa90b9a/index.md
  25. 257
    0
      cache/2022/ad5756e74f5c976458c42eeb9e60707e/index.html
  26. 90
    0
      cache/2022/ad5756e74f5c976458c42eeb9e60707e/index.md
  27. 175
    0
      cache/2022/ae3792ebced6f8b2b12b04723d982462/index.html
  28. 8
    0
      cache/2022/ae3792ebced6f8b2b12b04723d982462/index.md
  29. 656
    0
      cache/2022/b17f8ac80615c86cade89dd81c8aa50b/index.html
  30. 492
    0
      cache/2022/b17f8ac80615c86cade89dd81c8aa50b/index.md
  31. 342
    0
      cache/2022/e8d6bd5b11ae399009cf9258869be09c/index.html
  32. 175
    0
      cache/2022/e8d6bd5b11ae399009cf9258869be09c/index.md
  33. 204
    0
      cache/2022/ed0eff49e75f35733437d71da03b0af3/index.html
  34. 37
    0
      cache/2022/ed0eff49e75f35733437d71da03b0af3/index.md
  35. 300
    0
      cache/2022/f57abf8bb9e96e5cb5cfe845d76729f5/index.html
  36. 129
    0
      cache/2022/f57abf8bb9e96e5cb5cfe845d76729f5/index.md
  37. 36
    0
      cache/2022/index.html

+ 443
- 0
cache/2022/0dc625e86fb8e680308250b1245f1086/index.html View File

@@ -0,0 +1,443 @@
<!doctype html><!-- This is a valid HTML5 document. -->
<!-- Screen readers, SEO, extensions and so on. -->
<html lang="fr">
<!-- Has to be within the first 1024 bytes, hence before the `title` element
See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
<meta charset="utf-8">
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
<!-- The viewport meta is quite crowded and we are responsible for that.
See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
<meta name="viewport" content="width=device-width,initial-scale=1">
<!-- Required to make a valid HTML5 document. -->
<title>What makes writing more readable? (archive) — David Larlet</title>
<meta name="description" content="Publication mise en cache pour en conserver une trace.">
<!-- That good ol' feed, subscribe :). -->
<link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/">
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png">
<link rel="manifest" href="/static/david/icons2/site.webmanifest">
<link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c">
<link rel="shortcut icon" href="/static/david/icons2/favicon.ico">
<meta name="msapplication-TileColor" content="#f7f7f7">
<meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml">
<meta name="theme-color" content="#f7f7f7" media="(prefers-color-scheme: light)">
<meta name="theme-color" content="#272727" media="(prefers-color-scheme: dark)">
<!-- Documented, feel free to shoot an email. -->
<link rel="stylesheet" href="/static/david/css/style_2021-01-20.css">
<!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. -->
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<script>
function toggleTheme(themeName) {
document.documentElement.classList.toggle(
'forced-dark',
themeName === 'dark'
)
document.documentElement.classList.toggle(
'forced-light',
themeName === 'light'
)
}
const selectedTheme = localStorage.getItem('theme')
if (selectedTheme !== 'undefined') {
toggleTheme(selectedTheme)
}
</script>

<meta name="robots" content="noindex, nofollow">
<meta content="origin-when-cross-origin" name="referrer">
<!-- Canonical URL for SEO purposes -->
<link rel="canonical" href="https://pudding.cool/2022/02/plain/">

<body class="remarkdown h1-underline h2-underline h3-underline em-underscore hr-center ul-star pre-tick" data-instant-intensity="viewport-all">


<article>
<header>
<h1>What makes writing more readable?</h1>
</header>
<nav>
<p class="center">
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="https://pudding.cool/2022/02/plain/" title="Lien vers le contenu original">Source originale</a>
</p>
</nav>
<hr>
<div class="toggle svelte-1k1jl04"><p class="sr-only">The following is a toggle that allows you to change whether the text is standard or translated
into plain language. Press the p key at any time to switch between standard and plain language
versions of the article. If you are using a screen reader, you will need to disable your the quick
navigation keyboard commands in order for the P key to function.
</p>

<p class="toggle toggle--inner svelte-1nyzcas"><span class="label svelte-1nyzcas" id="toggle-471912">Plain Language</span>
<button role="switch" aria-checked="false" aria-labelledby="toggle-471912" class="svelte-1nyzcas"><span class="svelte-1nyzcas">on</span>
<span class="svelte-1nyzcas">off</span></button></p>
<p aria-hidden class="use-keyboard plain-style svelte-1nyzcas">(Or use the "p" key)</p></div>

<section id="part-1" class="svelte-192zsyu">
<div class="sr-only"><p>Writing text that can be understood by as many people as possible seems like an obvious best practice. But from news media to legal guidance to academic research, the way we write often creates barriers to who can read it. Plain language—a style of writing that uses simplified sentences, everyday vocabulary, and clear structure—aims to remove those barriers.</p></div>
<div aria-hidden class="svelte-1xg41jv outer">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">Writing text that can be understood by as many people as possible seems like an obvious best practice. But from news media to legal guidance to academic research, the way we write often creates barriers to who can read it. Plain language—a style of writing that uses simplified sentences, everyday vocabulary, and clear structure—aims to remove those barriers.</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">Good writing is easy to read. But a lot of writing is hard to read. Some people can’t read hard writing. Plain language fixes this problem. It makes writing easy to read for more people.</p>
</button></div>
</div><div class="sr-only"><p><span class="tap-icon"></span><strong>You can see it in action right here!</strong> Click the text next to each paragraph to read it in <span class="plain-style">plain language</span>.</p></div>
<div aria-hidden class="svelte-1xg41jv outer no-plain">

<div class="svelte-1xg41jv inner info-box"><p class="svelte-1xg41jv"><span class="tap-icon"></span><strong>You can see it in action right here!</strong> Click the text next to each paragraph to read it in <span class="plain-style">plain language</span>.</p></div>
</div><div class="sr-only"><p>You can also use the toggle on the top right to switch <strong>everything</strong> to <span class="plain-style">plain language</span>. Or use the <span class="plain-style">“p”</span> key on your keyboard.</p></div>
<div aria-hidden class="svelte-1xg41jv outer no-plain">

<div class="svelte-1xg41jv inner info-box"><p class="svelte-1xg41jv">You can also use the toggle on the top right to switch <strong>everything</strong> to <span class="plain-style">plain language</span>. Or use the <span class="plain-style">“p”</span> key on your keyboard.</p></div>
</div>
<div aria-hidden class="svelte-1xg41jv outer">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">Plain language is useful for everyone, but especially for those who are often denied the opportunity to engage with and comment on public writing. This includes the <a href="https://www.ncld.org/research/state-of-learning-disabilities">20% of the population with learning disabilities</a>, a number of the <a href="https://ici-s.umn.edu/files/aCHyYaFjMi/risp_2017">more than 7 million people in the US</a> with intellectual disabilities (ID), readers for whom English is not a first language and people with limited access to education, among others.</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">Plain language is helpful for everyone. But it is really good for people who may find other kinds of writing hard to read. That includes:</p><ul><li>People with learning disabilities.</li><li>People with intellectual disabilities (ID).</li><li>People who are learning to speak English.</li><li>People who did not go to school or went to school less than they wanted to.</li>
</ul>
</button></div>
</div><div class="sr-only"><p>These audiences are routinely excluded from public dialogues, including dialogues about themselves. People with disabilities are also often excluded from writing or sharing their own stories first-hand due to lower vocabulary skills, learning differences, and intellectual disabilities. For example, throughout much of US history, people with ID <a href="https://ncd.gov/sites/default/files/NCD_Turning-Rights-into-Reality_508_0.pdf">have had decisions made on their behalf</a> based on the presumption that they do not and cannot understand. This, on top of discriminatory attitudes and stigma, has led to <a href="https://www.google.com/url?q=http://nosmag.org/mental-age-theory-hurts-people-with-intellectual-disabilities/&amp;sa=D&amp;source=docs&amp;ust=1641598391812179&amp;usg=AOvVaw1oFiTrpzcEMoYjnn3cB96G">infantilization</a>, <a href="https://journals.sagepub.com/doi/full/10.1177/1744629518767001">institutionalization and eugenic sterilization</a>.</p></div>
<div aria-hidden class="svelte-1xg41jv outer">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">These audiences are routinely excluded from public dialogues, including dialogues about themselves. People with disabilities are also often excluded from writing or sharing their own stories first-hand due to lower vocabulary skills, learning differences, and intellectual disabilities. For example, throughout much of US history, people with ID <a href="https://ncd.gov/sites/default/files/NCD_Turning-Rights-into-Reality_508_0.pdf">have had decisions made on their behalf</a> based on the presumption that they do not and cannot understand. This, on top of discriminatory attitudes and stigma, has led to <a href="https://www.google.com/url?q=http://nosmag.org/mental-age-theory-hurts-people-with-intellectual-disabilities/&amp;sa=D&amp;source=docs&amp;ust=1641598391812179&amp;usg=AOvVaw1oFiTrpzcEMoYjnn3cB96G">infantilization</a>, <a href="https://journals.sagepub.com/doi/full/10.1177/1744629518767001">institutionalization and eugenic sterilization</a>.</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">These groups of people get left out of the conversation a lot. Even when the conversation is about them.</p><p class="svelte-1xg41jv">For example, many people think people with ID don’t understand how to make choices for themselves. Nondisabled people make choices for them. These choices sometimes hurt people with ID. Throughout history, many people with ID have been:</p><ul><li>Treated like children.</li><li>Forced to live in institutions, group homes, and nursing homes.</li><li>Forced to have surgery so they could not have children.</li>
</ul>
</button></div>
</div><div class="sr-only"><p>Additionally, there is a tendency to censor content for these audiences rather than explain it, which can contribute to continued disparities, like the <a href="https://thearc.org/wp-content/uploads/forchapters/Sexual%20Violence.pdf">higher rate</a> at which people with ID experience sexual violence than nondisabled people.</p></div>
<div aria-hidden class="svelte-1xg41jv outer">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">Additionally, there is a tendency to censor content for these audiences rather than explain it, which can contribute to continued disparities, like the <a href="https://thearc.org/wp-content/uploads/forchapters/Sexual%20Violence.pdf">higher rate</a> at which people with ID experience sexual violence than nondisabled people.</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">Writers will censor writing for these groups. To censor something means to take out information the writer thinks is not appropriate. Taking out information can make some problems worse.</p><p class="svelte-1xg41jv">For example, people with ID experience sexual violence more than nondisabled people. But some writers think people with ID should not read about sex or sexual violence. So, readers don’t have all the information they need.</p>
</button></div>
</div><div class="sr-only"><p>The benefits of plain language aren’t limited to universally challenging texts like legal documents and tax forms. Even everyday writing, like news articles, can still pose a barrier for some readers.</p></div>
<div aria-hidden class="svelte-1xg41jv outer">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">The benefits of plain language aren’t limited to universally challenging texts like legal documents and tax forms. Even everyday writing, like news articles, can still pose a barrier for some readers.</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">Some kinds of writing are hard for everyone to read, like tax forms. But everyday writing, like the news, can be hard to read too.</p>
</button></div>
</div><p class="sr-only"></p>
<div aria-hidden class="svelte-1xg41jv outer no-plain">

<p class="svelte-1xg41jv inner"><h2 class="text svelte-1xg41jv">How does a human assess readability?</h2></p>
</div><div class="sr-only"><p>Let’s walk through how Rebecca, an expert in plain language, translates a text to be more readable. We'll use an excerpt from her <a href="https://www.propublica.org/article/arizona-promised-to-help-people-with-developmental-disabilities-but-some-had-to-wait-a-long-time-some-did-not-get-help-at-all-plain-text">translation</a> of a <a href="https://www.propublica.org/article/people-with-developmental-disabilities-were-promised-help-instead-they-face-delays-and-denials">ProPublica article</a> by Amy Silverman in the following example.</p></div>
<div aria-hidden class="svelte-1xg41jv outer">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">Let’s walk through how Rebecca, an expert in plain language, translates a text to be more readable. We'll use an excerpt from her <a href="https://www.propublica.org/article/arizona-promised-to-help-people-with-developmental-disabilities-but-some-had-to-wait-a-long-time-some-did-not-get-help-at-all-plain-text">translation</a> of a <a href="https://www.propublica.org/article/people-with-developmental-disabilities-were-promised-help-instead-they-face-delays-and-denials">ProPublica article</a> by Amy Silverman in the following example.</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">Here is an example for how to make writing easier to read. Rebecca wrote this example. She is an expert in plain language. This quote is from a news article. Amy Silverman wrote it for ProPublica. Rebecca wrote it in plain language.</p>
</button></div>
</div><div class="sr-only"><p><span class="tap-icon"></span><strong>Read the translation below.</strong> Click the <span class="highlight">highlights</span> to see what Rebecca thinks.</p></div>
<div aria-hidden class="svelte-1xg41jv outer no-plain">

<div class="svelte-1xg41jv inner info-box"><p class="svelte-1xg41jv"><span class="tap-icon"></span><strong>Read the translation below.</strong> Click the <span class="highlight">highlights</span> to see what Rebecca thinks.</p></div>
</div><figure><figcaption class="sr-only">An example of translating text from standard to plain language where you can select Rebecca's
comments to learn more about her translation process.
</figcaption>

<h3 class="svelte-1yv5b92">Plain language translating: side-by-side comparison</h3>

<div class="container svelte-1yv5b92"><div class="texts svelte-1yv5b92">
<div class="after svelte-1yv5b92"><p class="head svelte-1yv5b92">PLAIN LANGUAGE</p>
<p class="plain-style svelte-1yv5b92"><span class="after-step" id="after-0">Kyra is autistic and deaf.</span> <span class="after-step" id="after-1">She was born early.</span> <span class="after-step" id="after-2">She was very small when she was born.</span> <span class="after-step" id="after-3">She has trouble seeing, hearing, eating and sleeping.</span> <span class="after-step" id="after-4">Her hand shakes so she does not do sign language.</span> <span class="after-step" id="after-5">Her parents think she knows some signs.</span></p></div></div>

<p class="description-title svelte-1yv5b92">Rebecca's comments</p>

</div>
<div class="sr-only"><p>Click the <span class="highlight">highlighted</span> text to see Rebecca's comments.</p></div>
<div aria-hidden class="svelte-1xg41jv outer">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">Click the <span class="highlight">highlighted</span> text to see Rebecca's comments.</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">Click the <span class="highlight">highlighted</span> text to see Rebecca's comments.</p>
</button></div>
</div>
</figure><details class="svelte-192zsyu"><summary class="svelte-192zsyu">More about Rebecca’s translation process</summary>
<div class="sr-only"><p>When doing a plain language translation, my first step is always to do a close read of the original text. I identify the main points, the order information is presented, and any terms or concepts that I think will need to be defined or replaced. I always think to myself “what does this sentence/idea/concept assume the reader already knows?” There is so much implied in how we write, and plain language should aim to make the implicit more explicit.</p></div>
<div aria-hidden class="svelte-1xg41jv outer deep-dive">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">When doing a plain language translation, my first step is always to do a close read of the original text. I identify the main points, the order information is presented, and any terms or concepts that I think will need to be defined or replaced. I always think to myself “what does this sentence/idea/concept assume the reader already knows?” There is so much implied in how we write, and plain language should aim to make the implicit more explicit.</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">My first step is to read the whole paragraph. I look for:</p><ul><li>The main points.</li><li>The order things are written in.</li><li>Any words or ideas that I will need to explain.</li>
</ul><p class="svelte-1xg41jv">A lot of writing assumes the reader already knows something about the topic. Plain language should not assume that. I will explain things fully.</p>
</button></div>
</div><div class="sr-only"><p>Once I start translating, I typically take a paragraph-by-paragraph approach rather than sentence-by-sentence, because often I will need to re-order information, add definitions or examples, or reintroduce characters and ideas at the top of a new paragraph. Focusing too much on the sentence-level translation can mean losing sight of the bigger picture.</p></div>
<div aria-hidden class="svelte-1xg41jv outer deep-dive">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">Once I start translating, I typically take a paragraph-by-paragraph approach rather than sentence-by-sentence, because often I will need to re-order information, add definitions or examples, or reintroduce characters and ideas at the top of a new paragraph. Focusing too much on the sentence-level translation can mean losing sight of the bigger picture.</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">When I write something in plain language, I don’t take every sentence from the original writing. I look at the big ideas. I:</p><ul><li>Put things in a different order.</li><li>Add definitions and examples.</li><li>Remind the reader about key characters and ideas.</li>
</ul>
</button></div>
</div>
</details>
</section>
<section id="part-2" class="svelte-192zsyu"><h2 class="svelte-192zsyu">How do algorithms try to assess readability?</h2>
<div class="sr-only"><p>As more people have recognized the practical value of plain language, researchers have sought to quantify the “plainness” of writing through readability formulas—mathematical models that assign numerical scores to text, indicating how understandable they are.</p></div>
<div aria-hidden class="svelte-1xg41jv outer">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">As more people have recognized the practical value of plain language, researchers have sought to quantify the “plainness” of writing through readability formulas—mathematical models that assign numerical scores to text, indicating how understandable they are.</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">Researchers try to measure how easy something is to read. They use math to give the writing a score. The score tells us how easy something is to read. These are called “readability scores.”</p>
</button></div>
</div><div class="sr-only"><p>Though most readability formulas were designed to offer rough difficulty estimates for specific groups of readers, their usage varies greatly, with the Agency for Healthcare Research and Quality <a href="https://www.ahrq.gov/talkingquality/resources/writing/tip6.html">warning</a> that “these formulas are often interpreted and used in ways that go well beyond what they measure.”</p></div>
<div aria-hidden class="svelte-1xg41jv outer">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">Though most readability formulas were designed to offer rough difficulty estimates for specific groups of readers, their usage varies greatly, with the Agency for Healthcare Research and Quality <a href="https://www.ahrq.gov/talkingquality/resources/writing/tip6.html">warning</a> that “these formulas are often interpreted and used in ways that go well beyond what they measure.”</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">Readability scores just give us an “estimate” about how hard something is to read. That means the scores are not perfect. But they give us a good idea about how hard it might be for different groups of people to read something.</p><p class="svelte-1xg41jv">But the Agency for Healthcare Research and Quality said, “these formulas are often interpreted and used in ways that go well beyond what they measure.” This quote means people use these scores in ways they were not made to be used.</p>
</button></div>
</div><div class="sr-only"><p>Moreover, the simplicity of readability checkers has enabled their widespread adoption. Military engineers use them to help write technical documents. Governments and doctors use them to guide communication for a general audience. Schools and textbook manufacturers use them to tailor reading assignments to particular grade levels and students.</p></div>
<div aria-hidden class="svelte-1xg41jv outer">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">Moreover, the simplicity of readability checkers has enabled their widespread adoption. Military engineers use them to help write technical documents. Governments and doctors use them to guide communication for a general audience. Schools and textbook manufacturers use them to tailor reading assignments to particular grade levels and students.</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">Readability scores are easy to understand. Many people use these scores to help them write. Some groups that use readability scores are:</p><ul><li>The military.</li><li>The government.</li><li>Doctors.</li><li>Schools.</li>
</ul>
</button></div>
</div><div class="sr-only"><p>To better understand how readability scores work—and how they can fail—let’s look at three representative examples.</p></div>
<div aria-hidden class="svelte-1xg41jv outer">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">To better understand how readability scores work—and how they can fail—let’s look at three representative examples.</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">Let’s look at three examples of readability scores. They can help us understand how these scores work and how they can fail.</p>
</button></div>
</div><p class="sr-only"></p>
<div aria-hidden class="svelte-1xg41jv outer no-plain">

<p class="svelte-1xg41jv inner"><h3 class="text svelte-1xg41jv">Algorithm #1: Syllable Count</h3></p>
</div><div class="sr-only"><p>The Flesch-Kincaid Grade level formula looks, in part, at syllable count, based on the idea that words with fewer syllables are easier to understand.</p></div>
<div aria-hidden class="svelte-1xg41jv outer">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">The Flesch-Kincaid Grade level formula looks, in part, at syllable count, based on the idea that words with fewer syllables are easier to understand.</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">The Flesch-Kincaid formula measures two things:</p><ul><li>How long words are.</li><li>How many words are in a sentence.</li>
</ul><p class="svelte-1xg41jv">The formula says the shorter the words and sentence, the easier it is to read.</p>
</button></div>
</div><figure class="container svelte-18drwk1"><figcaption class="sr-only">An interactive showing what the Flesch-Kincaid algorithm considers a easy, medium, and hard
sentence. The algorithm deems sentences with lower syllable counts to be easier, so when long
multisyllabic words are added (even if they are easy words), the algorithm says it's a hard
sentence. If we add short but obscure words, the algorithm thinks it's an easier sentence. We
see that the Flesch-Kincaid algorithm isn't able to handle much complexity when it comes to
assessing readability.</figcaption>

<h3 class="svelte-18drwk1">What happens if we only care about <strong>syllables</strong></h3>

<p class="reading-level svelte-18drwk1">The below text is at a <span class="grade svelte-18drwk1">2.34 (2nd grade)</span>
grade reading level according to Flesch-Kincaid</p>

<div class="container svelte-9tsnz9"><p class="spacer svelte-9tsnz9">The quick brown fox jumped over the lazy dog.</p>

<p class="text hide svelte-9tsnz9" aria-hidden><span id="Flesch-Kincaid-The-0">The </span><span id="Flesch-Kincaid-dun-0">dun </span><span id="Flesch-Kincaid-fox-0">fox </span><span id="Flesch-Kincaid-cleared-0">cleared </span><span id="Flesch-Kincaid-that-0">that </span><span id="Flesch-Kincaid-slouch-0">slouch </span><span id="Flesch-Kincaid-of-0">of </span><span id="Flesch-Kincaid-a-0">a </span><span id="Flesch-Kincaid-dog-0">dog </span><span id="Flesch-Kincaid-at-0">at </span><span id="Flesch-Kincaid-full-0">full </span><span id="Flesch-Kincaid-tilt-0">tilt. </span></p>
<p class="text hide svelte-9tsnz9" aria-hidden><span id="Flesch-Kincaid-The-1">The </span><span id="Flesch-Kincaid-quick-1">quick </span><span id="Flesch-Kincaid-brown-1">brown </span><span id="Flesch-Kincaid-fox-1">fox </span><span id="Flesch-Kincaid-jumped-1">jumped </span><span id="Flesch-Kincaid-over-1">over </span><span id="Flesch-Kincaid-the-1">the </span><span id="Flesch-Kincaid-lazy-1">lazy </span><span id="Flesch-Kincaid-dog-1">dog. </span></p>
<p class="text hide svelte-9tsnz9" aria-hidden><span id="Flesch-Kincaid-The-2">The </span><span id="Flesch-Kincaid-wonderful-2">wonderful, </span><span id="Flesch-Kincaid-beautiful-2">beautiful </span><span id="Flesch-Kincaid-fox-2">fox </span><span id="Flesch-Kincaid-jumped-2">jumped </span><span id="Flesch-Kincaid-over-2">over </span><span id="Flesch-Kincaid-the-2">the </span><span id="Flesch-Kincaid-unbelievably-2">unbelievably </span><span id="Flesch-Kincaid-lazy-2">lazy </span><span id="Flesch-Kincaid-dog-2">dog. </span></p>


</div>
<p class="explanation svelte-18drwk1">The two factors considered by Flesch–Kincaid are number of words per sentence and number of syllables per word. This is a short sentence with only two multi-syllable words (<strong>“over”</strong> and <strong>“lazy”</strong>), so the Flesch–Kincaid formula assigns it a low grade level.</p>
</figure><details class="svelte-192zsyu"><summary class="svelte-192zsyu">More about this algorithm</summary>
<div class="sr-only"><p>The author Rudolf Flesch made a career as an early evangelist for plain language in the mid-20th century, promoting his namesake Flesch Reading-Ease Test and its cousin, the Flesch-Kincaid Grade Level Formula, developed in 1975 under contract with the U.S. Navy. It was calibrated on the reading comprehension scores of 531 enlisted Navy personnel, in order to measure readability in the specific context of technical communication. Today, perhaps thanks to its misleading name, the F-K Grade Level Formula is used in schools to estimate reading difficulty for children, overlooking the obvious fact that elementary school students and naval cadets may not agree on whether the same text is easy or difficult to understand.</p></div>
<div aria-hidden class="svelte-1xg41jv outer deep-dive">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">The author Rudolf Flesch made a career as an early evangelist for plain language in the mid-20th century, promoting his namesake Flesch Reading-Ease Test and its cousin, the Flesch-Kincaid Grade Level Formula, developed in 1975 under contract with the U.S. Navy. It was calibrated on the reading comprehension scores of 531 enlisted Navy personnel, in order to measure readability in the specific context of technical communication. Today, perhaps thanks to its misleading name, the F-K Grade Level Formula is used in schools to estimate reading difficulty for children, overlooking the obvious fact that elementary school students and naval cadets may not agree on whether the same text is easy or difficult to understand.</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">Rudolf Flesch was an author. He lived in the 1900s. He thought plain language was very important. He made two scores to measure how easy something was to read:</p><ul><li>The Flesch Reading-Ease Test</li><li>The Flesch-Kincaid Grade Level Formula</li>
</ul><p class="svelte-1xg41jv">Rudolf Flesch created the Flesch-Kincaid Grade Level Formula when he was working for the Navy. He measured how well 531 people in the Navy could read technical communications. Technical communications have special information that people in the Navy need to do their jobs.</p><p class="svelte-1xg41jv">Now we use the Flesch-Kincaid Grade Level Formula to measure readings for children. But the score has never been tested with children.</p>
</button></div>
</div>
</details><p class="sr-only"></p>
<div aria-hidden class="svelte-1xg41jv outer no-plain">

<p class="svelte-1xg41jv inner"><h3 class="text svelte-1xg41jv">Algorithm #2: Difficult words</h3></p>
</div><div class="sr-only"><p>The Dale-Chall Readability Formula considers the proportion of difficult words, where it deems a word “difficult” if it is not on a list of 3,000 words familiar to fourth-grade students.</p></div>
<div aria-hidden class="svelte-1xg41jv outer">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">The Dale-Chall Readability Formula considers the proportion of difficult words, where it deems a word “difficult” if it is not on a list of 3,000 words familiar to fourth-grade students.</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">Dale-Chall is another readability score. It measures two things:</p><ul><li>How long each sentence is.</li><li>The number of easy or hard words.</li>
</ul><p class="svelte-1xg41jv">Dale-Chall uses a list of 3,000 easy words. Dale-Chall says these are words most 4th graders know. Any other word is a hard word.</p>
</button></div>
</div><div class="sr-only"><p>One risk in the use of vocabulary lists is that the vocabulary of the readers surveyed to create them may not match the vocabulary of the intended audience. The original Dale-Chall list of “familiar words” was compiled in 1948 through a survey of U.S. fourth-graders, and even the most recent update to the list in 1995 retains obsolete words like “Negro” and “homely” while omitting “computer.”</p></div>
<div aria-hidden class="svelte-1xg41jv outer">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">One risk in the use of vocabulary lists is that the vocabulary of the readers surveyed to create them may not match the vocabulary of the intended audience. The original Dale-Chall list of “familiar words” was compiled in 1948 through a survey of U.S. fourth-graders, and even the most recent update to the list in 1995 retains obsolete words like “Negro” and “homely” while omitting “computer.”</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">But not everyone knows the same words. Dale-Chall made the first easy word list in 1948. They updated the list in 1995.</p><p class="svelte-1xg41jv">We don’t use the same words now that we did back then. The list has words most people don’t use now, like “Negro” and “homely.” And it doesn’t have words a lot of people use now, like “computer.”</p>
</button></div>
</div><figure class="container svelte-18drwk1"><figcaption class="sr-only">An interactive showing what the Dale-Chall algorithm considers a easy, medium, and hard
sentence. Dale-Chall considers average sentence length along with how many difficult words are
used, where “difficult” words are words that don't appear on the Dale-Chall list. If we add
words that are unfamiliar (like dinosaur or dude) the algorithm says it's a difficult
sentence. If we simply add a sentence that just contains the exclamation "Yes!", that lowers
the average sentence length and makes the algorithm say it's an easier sentence. We see that
the Dale-Chall algorithm isn't able to handle much complexity when it comes to assessing
readability.</figcaption>

<h3 class="svelte-18drwk1">What happens if we only care about <strong>“difficult” words</strong></h3>

<p class="reading-level svelte-18drwk1">The below text is at a <span class="grade svelte-18drwk1">0.45 (4th grade or below)</span>
grade reading level according to Dale-Chall</p>

<div class="container svelte-9tsnz9"><p class="spacer svelte-9tsnz9">The quick brown fox jumped over the lazy dog.</p>

<p class="text hide svelte-9tsnz9" aria-hidden><span id="Dale-Chall-Yes-0">Yes! </span><span id="Dale-Chall-The-0">The </span><span id="Dale-Chall-quick-0">quick </span><span id="Dale-Chall-brown-0">brown </span><span id="Dale-Chall-fox-0">fox </span><span id="Dale-Chall-jumped-0">jumped </span><span id="Dale-Chall-over-0">over </span><span id="Dale-Chall-the-0">the </span><span id="Dale-Chall-lazy-0">lazy </span><span id="Dale-Chall-dog-0">dog. </span></p>
<p class="text hide svelte-9tsnz9" aria-hidden><span id="Dale-Chall-The-1">The </span><span id="Dale-Chall-quick-1">quick </span><span id="Dale-Chall-brown-1">brown </span><span id="Dale-Chall-fox-1">fox </span><span id="Dale-Chall-jumped-1">jumped </span><span id="Dale-Chall-over-1">over </span><span id="Dale-Chall-the-1">the </span><span id="Dale-Chall-lazy-1">lazy </span><span id="Dale-Chall-dog-1">dog. </span></p>
<p class="text hide svelte-9tsnz9" aria-hidden><span id="Dale-Chall-The-2">The </span><span id="Dale-Chall-quick-2">quick </span><span id="Dale-Chall-brown-2">brown </span><span id="Dale-Chall-dinosaur-2">dinosaur </span><span id="Dale-Chall-jumped-2">jumped </span><span id="Dale-Chall-over-2">over </span><span id="Dale-Chall-the-2">the </span><span id="Dale-Chall-lazy-2">lazy </span><span id="Dale-Chall-dude-2">dude. </span></p>


</div>
<p class="explanation svelte-18drwk1">Dale–Chall considers average sentence length along with percentage of difficult words (PDW), where “difficult” words are words that don't appear on the Dale–Chall list. This is a short sentence made entirely of words on the Dale–Chall list, so its ASL score is low and its PDW score is zero, yielding a score of 0.45. Since the formula was calibrated on a group of 4th grade students, all scores below 5.0 are collapsed into a single readability category representing “4th grade and below.”</p>
</figure><p class="sr-only"></p>
<div aria-hidden class="svelte-1xg41jv outer no-plain">

<p class="svelte-1xg41jv inner"><h3 class="text svelte-1xg41jv">Algorithm #3: Algorithmic black boxes</h3></p>
</div><div class="sr-only"><p>More recently, US schools and textbook manufacturers have standardized their curricula on the Lexile Framework for Reading, a set of readability algorithms and vocabulary lists designed to automatically match students with appropriately difficult books. Publishers apply Lexile to their texts to rate their difficulty. A Lexile score of 210 indicates an easy-to-read book, while a score of 1730 indicates a very challenging one. A reading comprehension test assigns a corresponding reading score to each student, after which teachers pair students with texts that have comparable Lexile scores.</p></div>
<div aria-hidden class="svelte-1xg41jv outer">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">More recently, US schools and textbook manufacturers have standardized their curricula on the Lexile Framework for Reading, a set of readability algorithms and vocabulary lists designed to automatically match students with appropriately difficult books. Publishers apply Lexile to their texts to rate their difficulty. A Lexile score of 210 indicates an easy-to-read book, while a score of 1730 indicates a very challenging one. A reading comprehension test assigns a corresponding reading score to each student, after which teachers pair students with texts that have comparable Lexile scores.</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">Lexile Framework for Reading is another formula to measure how easy something is to read. Schools and textbook writers use Lexile. Lexile helps match students with books they are able to read.</p><p class="svelte-1xg41jv">Here is how it works:</p><ul><li>Lexile scores books. It rates them as easy or hard to read.</li><li>Students take a reading test. It tells them how well they read.</li><li>Teachers give students books that won’t be too easy or too hard for them to read.</li>
</ul>
</button></div>
</div><div class="sr-only"><p>The approach sounds simple enough, but critics have pointed out absurdities in Lexile's results. According to Lexile, The Grapes of Wrath (Lexile score: 680) is easier to understand than the Nancy Drew mystery Nancy's Mysterious Letter (score: 720), but neither of these is as challenging as The Library Mouse (score: 860), a 32-page illustrated children's book.</p></div>
<div aria-hidden class="svelte-1xg41jv outer">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">The approach sounds simple enough, but critics have pointed out absurdities in Lexile's results. According to Lexile, The Grapes of Wrath (Lexile score: 680) is easier to understand than the Nancy Drew mystery Nancy's Mysterious Letter (score: 720), but neither of these is as challenging as The Library Mouse (score: 860), a 32-page illustrated children's book.</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">But the scores Lexile gives books don’t always make sense. Here’s an example. Lexile says:</p><ul><li>Lexile says that The Grapes of Wrath is a pretty easy book to read. The Grapes of Wrath is a book for adults. It is over 400 pages long and has many complex themes and ideas.</li><li>Lexile says the Nancy Drew book Nancy’s Mysterious Letter is harder to read than The Grapes of Wrath. Nancy Drew books are made for preteens. Most people would consider it much easier to read than The Grapes of Wrath.</li><li>Lexile says The Library Mouse is harder to read than the Nancy Drew book or The Grapes of Wrath. The Library Mouse is a picture book for children.</li>
</ul><p class="svelte-1xg41jv">It does not make sense that a children’s picture book would be harder to read than a book for adults.</p>
</button></div>
</div><figure class="container svelte-19y896n"><figcaption class="sr-only">Images of three book covers arranged by how difficult the Lexile algorithm thinks they are. It
says Grapes of Wrath is the easiest, followed by Nancy's Mysterious Letter, and the hardest is
The Library Mouse, a 32-page illustrated children's book. This doesn't make much sense, most
people would say that Grapes of Wrath is much more difficult than a simple children's book.
</figcaption>

<h3 class="svelte-19y896n">How Lexile scores popular books for children</h3>
<div class="books svelte-19y896n"><div class="book svelte-19y896n"><img src="assets/img/grapes.jpeg" alt="the grapes of wrath cover" class=" svelte-19y896n">
<p class="score svelte-19y896n">680</p>
<p class="grade svelte-19y896n">(5th grade)</p>
</div><div class="book svelte-19y896n"><img src="assets/img/nancy.jpeg" alt="nancy drew cover" class=" svelte-19y896n">
<p class="score svelte-19y896n">720</p>
<p class="grade svelte-19y896n">(7th grade)</p>
</div><div class="book svelte-19y896n"><img src="assets/img/mouse.jpeg" alt="the library mouse cover" class=" svelte-19y896n">
<p class="score svelte-19y896n">860</p>
<p class="grade svelte-19y896n">(10th grade)</p>
</div></div>
</figure><div class="sr-only"><p>How exactly are Lexile scores calculated? Unfortunately for us, the Lexile Framework is the intellectual property of MetaMetrics, the private company that created it, so we can only guess at the secret recipe, but it's a pretty good bet that Lexile scores depend on a mixture of the same factors used in Flesch–Kincaid and other open-source readability measures.</p></div>
<div aria-hidden class="svelte-1xg41jv outer">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">How exactly are Lexile scores calculated? Unfortunately for us, the Lexile Framework is the intellectual property of MetaMetrics, the private company that created it, so we can only guess at the secret recipe, but it's a pretty good bet that Lexile scores depend on a mixture of the same factors used in Flesch–Kincaid and other open-source readability measures.</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">We don’t know how Lexile decides how hard each book is. MetaMetrics is the company that made Lexile. They do not share what math they do to get their readability scores. But it is probably close to the other formulas we looked at. We know Lexile looks at:</p><ul><li>How long words are.</li><li>How long each sentence is.</li><li>How familiar the words are.</li><li>If things are repeated.</li>
</ul>
</button></div>
</div><div class="sr-only"><p>Formulas based on surface level text properties and word frequency have clear limitations. None of them consider how well organized the information is, or whether the sentences and paragraphs are coherent. None consider the role of grammatical tense. None account for the explanation of acronyms and jargon. None would balk at Jack Torrance's rambling and meaningless draft in The Shining, endlessly repeating “All work and no play makes Jack a dull boy.”</p></div>
<div aria-hidden class="svelte-1xg41jv outer">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">Formulas based on surface level text properties and word frequency have clear limitations. None of them consider how well organized the information is, or whether the sentences and paragraphs are coherent. None consider the role of grammatical tense. None account for the explanation of acronyms and jargon. None would balk at Jack Torrance's rambling and meaningless draft in The Shining, endlessly repeating “All work and no play makes Jack a dull boy.”</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">None of these formulas are perfect. They don’t measure:</p><ul><li>The order of the sentences.</li><li>If the writing makes sense.</li><li>Grammar.</li><li>If the writer explains hard words and phrases.</li>
</ul><p class="svelte-1xg41jv">These formulas would have no problem with the scene in The Shining where Jack Torrance writes “All work and no play makes Jack a dull boy,” over and over again. They do not check if the writing means anything.</p>
</button></div>
</div><div class="sr-only"><p>But proprietary tech like Lexile has some of the most disconcerting aspects of both worlds. As flawed as Flesch-Kincaid or Dale-Chall, but opaque and unexplainable. The main benefit of the F-K and D-C formulas (and other simple algorithms like Gunning-Fog and SMOG) is their transparency. A broken system locked in a black box can't even offer this.</p></div>
<div aria-hidden class="svelte-1xg41jv outer">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">But proprietary tech like Lexile has some of the most disconcerting aspects of both worlds. As flawed as Flesch-Kincaid or Dale-Chall, but opaque and unexplainable. The main benefit of the F-K and D-C formulas (and other simple algorithms like Gunning-Fog and SMOG) is their transparency. A broken system locked in a black box can't even offer this.</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">At least we know how Flesch-Kincaid and Dale-Chall work. They are not perfect but we can explain them. We don’t even know what Lexile measures.</p>
</button></div>
</div>
</section>
<div class="svelte-16d9zvc"><h3>Authors' note</h3>

<p>A lot of people helped us write this article.</p><p>Thank you to Zoe Gross and Leah Mapstead for being our expert readers. Zoe and Leah told us how to make the article better. Zoe is Director of Advocacy at the Autistic Self-Advocacy Network. Leah is a disability advocate and actor.</p><p>Thank you to:</p><p>They made our article interactive. They helped brainstorm ideas. They told us how to make our writing better.</p><p>Thank you to Matt Hackert for making sure the article works on a screen reader. Matt leads the Center of Excellence in Nonvisual Accessibility at the National Federation of the Blind.</p><p>Thank you to Amy Silverman for helping come up with the idea for this article.</p><p>You can learn more about Kyra <a href="https://www.propublica.org/article/people-with-developmental-disabilities-were-promised-help-instead-they-face-delays-and-denials">here</a>.</p><p>You can learn more about how to write plain language and Easy Read <a href="https://autisticadvocacy.org/resources/accessibility/easyread/">here</a>, <a href="https://www.plainlanguage.gov/">here</a>, and <a href="https://www.easy-read-online.co.uk/media/10609/making-myself-clear.pdf">here</a>.</p>
</div>
</article>


<hr>

<footer>
<p>
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="/david/log/" title="Accès au flux RSS"><svg class="icon icon-rss2">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-rss2"></use>
</svg> Suivre</a> •
<a href="http://larlet.com" title="Go to my English profile" data-instant><svg class="icon icon-user-tie">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-user-tie"></use>
</svg> Pro</a> •
<a href="mailto:david%40larlet.fr" title="Envoyer un courriel"><svg class="icon icon-mail">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-mail"></use>
</svg> Email</a> •
<abbr class="nowrap" title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340"><svg class="icon icon-hammer2">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-hammer2"></use>
</svg> Légal</abbr>
</p>
<template id="theme-selector">
<form>
<fieldset>
<legend><svg class="icon icon-brightness-contrast">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-brightness-contrast"></use>
</svg> Thème</legend>
<label>
<input type="radio" value="auto" name="chosen-color-scheme" checked> Auto
</label>
<label>
<input type="radio" value="dark" name="chosen-color-scheme"> Foncé
</label>
<label>
<input type="radio" value="light" name="chosen-color-scheme"> Clair
</label>
</fieldset>
</form>
</template>
</footer>
<script src="/static/david/js/instantpage-5.1.0.min.js" type="module"></script>
<script>
function loadThemeForm(templateName) {
const themeSelectorTemplate = document.querySelector(templateName)
const form = themeSelectorTemplate.content.firstElementChild
themeSelectorTemplate.replaceWith(form)

form.addEventListener('change', (e) => {
const chosenColorScheme = e.target.value
localStorage.setItem('theme', chosenColorScheme)
toggleTheme(chosenColorScheme)
})

const selectedTheme = localStorage.getItem('theme')
if (selectedTheme && selectedTheme !== 'undefined') {
form.querySelector(`[value="${selectedTheme}"]`).checked = true
}
}

const prefersColorSchemeDark = '(prefers-color-scheme: dark)'
window.addEventListener('load', () => {
let hasDarkRules = false
for (const styleSheet of Array.from(document.styleSheets)) {
let mediaRules = []
for (const cssRule of styleSheet.cssRules) {
if (cssRule.type !== CSSRule.MEDIA_RULE) {
continue
}
// WARNING: Safari does not have/supports `conditionText`.
if (cssRule.conditionText) {
if (cssRule.conditionText !== prefersColorSchemeDark) {
continue
}
} else {
if (cssRule.cssText.startsWith(prefersColorSchemeDark)) {
continue
}
}
mediaRules = mediaRules.concat(Array.from(cssRule.cssRules))
}

// WARNING: do not try to insert a Rule to a styleSheet you are
// currently iterating on, otherwise the browser will be stuck
// in a infinite loop…
for (const mediaRule of mediaRules) {
styleSheet.insertRule(mediaRule.cssText)
hasDarkRules = true
}
}
if (hasDarkRules) {
loadThemeForm('#theme-selector')
}
})
</script>
</body>
</html>

+ 274
- 0
cache/2022/0dc625e86fb8e680308250b1245f1086/index.md View File

@@ -0,0 +1,274 @@
title: What makes writing more readable?
url: https://pudding.cool/2022/02/plain/
hash_url: 0dc625e86fb8e680308250b1245f1086

<div class="toggle svelte-1k1jl04"><p class="sr-only">The following is a toggle that allows you to change whether the text is standard or translated
into plain language. Press the p key at any time to switch between standard and plain language
versions of the article. If you are using a screen reader, you will need to disable your the quick
navigation keyboard commands in order for the P key to function.
</p>

<p class="toggle toggle--inner svelte-1nyzcas"><span class="label svelte-1nyzcas" id="toggle-471912">Plain Language</span>
<button role="switch" aria-checked="false" aria-labelledby="toggle-471912" class="svelte-1nyzcas"><span class="svelte-1nyzcas">on</span>
<span class="svelte-1nyzcas">off</span></button></p>
<p aria-hidden class="use-keyboard plain-style svelte-1nyzcas">(Or use the "p" key)</p></div>

<section id="part-1" class="svelte-192zsyu">
<div class="sr-only"><p>Writing text that can be understood by as many people as possible seems like an obvious best practice. But from news media to legal guidance to academic research, the way we write often creates barriers to who can read it. Plain language—a style of writing that uses simplified sentences, everyday vocabulary, and clear structure—aims to remove those barriers.</p></div>
<div aria-hidden class="svelte-1xg41jv outer">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">Writing text that can be understood by as many people as possible seems like an obvious best practice. But from news media to legal guidance to academic research, the way we write often creates barriers to who can read it. Plain language—a style of writing that uses simplified sentences, everyday vocabulary, and clear structure—aims to remove those barriers.</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">Good writing is easy to read. But a lot of writing is hard to read. Some people can’t read hard writing. Plain language fixes this problem. It makes writing easy to read for more people.</p>
</button></div>
</div><div class="sr-only"><p><span class="tap-icon"></span><strong>You can see it in action right here!</strong> Click the text next to each paragraph to read it in <span class="plain-style">plain language</span>.</p></div>
<div aria-hidden class="svelte-1xg41jv outer no-plain">

<div class="svelte-1xg41jv inner info-box"><p class="svelte-1xg41jv"><span class="tap-icon"></span><strong>You can see it in action right here!</strong> Click the text next to each paragraph to read it in <span class="plain-style">plain language</span>.</p></div>
</div><div class="sr-only"><p>You can also use the toggle on the top right to switch <strong>everything</strong> to <span class="plain-style">plain language</span>. Or use the <span class="plain-style">“p”</span> key on your keyboard.</p></div>
<div aria-hidden class="svelte-1xg41jv outer no-plain">

<div class="svelte-1xg41jv inner info-box"><p class="svelte-1xg41jv">You can also use the toggle on the top right to switch <strong>everything</strong> to <span class="plain-style">plain language</span>. Or use the <span class="plain-style">“p”</span> key on your keyboard.</p></div>
</div>
<div aria-hidden class="svelte-1xg41jv outer">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">Plain language is useful for everyone, but especially for those who are often denied the opportunity to engage with and comment on public writing. This includes the <a href="https://www.ncld.org/research/state-of-learning-disabilities">20% of the population with learning disabilities</a>, a number of the <a href="https://ici-s.umn.edu/files/aCHyYaFjMi/risp_2017">more than 7 million people in the US</a> with intellectual disabilities (ID), readers for whom English is not a first language and people with limited access to education, among others.</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">Plain language is helpful for everyone. But it is really good for people who may find other kinds of writing hard to read. That includes:</p><ul><li>People with learning disabilities.</li><li>People with intellectual disabilities (ID).</li><li>People who are learning to speak English.</li><li>People who did not go to school or went to school less than they wanted to.</li>
</ul>
</button></div>
</div><div class="sr-only"><p>These audiences are routinely excluded from public dialogues, including dialogues about themselves. People with disabilities are also often excluded from writing or sharing their own stories first-hand due to lower vocabulary skills, learning differences, and intellectual disabilities. For example, throughout much of US history, people with ID <a href="https://ncd.gov/sites/default/files/NCD_Turning-Rights-into-Reality_508_0.pdf">have had decisions made on their behalf</a> based on the presumption that they do not and cannot understand. This, on top of discriminatory attitudes and stigma, has led to <a href="https://www.google.com/url?q=http://nosmag.org/mental-age-theory-hurts-people-with-intellectual-disabilities/&amp;sa=D&amp;source=docs&amp;ust=1641598391812179&amp;usg=AOvVaw1oFiTrpzcEMoYjnn3cB96G">infantilization</a>, <a href="https://journals.sagepub.com/doi/full/10.1177/1744629518767001">institutionalization and eugenic sterilization</a>.</p></div>
<div aria-hidden class="svelte-1xg41jv outer">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">These audiences are routinely excluded from public dialogues, including dialogues about themselves. People with disabilities are also often excluded from writing or sharing their own stories first-hand due to lower vocabulary skills, learning differences, and intellectual disabilities. For example, throughout much of US history, people with ID <a href="https://ncd.gov/sites/default/files/NCD_Turning-Rights-into-Reality_508_0.pdf">have had decisions made on their behalf</a> based on the presumption that they do not and cannot understand. This, on top of discriminatory attitudes and stigma, has led to <a href="https://www.google.com/url?q=http://nosmag.org/mental-age-theory-hurts-people-with-intellectual-disabilities/&amp;sa=D&amp;source=docs&amp;ust=1641598391812179&amp;usg=AOvVaw1oFiTrpzcEMoYjnn3cB96G">infantilization</a>, <a href="https://journals.sagepub.com/doi/full/10.1177/1744629518767001">institutionalization and eugenic sterilization</a>.</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">These groups of people get left out of the conversation a lot. Even when the conversation is about them.</p><p class="svelte-1xg41jv">For example, many people think people with ID don’t understand how to make choices for themselves. Nondisabled people make choices for them. These choices sometimes hurt people with ID. Throughout history, many people with ID have been:</p><ul><li>Treated like children.</li><li>Forced to live in institutions, group homes, and nursing homes.</li><li>Forced to have surgery so they could not have children.</li>
</ul>
</button></div>
</div><div class="sr-only"><p>Additionally, there is a tendency to censor content for these audiences rather than explain it, which can contribute to continued disparities, like the <a href="https://thearc.org/wp-content/uploads/forchapters/Sexual%20Violence.pdf">higher rate</a> at which people with ID experience sexual violence than nondisabled people.</p></div>
<div aria-hidden class="svelte-1xg41jv outer">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">Additionally, there is a tendency to censor content for these audiences rather than explain it, which can contribute to continued disparities, like the <a href="https://thearc.org/wp-content/uploads/forchapters/Sexual%20Violence.pdf">higher rate</a> at which people with ID experience sexual violence than nondisabled people.</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">Writers will censor writing for these groups. To censor something means to take out information the writer thinks is not appropriate. Taking out information can make some problems worse.</p><p class="svelte-1xg41jv">For example, people with ID experience sexual violence more than nondisabled people. But some writers think people with ID should not read about sex or sexual violence. So, readers don’t have all the information they need.</p>
</button></div>
</div><div class="sr-only"><p>The benefits of plain language aren’t limited to universally challenging texts like legal documents and tax forms. Even everyday writing, like news articles, can still pose a barrier for some readers.</p></div>
<div aria-hidden class="svelte-1xg41jv outer">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">The benefits of plain language aren’t limited to universally challenging texts like legal documents and tax forms. Even everyday writing, like news articles, can still pose a barrier for some readers.</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">Some kinds of writing are hard for everyone to read, like tax forms. But everyday writing, like the news, can be hard to read too.</p>
</button></div>
</div><p class="sr-only"></p>
<div aria-hidden class="svelte-1xg41jv outer no-plain">

<p class="svelte-1xg41jv inner"><h2 class="text svelte-1xg41jv">How does a human assess readability?</h2></p>
</div><div class="sr-only"><p>Let’s walk through how Rebecca, an expert in plain language, translates a text to be more readable. We'll use an excerpt from her <a href="https://www.propublica.org/article/arizona-promised-to-help-people-with-developmental-disabilities-but-some-had-to-wait-a-long-time-some-did-not-get-help-at-all-plain-text">translation</a> of a <a href="https://www.propublica.org/article/people-with-developmental-disabilities-were-promised-help-instead-they-face-delays-and-denials">ProPublica article</a> by Amy Silverman in the following example.</p></div>
<div aria-hidden class="svelte-1xg41jv outer">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">Let’s walk through how Rebecca, an expert in plain language, translates a text to be more readable. We'll use an excerpt from her <a href="https://www.propublica.org/article/arizona-promised-to-help-people-with-developmental-disabilities-but-some-had-to-wait-a-long-time-some-did-not-get-help-at-all-plain-text">translation</a> of a <a href="https://www.propublica.org/article/people-with-developmental-disabilities-were-promised-help-instead-they-face-delays-and-denials">ProPublica article</a> by Amy Silverman in the following example.</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">Here is an example for how to make writing easier to read. Rebecca wrote this example. She is an expert in plain language. This quote is from a news article. Amy Silverman wrote it for ProPublica. Rebecca wrote it in plain language.</p>
</button></div>
</div><div class="sr-only"><p><span class="tap-icon"></span><strong>Read the translation below.</strong> Click the <span class="highlight">highlights</span> to see what Rebecca thinks.</p></div>
<div aria-hidden class="svelte-1xg41jv outer no-plain">

<div class="svelte-1xg41jv inner info-box"><p class="svelte-1xg41jv"><span class="tap-icon"></span><strong>Read the translation below.</strong> Click the <span class="highlight">highlights</span> to see what Rebecca thinks.</p></div>
</div><figure><figcaption class="sr-only">An example of translating text from standard to plain language where you can select Rebecca's
comments to learn more about her translation process.
</figcaption>

<h3 class="svelte-1yv5b92">Plain language translating: side-by-side comparison</h3>

<div class="container svelte-1yv5b92"><div class="texts svelte-1yv5b92">
<div class="after svelte-1yv5b92"><p class="head svelte-1yv5b92">PLAIN LANGUAGE</p>
<p class="plain-style svelte-1yv5b92"><span class="after-step" id="after-0">Kyra is autistic and deaf.</span> <span class="after-step" id="after-1">She was born early.</span> <span class="after-step" id="after-2">She was very small when she was born.</span> <span class="after-step" id="after-3">She has trouble seeing, hearing, eating and sleeping.</span> <span class="after-step" id="after-4">Her hand shakes so she does not do sign language.</span> <span class="after-step" id="after-5">Her parents think she knows some signs.</span></p></div></div>

<p class="description-title svelte-1yv5b92">Rebecca's comments</p>

</div>
<div class="sr-only"><p>Click the <span class="highlight">highlighted</span> text to see Rebecca's comments.</p></div>
<div aria-hidden class="svelte-1xg41jv outer">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">Click the <span class="highlight">highlighted</span> text to see Rebecca's comments.</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">Click the <span class="highlight">highlighted</span> text to see Rebecca's comments.</p>
</button></div>
</div>
</figure><details class="svelte-192zsyu"><summary class="svelte-192zsyu">More about Rebecca’s translation process</summary>
<div class="sr-only"><p>When doing a plain language translation, my first step is always to do a close read of the original text. I identify the main points, the order information is presented, and any terms or concepts that I think will need to be defined or replaced. I always think to myself “what does this sentence/idea/concept assume the reader already knows?” There is so much implied in how we write, and plain language should aim to make the implicit more explicit.</p></div>
<div aria-hidden class="svelte-1xg41jv outer deep-dive">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">When doing a plain language translation, my first step is always to do a close read of the original text. I identify the main points, the order information is presented, and any terms or concepts that I think will need to be defined or replaced. I always think to myself “what does this sentence/idea/concept assume the reader already knows?” There is so much implied in how we write, and plain language should aim to make the implicit more explicit.</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">My first step is to read the whole paragraph. I look for:</p><ul><li>The main points.</li><li>The order things are written in.</li><li>Any words or ideas that I will need to explain.</li>
</ul><p class="svelte-1xg41jv">A lot of writing assumes the reader already knows something about the topic. Plain language should not assume that. I will explain things fully.</p>
</button></div>
</div><div class="sr-only"><p>Once I start translating, I typically take a paragraph-by-paragraph approach rather than sentence-by-sentence, because often I will need to re-order information, add definitions or examples, or reintroduce characters and ideas at the top of a new paragraph. Focusing too much on the sentence-level translation can mean losing sight of the bigger picture.</p></div>
<div aria-hidden class="svelte-1xg41jv outer deep-dive">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">Once I start translating, I typically take a paragraph-by-paragraph approach rather than sentence-by-sentence, because often I will need to re-order information, add definitions or examples, or reintroduce characters and ideas at the top of a new paragraph. Focusing too much on the sentence-level translation can mean losing sight of the bigger picture.</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">When I write something in plain language, I don’t take every sentence from the original writing. I look at the big ideas. I:</p><ul><li>Put things in a different order.</li><li>Add definitions and examples.</li><li>Remind the reader about key characters and ideas.</li>
</ul>
</button></div>
</div>
</details>
</section><section id="part-2" class="svelte-192zsyu"><h2 class="svelte-192zsyu">How do algorithms try to assess readability?</h2>
<div class="sr-only"><p>As more people have recognized the practical value of plain language, researchers have sought to quantify the “plainness” of writing through readability formulas—mathematical models that assign numerical scores to text, indicating how understandable they are.</p></div>
<div aria-hidden class="svelte-1xg41jv outer">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">As more people have recognized the practical value of plain language, researchers have sought to quantify the “plainness” of writing through readability formulas—mathematical models that assign numerical scores to text, indicating how understandable they are.</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">Researchers try to measure how easy something is to read. They use math to give the writing a score. The score tells us how easy something is to read. These are called “readability scores.”</p>
</button></div>
</div><div class="sr-only"><p>Though most readability formulas were designed to offer rough difficulty estimates for specific groups of readers, their usage varies greatly, with the Agency for Healthcare Research and Quality <a href="https://www.ahrq.gov/talkingquality/resources/writing/tip6.html">warning</a> that “these formulas are often interpreted and used in ways that go well beyond what they measure.”</p></div>
<div aria-hidden class="svelte-1xg41jv outer">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">Though most readability formulas were designed to offer rough difficulty estimates for specific groups of readers, their usage varies greatly, with the Agency for Healthcare Research and Quality <a href="https://www.ahrq.gov/talkingquality/resources/writing/tip6.html">warning</a> that “these formulas are often interpreted and used in ways that go well beyond what they measure.”</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">Readability scores just give us an “estimate” about how hard something is to read. That means the scores are not perfect. But they give us a good idea about how hard it might be for different groups of people to read something.</p><p class="svelte-1xg41jv">But the Agency for Healthcare Research and Quality said, “these formulas are often interpreted and used in ways that go well beyond what they measure.” This quote means people use these scores in ways they were not made to be used.</p>
</button></div>
</div><div class="sr-only"><p>Moreover, the simplicity of readability checkers has enabled their widespread adoption. Military engineers use them to help write technical documents. Governments and doctors use them to guide communication for a general audience. Schools and textbook manufacturers use them to tailor reading assignments to particular grade levels and students.</p></div>
<div aria-hidden class="svelte-1xg41jv outer">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">Moreover, the simplicity of readability checkers has enabled their widespread adoption. Military engineers use them to help write technical documents. Governments and doctors use them to guide communication for a general audience. Schools and textbook manufacturers use them to tailor reading assignments to particular grade levels and students.</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">Readability scores are easy to understand. Many people use these scores to help them write. Some groups that use readability scores are:</p><ul><li>The military.</li><li>The government.</li><li>Doctors.</li><li>Schools.</li>
</ul>
</button></div>
</div><div class="sr-only"><p>To better understand how readability scores work—and how they can fail—let’s look at three representative examples.</p></div>
<div aria-hidden class="svelte-1xg41jv outer">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">To better understand how readability scores work—and how they can fail—let’s look at three representative examples.</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">Let’s look at three examples of readability scores. They can help us understand how these scores work and how they can fail.</p>
</button></div>
</div><p class="sr-only"></p>
<div aria-hidden class="svelte-1xg41jv outer no-plain">

<p class="svelte-1xg41jv inner"><h3 class="text svelte-1xg41jv">Algorithm #1: Syllable Count</h3></p>
</div><div class="sr-only"><p>The Flesch-Kincaid Grade level formula looks, in part, at syllable count, based on the idea that words with fewer syllables are easier to understand.</p></div>
<div aria-hidden class="svelte-1xg41jv outer">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">The Flesch-Kincaid Grade level formula looks, in part, at syllable count, based on the idea that words with fewer syllables are easier to understand.</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">The Flesch-Kincaid formula measures two things:</p><ul><li>How long words are.</li><li>How many words are in a sentence.</li>
</ul><p class="svelte-1xg41jv">The formula says the shorter the words and sentence, the easier it is to read.</p>
</button></div>
</div><figure class="container svelte-18drwk1"><figcaption class="sr-only">An interactive showing what the Flesch-Kincaid algorithm considers a easy, medium, and hard
sentence. The algorithm deems sentences with lower syllable counts to be easier, so when long
multisyllabic words are added (even if they are easy words), the algorithm says it's a hard
sentence. If we add short but obscure words, the algorithm thinks it's an easier sentence. We
see that the Flesch-Kincaid algorithm isn't able to handle much complexity when it comes to
assessing readability.</figcaption>

<h3 class="svelte-18drwk1">What happens if we only care about <strong>syllables</strong></h3>
<p class="reading-level svelte-18drwk1">The below text is at a <span class="grade svelte-18drwk1">2.34 (2nd grade)</span>
grade reading level according to Flesch-Kincaid</p>

<div class="container svelte-9tsnz9"><p class="spacer svelte-9tsnz9">The quick brown fox jumped over the lazy dog.</p>

<p class="text hide svelte-9tsnz9" aria-hidden><span id="Flesch-Kincaid-The-0">The </span><span id="Flesch-Kincaid-dun-0">dun </span><span id="Flesch-Kincaid-fox-0">fox </span><span id="Flesch-Kincaid-cleared-0">cleared </span><span id="Flesch-Kincaid-that-0">that </span><span id="Flesch-Kincaid-slouch-0">slouch </span><span id="Flesch-Kincaid-of-0">of </span><span id="Flesch-Kincaid-a-0">a </span><span id="Flesch-Kincaid-dog-0">dog </span><span id="Flesch-Kincaid-at-0">at </span><span id="Flesch-Kincaid-full-0">full </span><span id="Flesch-Kincaid-tilt-0">tilt. </span></p>
<p class="text hide svelte-9tsnz9" aria-hidden><span id="Flesch-Kincaid-The-1">The </span><span id="Flesch-Kincaid-quick-1">quick </span><span id="Flesch-Kincaid-brown-1">brown </span><span id="Flesch-Kincaid-fox-1">fox </span><span id="Flesch-Kincaid-jumped-1">jumped </span><span id="Flesch-Kincaid-over-1">over </span><span id="Flesch-Kincaid-the-1">the </span><span id="Flesch-Kincaid-lazy-1">lazy </span><span id="Flesch-Kincaid-dog-1">dog. </span></p>
<p class="text hide svelte-9tsnz9" aria-hidden><span id="Flesch-Kincaid-The-2">The </span><span id="Flesch-Kincaid-wonderful-2">wonderful, </span><span id="Flesch-Kincaid-beautiful-2">beautiful </span><span id="Flesch-Kincaid-fox-2">fox </span><span id="Flesch-Kincaid-jumped-2">jumped </span><span id="Flesch-Kincaid-over-2">over </span><span id="Flesch-Kincaid-the-2">the </span><span id="Flesch-Kincaid-unbelievably-2">unbelievably </span><span id="Flesch-Kincaid-lazy-2">lazy </span><span id="Flesch-Kincaid-dog-2">dog. </span></p>

</div>
<p class="explanation svelte-18drwk1">The two factors considered by Flesch–Kincaid are number of words per sentence and number of syllables per word. This is a short sentence with only two multi-syllable words (<strong>“over”</strong> and <strong>“lazy”</strong>), so the Flesch–Kincaid formula assigns it a low grade level.</p>
</figure><details class="svelte-192zsyu"><summary class="svelte-192zsyu">More about this algorithm</summary>
<div class="sr-only"><p>The author Rudolf Flesch made a career as an early evangelist for plain language in the mid-20th century, promoting his namesake Flesch Reading-Ease Test and its cousin, the Flesch-Kincaid Grade Level Formula, developed in 1975 under contract with the U.S. Navy. It was calibrated on the reading comprehension scores of 531 enlisted Navy personnel, in order to measure readability in the specific context of technical communication. Today, perhaps thanks to its misleading name, the F-K Grade Level Formula is used in schools to estimate reading difficulty for children, overlooking the obvious fact that elementary school students and naval cadets may not agree on whether the same text is easy or difficult to understand.</p></div>
<div aria-hidden class="svelte-1xg41jv outer deep-dive">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">The author Rudolf Flesch made a career as an early evangelist for plain language in the mid-20th century, promoting his namesake Flesch Reading-Ease Test and its cousin, the Flesch-Kincaid Grade Level Formula, developed in 1975 under contract with the U.S. Navy. It was calibrated on the reading comprehension scores of 531 enlisted Navy personnel, in order to measure readability in the specific context of technical communication. Today, perhaps thanks to its misleading name, the F-K Grade Level Formula is used in schools to estimate reading difficulty for children, overlooking the obvious fact that elementary school students and naval cadets may not agree on whether the same text is easy or difficult to understand.</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">Rudolf Flesch was an author. He lived in the 1900s. He thought plain language was very important. He made two scores to measure how easy something was to read:</p><ul><li>The Flesch Reading-Ease Test</li><li>The Flesch-Kincaid Grade Level Formula</li>
</ul><p class="svelte-1xg41jv">Rudolf Flesch created the Flesch-Kincaid Grade Level Formula when he was working for the Navy. He measured how well 531 people in the Navy could read technical communications. Technical communications have special information that people in the Navy need to do their jobs.</p><p class="svelte-1xg41jv">Now we use the Flesch-Kincaid Grade Level Formula to measure readings for children. But the score has never been tested with children.</p>
</button></div>
</div>
</details><p class="sr-only"></p>
<div aria-hidden class="svelte-1xg41jv outer no-plain">

<p class="svelte-1xg41jv inner"><h3 class="text svelte-1xg41jv">Algorithm #2: Difficult words</h3></p>
</div><div class="sr-only"><p>The Dale-Chall Readability Formula considers the proportion of difficult words, where it deems a word “difficult” if it is not on a list of 3,000 words familiar to fourth-grade students.</p></div>
<div aria-hidden class="svelte-1xg41jv outer">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">The Dale-Chall Readability Formula considers the proportion of difficult words, where it deems a word “difficult” if it is not on a list of 3,000 words familiar to fourth-grade students.</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">Dale-Chall is another readability score. It measures two things:</p><ul><li>How long each sentence is.</li><li>The number of easy or hard words.</li>
</ul><p class="svelte-1xg41jv">Dale-Chall uses a list of 3,000 easy words. Dale-Chall says these are words most 4th graders know. Any other word is a hard word.</p>
</button></div>
</div><div class="sr-only"><p>One risk in the use of vocabulary lists is that the vocabulary of the readers surveyed to create them may not match the vocabulary of the intended audience. The original Dale-Chall list of “familiar words” was compiled in 1948 through a survey of U.S. fourth-graders, and even the most recent update to the list in 1995 retains obsolete words like “Negro” and “homely” while omitting “computer.”</p></div>
<div aria-hidden class="svelte-1xg41jv outer">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">One risk in the use of vocabulary lists is that the vocabulary of the readers surveyed to create them may not match the vocabulary of the intended audience. The original Dale-Chall list of “familiar words” was compiled in 1948 through a survey of U.S. fourth-graders, and even the most recent update to the list in 1995 retains obsolete words like “Negro” and “homely” while omitting “computer.”</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">But not everyone knows the same words. Dale-Chall made the first easy word list in 1948. They updated the list in 1995.</p><p class="svelte-1xg41jv">We don’t use the same words now that we did back then. The list has words most people don’t use now, like “Negro” and “homely.” And it doesn’t have words a lot of people use now, like “computer.”</p>
</button></div>
</div><figure class="container svelte-18drwk1"><figcaption class="sr-only">An interactive showing what the Dale-Chall algorithm considers a easy, medium, and hard
sentence. Dale-Chall considers average sentence length along with how many difficult words are
used, where “difficult” words are words that don't appear on the Dale-Chall list. If we add
words that are unfamiliar (like dinosaur or dude) the algorithm says it's a difficult
sentence. If we simply add a sentence that just contains the exclamation "Yes!", that lowers
the average sentence length and makes the algorithm say it's an easier sentence. We see that
the Dale-Chall algorithm isn't able to handle much complexity when it comes to assessing
readability.</figcaption>

<h3 class="svelte-18drwk1">What happens if we only care about <strong>“difficult” words</strong></h3>
<p class="reading-level svelte-18drwk1">The below text is at a <span class="grade svelte-18drwk1">0.45 (4th grade or below)</span>
grade reading level according to Dale-Chall</p>

<div class="container svelte-9tsnz9"><p class="spacer svelte-9tsnz9">The quick brown fox jumped over the lazy dog.</p>

<p class="text hide svelte-9tsnz9" aria-hidden><span id="Dale-Chall-Yes-0">Yes! </span><span id="Dale-Chall-The-0">The </span><span id="Dale-Chall-quick-0">quick </span><span id="Dale-Chall-brown-0">brown </span><span id="Dale-Chall-fox-0">fox </span><span id="Dale-Chall-jumped-0">jumped </span><span id="Dale-Chall-over-0">over </span><span id="Dale-Chall-the-0">the </span><span id="Dale-Chall-lazy-0">lazy </span><span id="Dale-Chall-dog-0">dog. </span></p>
<p class="text hide svelte-9tsnz9" aria-hidden><span id="Dale-Chall-The-1">The </span><span id="Dale-Chall-quick-1">quick </span><span id="Dale-Chall-brown-1">brown </span><span id="Dale-Chall-fox-1">fox </span><span id="Dale-Chall-jumped-1">jumped </span><span id="Dale-Chall-over-1">over </span><span id="Dale-Chall-the-1">the </span><span id="Dale-Chall-lazy-1">lazy </span><span id="Dale-Chall-dog-1">dog. </span></p>
<p class="text hide svelte-9tsnz9" aria-hidden><span id="Dale-Chall-The-2">The </span><span id="Dale-Chall-quick-2">quick </span><span id="Dale-Chall-brown-2">brown </span><span id="Dale-Chall-dinosaur-2">dinosaur </span><span id="Dale-Chall-jumped-2">jumped </span><span id="Dale-Chall-over-2">over </span><span id="Dale-Chall-the-2">the </span><span id="Dale-Chall-lazy-2">lazy </span><span id="Dale-Chall-dude-2">dude. </span></p>

</div>
<p class="explanation svelte-18drwk1">Dale–Chall considers average sentence length along with percentage of difficult words (PDW), where “difficult” words are words that don't appear on the Dale–Chall list. This is a short sentence made entirely of words on the Dale–Chall list, so its ASL score is low and its PDW score is zero, yielding a score of 0.45. Since the formula was calibrated on a group of 4th grade students, all scores below 5.0 are collapsed into a single readability category representing “4th grade and below.”</p>
</figure><p class="sr-only"></p>
<div aria-hidden class="svelte-1xg41jv outer no-plain">

<p class="svelte-1xg41jv inner"><h3 class="text svelte-1xg41jv">Algorithm #3: Algorithmic black boxes</h3></p>
</div><div class="sr-only"><p>More recently, US schools and textbook manufacturers have standardized their curricula on the Lexile Framework for Reading, a set of readability algorithms and vocabulary lists designed to automatically match students with appropriately difficult books. Publishers apply Lexile to their texts to rate their difficulty. A Lexile score of 210 indicates an easy-to-read book, while a score of 1730 indicates a very challenging one. A reading comprehension test assigns a corresponding reading score to each student, after which teachers pair students with texts that have comparable Lexile scores.</p></div>
<div aria-hidden class="svelte-1xg41jv outer">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">More recently, US schools and textbook manufacturers have standardized their curricula on the Lexile Framework for Reading, a set of readability algorithms and vocabulary lists designed to automatically match students with appropriately difficult books. Publishers apply Lexile to their texts to rate their difficulty. A Lexile score of 210 indicates an easy-to-read book, while a score of 1730 indicates a very challenging one. A reading comprehension test assigns a corresponding reading score to each student, after which teachers pair students with texts that have comparable Lexile scores.</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">Lexile Framework for Reading is another formula to measure how easy something is to read. Schools and textbook writers use Lexile. Lexile helps match students with books they are able to read.</p><p class="svelte-1xg41jv">Here is how it works:</p><ul><li>Lexile scores books. It rates them as easy or hard to read.</li><li>Students take a reading test. It tells them how well they read.</li><li>Teachers give students books that won’t be too easy or too hard for them to read.</li>
</ul>
</button></div>
</div><div class="sr-only"><p>The approach sounds simple enough, but critics have pointed out absurdities in Lexile's results. According to Lexile, The Grapes of Wrath (Lexile score: 680) is easier to understand than the Nancy Drew mystery Nancy's Mysterious Letter (score: 720), but neither of these is as challenging as The Library Mouse (score: 860), a 32-page illustrated children's book.</p></div>
<div aria-hidden class="svelte-1xg41jv outer">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">The approach sounds simple enough, but critics have pointed out absurdities in Lexile's results. According to Lexile, The Grapes of Wrath (Lexile score: 680) is easier to understand than the Nancy Drew mystery Nancy's Mysterious Letter (score: 720), but neither of these is as challenging as The Library Mouse (score: 860), a 32-page illustrated children's book.</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">But the scores Lexile gives books don’t always make sense. Here’s an example. Lexile says:</p><ul><li>Lexile says that The Grapes of Wrath is a pretty easy book to read. The Grapes of Wrath is a book for adults. It is over 400 pages long and has many complex themes and ideas.</li><li>Lexile says the Nancy Drew book Nancy’s Mysterious Letter is harder to read than The Grapes of Wrath. Nancy Drew books are made for preteens. Most people would consider it much easier to read than The Grapes of Wrath.</li><li>Lexile says The Library Mouse is harder to read than the Nancy Drew book or The Grapes of Wrath. The Library Mouse is a picture book for children.</li>
</ul><p class="svelte-1xg41jv">It does not make sense that a children’s picture book would be harder to read than a book for adults.</p>
</button></div>
</div><figure class="container svelte-19y896n"><figcaption class="sr-only">Images of three book covers arranged by how difficult the Lexile algorithm thinks they are. It
says Grapes of Wrath is the easiest, followed by Nancy's Mysterious Letter, and the hardest is
The Library Mouse, a 32-page illustrated children's book. This doesn't make much sense, most
people would say that Grapes of Wrath is much more difficult than a simple children's book.
</figcaption>

<h3 class="svelte-19y896n">How Lexile scores popular books for children</h3>
<div class="books svelte-19y896n"><div class="book svelte-19y896n"><img src="assets/img/grapes.jpeg" alt="the grapes of wrath cover" class=" svelte-19y896n">
<p class="score svelte-19y896n">680</p>
<p class="grade svelte-19y896n">(5th grade)</p>
</div><div class="book svelte-19y896n"><img src="assets/img/nancy.jpeg" alt="nancy drew cover" class=" svelte-19y896n">
<p class="score svelte-19y896n">720</p>
<p class="grade svelte-19y896n">(7th grade)</p>
</div><div class="book svelte-19y896n"><img src="assets/img/mouse.jpeg" alt="the library mouse cover" class=" svelte-19y896n">
<p class="score svelte-19y896n">860</p>
<p class="grade svelte-19y896n">(10th grade)</p>
</div></div>
</figure><div class="sr-only"><p>How exactly are Lexile scores calculated? Unfortunately for us, the Lexile Framework is the intellectual property of MetaMetrics, the private company that created it, so we can only guess at the secret recipe, but it's a pretty good bet that Lexile scores depend on a mixture of the same factors used in Flesch–Kincaid and other open-source readability measures.</p></div>
<div aria-hidden class="svelte-1xg41jv outer">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">How exactly are Lexile scores calculated? Unfortunately for us, the Lexile Framework is the intellectual property of MetaMetrics, the private company that created it, so we can only guess at the secret recipe, but it's a pretty good bet that Lexile scores depend on a mixture of the same factors used in Flesch–Kincaid and other open-source readability measures.</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">We don’t know how Lexile decides how hard each book is. MetaMetrics is the company that made Lexile. They do not share what math they do to get their readability scores. But it is probably close to the other formulas we looked at. We know Lexile looks at:</p><ul><li>How long words are.</li><li>How long each sentence is.</li><li>How familiar the words are.</li><li>If things are repeated.</li>
</ul>
</button></div>
</div><div class="sr-only"><p>Formulas based on surface level text properties and word frequency have clear limitations. None of them consider how well organized the information is, or whether the sentences and paragraphs are coherent. None consider the role of grammatical tense. None account for the explanation of acronyms and jargon. None would balk at Jack Torrance's rambling and meaningless draft in The Shining, endlessly repeating “All work and no play makes Jack a dull boy.”</p></div>
<div aria-hidden class="svelte-1xg41jv outer">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">Formulas based on surface level text properties and word frequency have clear limitations. None of them consider how well organized the information is, or whether the sentences and paragraphs are coherent. None consider the role of grammatical tense. None account for the explanation of acronyms and jargon. None would balk at Jack Torrance's rambling and meaningless draft in The Shining, endlessly repeating “All work and no play makes Jack a dull boy.”</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">None of these formulas are perfect. They don’t measure:</p><ul><li>The order of the sentences.</li><li>If the writing makes sense.</li><li>Grammar.</li><li>If the writer explains hard words and phrases.</li>
</ul><p class="svelte-1xg41jv">These formulas would have no problem with the scene in The Shining where Jack Torrance writes “All work and no play makes Jack a dull boy,” over and over again. They do not check if the writing means anything.</p>
</button></div>
</div><div class="sr-only"><p>But proprietary tech like Lexile has some of the most disconcerting aspects of both worlds. As flawed as Flesch-Kincaid or Dale-Chall, but opaque and unexplainable. The main benefit of the F-K and D-C formulas (and other simple algorithms like Gunning-Fog and SMOG) is their transparency. A broken system locked in a black box can't even offer this.</p></div>
<div aria-hidden class="svelte-1xg41jv outer">

<div class="svelte-1xg41jv inner show-standard"><div class="text standard svelte-1xg41jv"><p class="svelte-1xg41jv">But proprietary tech like Lexile has some of the most disconcerting aspects of both worlds. As flawed as Flesch-Kincaid or Dale-Chall, but opaque and unexplainable. The main benefit of the F-K and D-C formulas (and other simple algorithms like Gunning-Fog and SMOG) is their transparency. A broken system locked in a black box can't even offer this.</p>
</div><button class="text plain svelte-1xg41jv faded"><p class="svelte-1xg41jv">At least we know how Flesch-Kincaid and Dale-Chall work. They are not perfect but we can explain them. We don’t even know what Lexile measures.</p>
</button></div>
</div>
</section><div class="svelte-16d9zvc"><h3>Authors' note</h3>

<p>A lot of people helped us write this article.</p><p>Thank you to Zoe Gross and Leah Mapstead for being our expert readers. Zoe and Leah told us how to make the article better. Zoe is Director of Advocacy at the Autistic Self-Advocacy Network. Leah is a disability advocate and actor.</p><p>Thank you to:</p><p>They made our article interactive. They helped brainstorm ideas. They told us how to make our writing better.</p><p>Thank you to Matt Hackert for making sure the article works on a screen reader. Matt leads the Center of Excellence in Nonvisual Accessibility at the National Federation of the Blind.</p><p>Thank you to Amy Silverman for helping come up with the idea for this article.</p><p>You can learn more about Kyra <a href="https://www.propublica.org/article/people-with-developmental-disabilities-were-promised-help-instead-they-face-delays-and-denials">here</a>.</p><p>You can learn more about how to write plain language and Easy Read <a href="https://autisticadvocacy.org/resources/accessibility/easyread/">here</a>, <a href="https://www.plainlanguage.gov/">here</a>, and <a href="https://www.easy-read-online.co.uk/media/10609/making-myself-clear.pdf">here</a>.</p>
</div>

+ 210
- 0
cache/2022/47b228aca2d77bc5e7eee35437655a8e/index.html View File

@@ -0,0 +1,210 @@
<!doctype html><!-- This is a valid HTML5 document. -->
<!-- Screen readers, SEO, extensions and so on. -->
<html lang="fr">
<!-- Has to be within the first 1024 bytes, hence before the `title` element
See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
<meta charset="utf-8">
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
<!-- The viewport meta is quite crowded and we are responsible for that.
See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
<meta name="viewport" content="width=device-width,initial-scale=1">
<!-- Required to make a valid HTML5 document. -->
<title>On ne fera pas l’économie de parler distance des logements (archive) — David Larlet</title>
<meta name="description" content="Publication mise en cache pour en conserver une trace.">
<!-- That good ol' feed, subscribe :). -->
<link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/">
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png">
<link rel="manifest" href="/static/david/icons2/site.webmanifest">
<link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c">
<link rel="shortcut icon" href="/static/david/icons2/favicon.ico">
<meta name="msapplication-TileColor" content="#f7f7f7">
<meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml">
<meta name="theme-color" content="#f7f7f7" media="(prefers-color-scheme: light)">
<meta name="theme-color" content="#272727" media="(prefers-color-scheme: dark)">
<!-- Documented, feel free to shoot an email. -->
<link rel="stylesheet" href="/static/david/css/style_2021-01-20.css">
<!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. -->
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<script>
function toggleTheme(themeName) {
document.documentElement.classList.toggle(
'forced-dark',
themeName === 'dark'
)
document.documentElement.classList.toggle(
'forced-light',
themeName === 'light'
)
}
const selectedTheme = localStorage.getItem('theme')
if (selectedTheme !== 'undefined') {
toggleTheme(selectedTheme)
}
</script>

<meta name="robots" content="noindex, nofollow">
<meta content="origin-when-cross-origin" name="referrer">
<!-- Canonical URL for SEO purposes -->
<link rel="canonical" href="https://n.survol.fr/n/on-ne-fera-pas-leconomie-de-parler-distance-des-logements">

<body class="remarkdown h1-underline h2-underline h3-underline em-underscore hr-center ul-star pre-tick" data-instant-intensity="viewport-all">


<article>
<header>
<h1>On ne fera pas l’économie de parler distance des logements</h1>
</header>
<nav>
<p class="center">
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="https://n.survol.fr/n/on-ne-fera-pas-leconomie-de-parler-distance-des-logements" title="Lien vers le contenu original">Source originale</a>
</p>
</nav>
<hr>
<p>On parle beau­coup prix de l’es­sence, climat, et tran­si­tion de la voiture vers d’autres modes de dépla­ce­ment comme le vélo ou les trans­ports en commun. </p>

<p>Ces discus­sions arrivent régu­liè­re­ment à l’objec­tion « je suis loin, sans alter­na­tive, la voiture m’est indis­pen­sable », comme si la distance était une donnée externe intan­gible.</p>

<p>La distance est pour­tant un choix. C’est parfois un choix de confort, pour ne pas démé­na­ger, ou au contraire pour gagner en surface et en confort. C’est toujours un choix collec­tif d’or­ga­ni­sa­tion urbaine, avec des pôles rési­den­tiel éloi­gnés des pôles indus­triels et des centres villes.</p>

<p>La distance a été consi­dé­rée comme un para­mètre acces­soire parce qu’on pouvait se repo­ser sur la voiture et l’in­fra­struc­ture routière.</p>

<hr class="wp-block-separator">

<p>Le parti pris c’est qu’on ne fera pas l’éco­no­mie de remettre ce choix en cause. Trop de gens dépendent de la voiture sans alter­na­tive. Si on veut pouvoir réduire la circu­la­tion auto­mo­bile, il faut aussi réduire là où elle est néces­saire.</p>

<p>On ne peut pas mettre tout le monde en centre ville. Il n’y a simple­ment pas la place. On ne peut pas construire un réseau de trans­port en commun qui circule loin, partout, à une fréquence qui permet de se repo­ser dessus. Ou plutôt on pour­rait mais on n’est proba­ble­ment pas prêt à en payer le coût.</p>

<p>L’al­ter­na­tive qui nous reste c’est de repen­ser à la fois l’or­ga­ni­sa­tion collec­tive et nos propres choix indi­vi­duels.</p>

<p>Ça veut dire inci­ter les bureaux à se disper­ser au lieu de les concen­trer dans un centre d’af­faire ou au centre ville.</p>

<p>Ça veut dire arrê­ter le modèle pavillon­naire où les plus aisés s’éloignent pour trou­ver leur maison indi­vi­duelle et leur jardin.</p>

<p>Ça veut dire parfois démé­na­ger du coin qu’on aime ou du coin où on a habité histo­rique­ment pour suivre les contraintes de distance au travail ou aux acti­vi­tés, y compris si ça veut dire quit­ter la ville pour la campagne ou quit­ter la campagne pour la ville, ou d’autres compro­mis comme la surface ou le confort acces­sibles au même prix.</p>

<p>Ça veut dire, pour ceux qui ont la chance de choi­sir leur travail, de le choi­sir aussi en fonc­tion de la distance aux loge­ments qu’on peut envi­sa­ger derrière.</p>

<p>Ça peut vouloir dire moins d’énormes métro­poles centra­li­sées et de petits villages où il n’y a rien, pour plus de villes et zones urbaines de moyenne impor­tance qui sont rela­ti­ve­ment auto­nomes au niveau loge­ment / travail / acti­vi­tés.</p>

<p>Ça veut dire moins de maisons indi­vi­duelles et plus de petits immeubles et loge­ments en co-propriété.</p>

<p>Ça veut dire des zones urbaines d’abord pensées pour se dépla­cer et y vivre sans voiture, au lieu d’être essen­tiel­le­ment pensées pour y circu­ler en voiture.</p>

<hr class="wp-block-separator">

<p>Oui, ça ne veut pas dire que des choses atti­rantes.</p>

<p>On a construit un modèle de société où le rêve est d’ha­bi­ter dans une maison indi­vi­duelle sans vis-a-vis avec un grand jardin, avec une ou plusieurs grosse voitures et une route large qui nous amène à une grande ville juste à côté.</p>

<p>C’est ce modèle qu’il nous faut dépas­ser, et ça pren­dra bien plus que quelques années, que ce soit au niveau chan­ge­ment des menta­li­tés ou au niveau de l’or­ga­ni­sa­tion urbaine.</p>

<p>Amélio­rer les trans­ports en commun et construire des pistes cyclables en zone urbaine dense c’est indis­pen­sable mais ça n’est que le mini­mum faisable à court terme. Ça ne suffira pas.</p>
</article>


<hr>

<footer>
<p>
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="/david/log/" title="Accès au flux RSS"><svg class="icon icon-rss2">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-rss2"></use>
</svg> Suivre</a> •
<a href="http://larlet.com" title="Go to my English profile" data-instant><svg class="icon icon-user-tie">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-user-tie"></use>
</svg> Pro</a> •
<a href="mailto:david%40larlet.fr" title="Envoyer un courriel"><svg class="icon icon-mail">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-mail"></use>
</svg> Email</a> •
<abbr class="nowrap" title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340"><svg class="icon icon-hammer2">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-hammer2"></use>
</svg> Légal</abbr>
</p>
<template id="theme-selector">
<form>
<fieldset>
<legend><svg class="icon icon-brightness-contrast">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-brightness-contrast"></use>
</svg> Thème</legend>
<label>
<input type="radio" value="auto" name="chosen-color-scheme" checked> Auto
</label>
<label>
<input type="radio" value="dark" name="chosen-color-scheme"> Foncé
</label>
<label>
<input type="radio" value="light" name="chosen-color-scheme"> Clair
</label>
</fieldset>
</form>
</template>
</footer>
<script src="/static/david/js/instantpage-5.1.0.min.js" type="module"></script>
<script>
function loadThemeForm(templateName) {
const themeSelectorTemplate = document.querySelector(templateName)
const form = themeSelectorTemplate.content.firstElementChild
themeSelectorTemplate.replaceWith(form)

form.addEventListener('change', (e) => {
const chosenColorScheme = e.target.value
localStorage.setItem('theme', chosenColorScheme)
toggleTheme(chosenColorScheme)
})

const selectedTheme = localStorage.getItem('theme')
if (selectedTheme && selectedTheme !== 'undefined') {
form.querySelector(`[value="${selectedTheme}"]`).checked = true
}
}

const prefersColorSchemeDark = '(prefers-color-scheme: dark)'
window.addEventListener('load', () => {
let hasDarkRules = false
for (const styleSheet of Array.from(document.styleSheets)) {
let mediaRules = []
for (const cssRule of styleSheet.cssRules) {
if (cssRule.type !== CSSRule.MEDIA_RULE) {
continue
}
// WARNING: Safari does not have/supports `conditionText`.
if (cssRule.conditionText) {
if (cssRule.conditionText !== prefersColorSchemeDark) {
continue
}
} else {
if (cssRule.cssText.startsWith(prefersColorSchemeDark)) {
continue
}
}
mediaRules = mediaRules.concat(Array.from(cssRule.cssRules))
}

// WARNING: do not try to insert a Rule to a styleSheet you are
// currently iterating on, otherwise the browser will be stuck
// in a infinite loop…
for (const mediaRule of mediaRules) {
styleSheet.insertRule(mediaRule.cssText)
hasDarkRules = true
}
}
if (hasDarkRules) {
loadThemeForm('#theme-selector')
}
})
</script>
</body>
</html>

+ 81
- 0
cache/2022/47b228aca2d77bc5e7eee35437655a8e/index.md View File

@@ -0,0 +1,81 @@
title: On ne fera pas l’économie de parler distance des logements
url: https://n.survol.fr/n/on-ne-fera-pas-leconomie-de-parler-distance-des-logements
hash_url: 47b228aca2d77bc5e7eee35437655a8e

<p>On parle beau­coup prix de l’es­sence, climat, et tran­si­tion de la voiture vers d’autres modes de dépla­ce­ment comme le vélo ou les trans­ports en commun. </p>



<p>Ces discus­sions arrivent régu­liè­re­ment à l’objec­tion « je suis loin, sans alter­na­tive, la voiture m’est indis­pen­sable », comme si la distance était une donnée externe intan­gible.</p>



<p>La distance est pour­tant un choix. C’est parfois un choix de confort, pour ne pas démé­na­ger, ou au contraire pour gagner en surface et en confort. C’est toujours un choix collec­tif d’or­ga­ni­sa­tion urbaine, avec des pôles rési­den­tiel éloi­gnés des pôles indus­triels et des centres villes.</p>



<p>La distance a été consi­dé­rée comme un para­mètre acces­soire parce qu’on pouvait se repo­ser sur la voiture et l’in­fra­struc­ture routière.</p>



<hr class="wp-block-separator">



<p>Le parti pris c’est qu’on ne fera pas l’éco­no­mie de remettre ce choix en cause. Trop de gens dépendent de la voiture sans alter­na­tive. Si on veut pouvoir réduire la circu­la­tion auto­mo­bile, il faut aussi réduire là où elle est néces­saire.</p>



<p>On ne peut pas mettre tout le monde en centre ville. Il n’y a simple­ment pas la place. On ne peut pas construire un réseau de trans­port en commun qui circule loin, partout, à une fréquence qui permet de se repo­ser dessus. Ou plutôt on pour­rait mais on n’est proba­ble­ment pas prêt à en payer le coût.</p>



<p>L’al­ter­na­tive qui nous reste c’est de repen­ser à la fois l’or­ga­ni­sa­tion collec­tive et nos propres choix indi­vi­duels.</p>



<p>Ça veut dire inci­ter les bureaux à se disper­ser au lieu de les concen­trer dans un centre d’af­faire ou au centre ville.</p>



<p>Ça veut dire arrê­ter le modèle pavillon­naire où les plus aisés s’éloignent pour trou­ver leur maison indi­vi­duelle et leur jardin.</p>



<p>Ça veut dire parfois démé­na­ger du coin qu’on aime ou du coin où on a habité histo­rique­ment pour suivre les contraintes de distance au travail ou aux acti­vi­tés, y compris si ça veut dire quit­ter la ville pour la campagne ou quit­ter la campagne pour la ville, ou d’autres compro­mis comme la surface ou le confort acces­sibles au même prix.</p>



<p>Ça veut dire, pour ceux qui ont la chance de choi­sir leur travail, de le choi­sir aussi en fonc­tion de la distance aux loge­ments qu’on peut envi­sa­ger derrière.</p>



<p>Ça peut vouloir dire moins d’énormes métro­poles centra­li­sées et de petits villages où il n’y a rien, pour plus de villes et zones urbaines de moyenne impor­tance qui sont rela­ti­ve­ment auto­nomes au niveau loge­ment / travail / acti­vi­tés.</p>



<p>Ça veut dire moins de maisons indi­vi­duelles et plus de petits immeubles et loge­ments en co-propriété.</p>



<p>Ça veut dire des zones urbaines d’abord pensées pour se dépla­cer et y vivre sans voiture, au lieu d’être essen­tiel­le­ment pensées pour y circu­ler en voiture.</p>



<hr class="wp-block-separator">



<p>Oui, ça ne veut pas dire que des choses atti­rantes.</p>



<p>On a construit un modèle de société où le rêve est d’ha­bi­ter dans une maison indi­vi­duelle sans vis-a-vis avec un grand jardin, avec une ou plusieurs grosse voitures et une route large qui nous amène à une grande ville juste à côté.</p>



<p>C’est ce modèle qu’il nous faut dépas­ser, et ça pren­dra bien plus que quelques années, que ce soit au niveau chan­ge­ment des menta­li­tés ou au niveau de l’or­ga­ni­sa­tion urbaine.</p>



<p>Amélio­rer les trans­ports en commun et construire des pistes cyclables en zone urbaine dense c’est indis­pen­sable mais ça n’est que le mini­mum faisable à court terme. Ça ne suffira pas.</p>

+ 264
- 0
cache/2022/571d5d3f9d63d9ec4a8107e5abd15941/index.html View File

@@ -0,0 +1,264 @@
<!doctype html><!-- This is a valid HTML5 document. -->
<!-- Screen readers, SEO, extensions and so on. -->
<html lang="fr">
<!-- Has to be within the first 1024 bytes, hence before the `title` element
See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
<meta charset="utf-8">
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
<!-- The viewport meta is quite crowded and we are responsible for that.
See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
<meta name="viewport" content="width=device-width,initial-scale=1">
<!-- Required to make a valid HTML5 document. -->
<title>Why not everything I do is “Open” or “Free” (archive) — David Larlet</title>
<meta name="description" content="Publication mise en cache pour en conserver une trace.">
<!-- That good ol' feed, subscribe :). -->
<link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/">
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png">
<link rel="manifest" href="/static/david/icons2/site.webmanifest">
<link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c">
<link rel="shortcut icon" href="/static/david/icons2/favicon.ico">
<meta name="msapplication-TileColor" content="#f7f7f7">
<meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml">
<meta name="theme-color" content="#f7f7f7" media="(prefers-color-scheme: light)">
<meta name="theme-color" content="#272727" media="(prefers-color-scheme: dark)">
<!-- Documented, feel free to shoot an email. -->
<link rel="stylesheet" href="/static/david/css/style_2021-01-20.css">
<!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. -->
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<script>
function toggleTheme(themeName) {
document.documentElement.classList.toggle(
'forced-dark',
themeName === 'dark'
)
document.documentElement.classList.toggle(
'forced-light',
themeName === 'light'
)
}
const selectedTheme = localStorage.getItem('theme')
if (selectedTheme !== 'undefined') {
toggleTheme(selectedTheme)
}
</script>

<meta name="robots" content="noindex, nofollow">
<meta content="origin-when-cross-origin" name="referrer">
<!-- Canonical URL for SEO purposes -->
<link rel="canonical" href="https://overengineer.dev/blog/2021/12/12/why-not-everything-i-do-is-open-or-free.html">

<body class="remarkdown h1-underline h2-underline h3-underline em-underscore hr-center ul-star pre-tick" data-instant-intensity="viewport-all">


<article>
<header>
<h1>Why not everything I do is “Open” or “Free”</h1>
</header>
<nav>
<p class="center">
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="https://overengineer.dev/blog/2021/12/12/why-not-everything-i-do-is-open-or-free.html" title="Lien vers le contenu original">Source originale</a>
</p>
</nav>
<hr>
<p>There is a high chance that, if you know me, you know me for some of my work on Free and/or Open Source projects, and you might know me as a supporter of such projects and parts of the culture. So it might seem odd that I deliberately decide <em>not</em> to release some of my work under such terms. I have been asked so many times about this, I decided to take the time and put my thoughts into a thing I can link to. This is more a collection of individual thoughts rather than a cohesive article.</p>

<h2 id="software-projects">Software projects</h2>

<p>I consider myself lucky in the way that I not only got the chance to work on and with a lot of amazing Free and/or Open Source projects in my free time, but that I am also able to spend my workdays working on Open Source software and earn my living that way. I had the chance to join a great project in its early days. Over time, that project grew to over 12k stars on GitHub, and I eventually ended up leading that project from an administrative side. Unfortunately, while most of that work was incredibly rewarding and fun, I also learned about the issues in such projects.</p>

<h3 id="code-dumping-does-not-work">“Code dumping” does not work</h3>

<p>A lot of people suggest “just upload your code to a code-sharing site and be done with it”. Not only do I personally find that incredibly counterproductive, but the whole idea of “Dump and Forget” does not work out.</p>

<p>Imagine building a little RTMP server in Rust, because you are frustrated with the nginx RTMP modules, and you wanted to learn Rust anyway. So you create a public GitHub repository and start working on it. After some months, you have reached a state where “the basics work just fine”, and then you stop working on it because you moved on towards new and more exciting things. Maybe you even had the foresight to add a “this project is incomplete and unmaintained” notice to the README. Sometime in the future, somebody will find your project. It could be that they searched for “RTMP server in Rust” and found it. Maybe they just looked through the “#rtmp” tag on GitHub, or they reached your project by other means. And instead of just moving on and looking at other projects, some people <em>will</em> skip your warnings.</p>

<p>I had multiple projects of that kind. And even though I had very explicit warnings about projects not being production-ready in the README - some projects even had the “archived” status on GitHub - that did not stop people from actually looking into it. I received countless issues and emails with “suggestions” (read: demands) on what to add and questions about how to build and run things because some outdated dependency did break or was no longer available. I even once had a company reach out to me, asking for help because a piece of server automation I shared ended up messing up their production environment, hoping I could help them figure out what happened. Unfortunately, I could not, and I ended up deleting that project.</p>

<p>When I share software projects publicly, then I do this because I think that a) someone could use that project to help them solve an issue, or b) they could learn something from looking at how I solved an issue or how I implemented a specific piece of logic. Quite honestly, for most of the projects we all create “on the side”, neither is true. Dumping unfinished, unpolished, unmaintained, and potentially badly designed or even insecure projects onto the internet is not benefitting anyone.</p>

<h3 id="open-source-is-not-just-about-open-source">Open Source is not just about open source</h3>

<p>Here is the thing: making a project’s code accessible to any audience is just a small piece of running an open-source <em>project</em>. Take GitHub, for example: you can turn off the issue tracker and turn off project discussions, but you cannot turn off the ability for people to create pull requests. And I get that, the whole “fork it, change it, and submit your changes upstream” culture is a huge part of open source - and one part I really like about (F)OSS projects.</p>

<p>The problem, though, is that reviewing pull requests, paying adequate attention, and providing helpful feedback takes <em>a lot</em> of time and energy. Reviewing code sometimes feels harder than writing code, and I do believe that this is true to a certain extend: you not only have to understand the intentions of the person writing the code, you also have to think about how this new code fits into the existing system and if there are any side-effects that might be tricky to catch from looking at the implementation itself. As an individual who just uploaded pieces of code to GitHub without considering them “a project”, you have two options:</p>

<ol>
<li>Just merging pretty much everything without too much care or attention. This is surprisingly common in smaller projects, but I can’t see how that’s a good idea. Projects that work like that frequently make breaking changes by accident, break completely, or end up in a state where the code is inconsistent or hard to maintain. When your project is large enough that people actually do submit pull requests for it, then your project is likely used by a non-zero amount of other folks. Leaving your project in an unstable or unpredictable state will cause more frustration and harm than not making your project available in the first place.</li>
<li>Ignoring Pull Requests completely. This is just… kinda disrespectful. Sure, if you have a note in your README that says you’ll not accept pull requests, or something similar, then you would be justified in just ignoring them or closing them without taking a look. But if you get a pull request, then someone else has spent time on your project, and just throwing that away is not good. Ignoring pull requests has an unfortunate side effect as well: the people working on and with your project could just continue their work in their own fork without ever bringing the changes upstream. This might sound like a feature at first, but this can become harmful as soon as there is more than one active fork. Forks usually do not sync back up, so you end up with multiple completely diverging projects that all have their pros and cons, and the “which fork should I be using?” question becomes a big issue for users.</li>
</ol>

<p>Running a (F)OSS project is not just about managing contributions to code, though. You will also get questions from users of your project, you usually have to provide a lot of documentation, maybe even plan out “stable” releases, and properly tag and distribute those… There’s a lot of stuff that needs to be done, and that all takes a lot of time. If you’re not committed to spending that time, then you cannot run a project, and you shouldn’t even try.</p>

<h3 id="when-projects-become-big">When projects become big</h3>

<p>If you are lucky - or unlucky - enough, your project might become big. Unless you are a company, or your project is for some other reason part of your work life and not just a volunteering side project, I consider projects becoming big a curse. The increase in contributors is not proportional to the increase of time and effort you have to spend to keep a project alive. Even if you publish something like a code library that’s only ever used by fellow programmers, the amount of questions and suggestions will always exceed the number of contributions - and unfortunately, providing support is one of the tasks most contributors don’t like to help out on, because “that’s the maintainers job”.</p>

<p>In one large project I’ve worked on, I found myself in a situation where 90% of my time was spent helping people, leading discussions, generally moderating communication channels, reviewing pull requests, making architectural suggestions, … - and only 10% with actually writing code. All that non-code work can be super fun and rewarding, and I enjoyed it a lot. But if you start a project because you want to write code, this can be troubling. :)</p>

<p>One thing that <em>does</em> scale with your project size is the number of bad actors. And I’m not even talking about people who’re trying to find security vulnerabilities in your project with malicious intents, but rather people who disrupt discussions and people whose primary motivation appears to be to annoy maintainers. Now, this is obviously not a binary state, but rather a huge gradient of different behaviors, and sometimes, the bad behavior might not even be deliberate.</p>

<p>If you are using a project, and that project breaks or changes in a way that you find bad, you might be annoyed. If you found a project that <em>almost</em> solves your need but falls short on a single aspect, you might request a feature or suggest a change, and you might be agitated if you do not get positive responses to that. If you are a contributor, and your pull request got rejected, or you just received the fourth round of review tasks that will take you multiple days, you might be angry and wish for that task to just be done already. All those people might use a project’s discussion board, chatrooms, issue trackers, or just social media, to vent that frustration. And honestly, I kinda get that.</p>

<p>Unfortunately, all this sums up if you are on the receiving end of those vents. You could leave all that stuff alone and just ignore it, but you know that this will turn your project’s communication channel into a wasteland that nobody can use productively. Or you start moderating things, but this will make the people in question even angrier and thus will cause you even more work. There is no win-condition here, and no matter how Rainbow Unicorn’y your project is, you <em>will</em> run into those situations.</p>

<p>As soon as your project becomes big, a lot of people will be very angry with you, all the time, for all kinds of reasons. The project’s website with documentation went down while you were sleeping? You shipped a bug affecting a company that makes millions with an application that uses your library? You need more than eleven seconds to resolve a security issue and ship a release? You decide that you would like to take the project in a different direction and one of your contributors is not happy with it? You decide that you will not be looking at this one giant pull request this Sunday? You asked for … a donation? You will be yelled at, no matter what you do.</p>

<h3 id="responsibility-and-mental-stress">Responsibility, and mental stress</h3>

<p>I am trying to make this post as generic as possible, but this is a section where I have to talk about <em>me</em>. Many people are fine with the things I wrote above, and they can just deal with the constant negative things and just feed off the positive experiences. Unfortunately, I am not that kind of person. Nobody would call 2020 or 2021 <em>good</em> years, but for me, my (F)OSS work reached a point where I had to hit the emergency brake. While I am usually okay with not letting yelling people get to me, brains do this funny thing where they accumulate multiple simultaneous problems into a state where everything wants to explode.</p>

<p>I worked on a project that was always very important to me for years. Not just because I used it a lot, but also because I thought it was an important project and because I liked the community around it. Over time, I naturally “evolved” from writing code into spending most of my time with the other non-code’y things I mentioned above, and honestly, I quite liked it. At one point, I decided that the project’s less-than-ideal public-facing website, as well as developer and user documentation, is something that needs more attention. So I did what every rational human would do and came up with a plan to rebuild everything in that category completely from scratch. You will not be surprised to learn that, while this decision made sense and the plans I came up with were pretty good, this did not get done. There just were too many other things that needed to be done, and I am not the kind of person who gets a lot of satisfaction out of spending all of my free time writing documentation and marketing texts.</p>

<p>However, this left me in a peculiar spot. We all agreed that this work was important, I started this work, and I owned this work. More often than not, when I felt like working on that project, I did not feel like working on the documentation piece. But because I felt this work was the <em>most important</em> thing I could do, I convinced myself that I should prioritize that work and not do other things. This, however, only resulted in me not doing anything at all. Eventually, I felt <em>bad</em> for not working on that project and then tried to force myself into it. This <em>worked</em> a bit, but my output was, naturally, not the best quality. Because the project was important to me, and because I can be a bit of a perfectionist, this led into a spiral where I felt bad for the work that was done and thus felt like not working on it, while also feeling bad for not working on it. Very fun state to be in!</p>

<p>I tried powering through that, and this is how it went:</p>

<p class="center"><img src="/statics/blog/20211212/github-graph.png" alt='A screenshot of the "GitHub Contribution Graph". The first half of the graph shows a lot of activity, where the majority of squares are marked. The second half, however, shows a significant drop in activity.' class="center">
(<em>Screenshot of my “GitHub Contribution Graph”, taken in May 2021. You can clearly see the point where I decided I had enough: December 2020.</em>)</p>

<p>This “documentation project” issue alone would have been resolvable. I could have just ended that project or gotten other people into contributing more to those efforts. Unfortunately, such problems never come alone in large projects because you’re not working alone and you’re not in a bubble. In my case, these feelings were paired with me using that project less and less, with a not insignificant amount of people constantly demanding to implement certain features, asking “why is X not done yet?”, and continuously criticizing some of my decisions and some of the project’s decision in a very aggressive manner.</p>

<p>I ended up completely dropping out of that project as a way of preserving my mental health. In fact, I dropped out of all my (F)OSS projects, and I even deleted some of my “code dump” projects on GitHub.</p>

<p>Now, I’m not going to write about burnout, especially (F)OSS maintainer’s burnout, or about the unreasonable expectations people have towards project maintainers. If you have read this post this far, you most likely have read articles about this that explained things far better than I could do. But this whole ordeal has absolutely contributed to my decision to massively scale down the number of “open” and “free” things I work on. If I want to release a project as Open Source, then I absolutely want to make sure that these things do not become an issue again. However, for most projects, this kind of preparation is simply not worth it.</p>

<h2 id="hardware-projects-and-hardware-designs">Hardware projects and hardware designs</h2>

<p>Enough about software. Sometimes, I do hardware projects as well: everything from 3D printed designs to electrical engineering. These projects are lesser-known, mainly because I’ve never really shared them besides some post on social media and some chats with friends, but they exist nonetheless<sup id="fnref:1"></sup>. All the reasons I previously explained still apply here, and I do not want these projects to be open for collaboration most of the time. However, there are additional points here, and the most important one is:</p>

<p>I’m not an expert on these things.</p>

<p>Hardware projects are always a bit more complicated than software projects. If software goes wrong, at least for the kinds of software I create, you might get a crash or two, or something might not work correctly, but no considerable harm will be done. For hardware projects, the consequences of a “bug” are far more severe: You could waste a lot of material and energy trying to reproduce a 3D print. You could actually physically <em>break</em> stuff while trying to modify an existing appliance. Hardware projects could result in broken components, or worse: in broken devices you attached my projects to. I don’t want to be responsible for any of that.</p>

<p>When I work on a hardware project, I very much only build things for myself. The measurements are <em>exactly</em> what I need and fine-tuned to what I know I can produce. Electronics are designed to work in the environment I build and the limitations I set up. The firmware does precisely what I need it to in a very stubborn way, and especially the “smart” “devices” usually depend on other pieces of infrastructure that are very special to my home.</p>

<p>While turning those projects into things that could be useful in other environments and more generalized setups, I consider them a playground (and learning ground) for myself, and I generally do not want to spend the time on making it more useful to more than just me.</p>

<h2 id="artsy-and-creative-things">Artsy and creative things</h2>

<p>I used to publish all my photos and other stuff using a license that allowed usage of my things without any license fees, even in commercial environments. The only limitation was that you needed to properly credit me as the author. These days, I do not use free licenses for my contents anymore.</p>

<p>“Clearly state who made this thing” sounds like a simple requirement, but it was frustrating how frequently this was violated. Frequently, users of “alternative social networks” posted my content without any credit whatsoever and then reacted aggressively and defensively when asked to stop doing that and asked to respect the license terms. This is especially ironic since it’s the same group of people that frequently <em>shames</em> artists for not using those kinds of licenses in the first place.</p>

<p>However, what finally tipped me over into no longer using this kind of license was when a multi-billion dollar company used several of my photos from a certain location in a print brochure to advertise their expensive all-inclusive holiday packages to that exact location. Being a nice guy, I started by sending them a friendly email, asking them to maybe consider not violating my license, and instructing them how and where to properly credit me according to the license. As you would expect, I received zero response to that.</p>

<p>So I ended up hiring a lawyer and pursuing legal action against that company. Unfortunately, this turned out to be a huge pain. Many legal systems are based around the concept of <em>damages</em> and <em>indemnification</em>, but as it turns out, it’s really hard to claim damage when you’re literally giving away stuff for free. Try finding an attorney with experience in international copyright affairs if the monetary damage you claim is Zero! It’s also super frustrating if the same case involves parties from many different countries, where Copyright appears to be even weirder than it is in Germany. Ultimately, after way more than a year of legal battle, the best outcome we could achieve was that that company paid a laughable amount of money (actually less than my camera setup that took this photo is worth), stops printing new flyers with my photos, and that the company has to cover my legal expenses in this case.</p>

<p>If dealing with such topics is part of sharing things online anyway, then at least I want to have some control over it. I share things because I want others to look at them and not because I want others to re-use them. I can achieve what I want to achieve by simply not using the kinds of licenses that have caused me issues before, and as time has shown, the individuals who redistribute things without any credit or care will do it anyway.</p>

<h2 id="but-what-if-you-really-want-to-use-something-i-did">But what if you <em>really</em> want to use something I did?</h2>

<p>There is a chance that you’ve reached this article because I linked to it somewhere else. In that case, you might still be really interested in using or getting access to a thing I did. If that is the case, simply reach out to me. You can find contact information on <a href="/me/card.html">my profile on this website</a>.</p>

<p>If you’re a private individual who wants to use a photo on a personal website, or you want to build something on top of a hardware project I did, this should be really simple to work out. Get in touch, and let’s have a chat. If you have commercial interests or are a company, I still encourage you to reach out. However, please note that I’m unlikely to give away things for free depending on what we’re talking about and depending on your use case. At the same time, I can provide you with legal and taxable invoices for almost all countries, so I am sure you will be fine.</p>

<p>If you made it this far into this text… I hope you have a nice day. Stay safe, take care!</p>
</article>


<hr>

<footer>
<p>
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="/david/log/" title="Accès au flux RSS"><svg class="icon icon-rss2">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-rss2"></use>
</svg> Suivre</a> •
<a href="http://larlet.com" title="Go to my English profile" data-instant><svg class="icon icon-user-tie">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-user-tie"></use>
</svg> Pro</a> •
<a href="mailto:david%40larlet.fr" title="Envoyer un courriel"><svg class="icon icon-mail">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-mail"></use>
</svg> Email</a> •
<abbr class="nowrap" title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340"><svg class="icon icon-hammer2">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-hammer2"></use>
</svg> Légal</abbr>
</p>
<template id="theme-selector">
<form>
<fieldset>
<legend><svg class="icon icon-brightness-contrast">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-brightness-contrast"></use>
</svg> Thème</legend>
<label>
<input type="radio" value="auto" name="chosen-color-scheme" checked> Auto
</label>
<label>
<input type="radio" value="dark" name="chosen-color-scheme"> Foncé
</label>
<label>
<input type="radio" value="light" name="chosen-color-scheme"> Clair
</label>
</fieldset>
</form>
</template>
</footer>
<script src="/static/david/js/instantpage-5.1.0.min.js" type="module"></script>
<script>
function loadThemeForm(templateName) {
const themeSelectorTemplate = document.querySelector(templateName)
const form = themeSelectorTemplate.content.firstElementChild
themeSelectorTemplate.replaceWith(form)

form.addEventListener('change', (e) => {
const chosenColorScheme = e.target.value
localStorage.setItem('theme', chosenColorScheme)
toggleTheme(chosenColorScheme)
})

const selectedTheme = localStorage.getItem('theme')
if (selectedTheme && selectedTheme !== 'undefined') {
form.querySelector(`[value="${selectedTheme}"]`).checked = true
}
}

const prefersColorSchemeDark = '(prefers-color-scheme: dark)'
window.addEventListener('load', () => {
let hasDarkRules = false
for (const styleSheet of Array.from(document.styleSheets)) {
let mediaRules = []
for (const cssRule of styleSheet.cssRules) {
if (cssRule.type !== CSSRule.MEDIA_RULE) {
continue
}
// WARNING: Safari does not have/supports `conditionText`.
if (cssRule.conditionText) {
if (cssRule.conditionText !== prefersColorSchemeDark) {
continue
}
} else {
if (cssRule.cssText.startsWith(prefersColorSchemeDark)) {
continue
}
}
mediaRules = mediaRules.concat(Array.from(cssRule.cssRules))
}

// WARNING: do not try to insert a Rule to a styleSheet you are
// currently iterating on, otherwise the browser will be stuck
// in a infinite loop…
for (const mediaRule of mediaRules) {
styleSheet.insertRule(mediaRule.cssText)
hasDarkRules = true
}
}
if (hasDarkRules) {
loadThemeForm('#theme-selector')
}
})
</script>
</body>
</html>

+ 97
- 0
cache/2022/571d5d3f9d63d9ec4a8107e5abd15941/index.md View File

@@ -0,0 +1,97 @@
title: Why not everything I do is “Open” or “Free”
url: https://overengineer.dev/blog/2021/12/12/why-not-everything-i-do-is-open-or-free.html
hash_url: 571d5d3f9d63d9ec4a8107e5abd15941

<p>There is a high chance that, if you know me, you know me for some of my work on Free and/or Open Source projects, and you might know me as a supporter of such projects and parts of the culture. So it might seem odd that I deliberately decide <em>not</em> to release some of my work under such terms. I have been asked so many times about this, I decided to take the time and put my thoughts into a thing I can link to. This is more a collection of individual thoughts rather than a cohesive article.</p>

<h2 id="software-projects">Software projects</h2>

<p>I consider myself lucky in the way that I not only got the chance to work on and with a lot of amazing Free and/or Open Source projects in my free time, but that I am also able to spend my workdays working on Open Source software and earn my living that way. I had the chance to join a great project in its early days. Over time, that project grew to over 12k stars on GitHub, and I eventually ended up leading that project from an administrative side. Unfortunately, while most of that work was incredibly rewarding and fun, I also learned about the issues in such projects.</p>

<h3 id="code-dumping-does-not-work">“Code dumping” does not work</h3>

<p>A lot of people suggest “just upload your code to a code-sharing site and be done with it”. Not only do I personally find that incredibly counterproductive, but the whole idea of “Dump and Forget” does not work out.</p>

<p>Imagine building a little RTMP server in Rust, because you are frustrated with the nginx RTMP modules, and you wanted to learn Rust anyway. So you create a public GitHub repository and start working on it. After some months, you have reached a state where “the basics work just fine”, and then you stop working on it because you moved on towards new and more exciting things. Maybe you even had the foresight to add a “this project is incomplete and unmaintained” notice to the README. Sometime in the future, somebody will find your project. It could be that they searched for “RTMP server in Rust” and found it. Maybe they just looked through the “#rtmp” tag on GitHub, or they reached your project by other means. And instead of just moving on and looking at other projects, some people <em>will</em> skip your warnings.</p>

<p>I had multiple projects of that kind. And even though I had very explicit warnings about projects not being production-ready in the README - some projects even had the “archived” status on GitHub - that did not stop people from actually looking into it. I received countless issues and emails with “suggestions” (read: demands) on what to add and questions about how to build and run things because some outdated dependency did break or was no longer available. I even once had a company reach out to me, asking for help because a piece of server automation I shared ended up messing up their production environment, hoping I could help them figure out what happened. Unfortunately, I could not, and I ended up deleting that project.</p>

<p>When I share software projects publicly, then I do this because I think that a) someone could use that project to help them solve an issue, or b) they could learn something from looking at how I solved an issue or how I implemented a specific piece of logic. Quite honestly, for most of the projects we all create “on the side”, neither is true. Dumping unfinished, unpolished, unmaintained, and potentially badly designed or even insecure projects onto the internet is not benefitting anyone.</p>

<h3 id="open-source-is-not-just-about-open-source">Open Source is not just about open source</h3>

<p>Here is the thing: making a project’s code accessible to any audience is just a small piece of running an open-source <em>project</em>. Take GitHub, for example: you can turn off the issue tracker and turn off project discussions, but you cannot turn off the ability for people to create pull requests. And I get that, the whole “fork it, change it, and submit your changes upstream” culture is a huge part of open source - and one part I really like about (F)OSS projects.</p>

<p>The problem, though, is that reviewing pull requests, paying adequate attention, and providing helpful feedback takes <em>a lot</em> of time and energy. Reviewing code sometimes feels harder than writing code, and I do believe that this is true to a certain extend: you not only have to understand the intentions of the person writing the code, you also have to think about how this new code fits into the existing system and if there are any side-effects that might be tricky to catch from looking at the implementation itself. As an individual who just uploaded pieces of code to GitHub without considering them “a project”, you have two options:</p>

<ol>
<li>Just merging pretty much everything without too much care or attention. This is surprisingly common in smaller projects, but I can’t see how that’s a good idea. Projects that work like that frequently make breaking changes by accident, break completely, or end up in a state where the code is inconsistent or hard to maintain. When your project is large enough that people actually do submit pull requests for it, then your project is likely used by a non-zero amount of other folks. Leaving your project in an unstable or unpredictable state will cause more frustration and harm than not making your project available in the first place.</li>
<li>Ignoring Pull Requests completely. This is just… kinda disrespectful. Sure, if you have a note in your README that says you’ll not accept pull requests, or something similar, then you would be justified in just ignoring them or closing them without taking a look. But if you get a pull request, then someone else has spent time on your project, and just throwing that away is not good. Ignoring pull requests has an unfortunate side effect as well: the people working on and with your project could just continue their work in their own fork without ever bringing the changes upstream. This might sound like a feature at first, but this can become harmful as soon as there is more than one active fork. Forks usually do not sync back up, so you end up with multiple completely diverging projects that all have their pros and cons, and the “which fork should I be using?” question becomes a big issue for users.</li>
</ol>

<p>Running a (F)OSS project is not just about managing contributions to code, though. You will also get questions from users of your project, you usually have to provide a lot of documentation, maybe even plan out “stable” releases, and properly tag and distribute those… There’s a lot of stuff that needs to be done, and that all takes a lot of time. If you’re not committed to spending that time, then you cannot run a project, and you shouldn’t even try.</p>

<h3 id="when-projects-become-big">When projects become big</h3>

<p>If you are lucky - or unlucky - enough, your project might become big. Unless you are a company, or your project is for some other reason part of your work life and not just a volunteering side project, I consider projects becoming big a curse. The increase in contributors is not proportional to the increase of time and effort you have to spend to keep a project alive. Even if you publish something like a code library that’s only ever used by fellow programmers, the amount of questions and suggestions will always exceed the number of contributions - and unfortunately, providing support is one of the tasks most contributors don’t like to help out on, because “that’s the maintainers job”.</p>

<p>In one large project I’ve worked on, I found myself in a situation where 90% of my time was spent helping people, leading discussions, generally moderating communication channels, reviewing pull requests, making architectural suggestions, … - and only 10% with actually writing code. All that non-code work can be super fun and rewarding, and I enjoyed it a lot. But if you start a project because you want to write code, this can be troubling. :)</p>

<p>One thing that <em>does</em> scale with your project size is the number of bad actors. And I’m not even talking about people who’re trying to find security vulnerabilities in your project with malicious intents, but rather people who disrupt discussions and people whose primary motivation appears to be to annoy maintainers. Now, this is obviously not a binary state, but rather a huge gradient of different behaviors, and sometimes, the bad behavior might not even be deliberate.</p>

<p>If you are using a project, and that project breaks or changes in a way that you find bad, you might be annoyed. If you found a project that <em>almost</em> solves your need but falls short on a single aspect, you might request a feature or suggest a change, and you might be agitated if you do not get positive responses to that. If you are a contributor, and your pull request got rejected, or you just received the fourth round of review tasks that will take you multiple days, you might be angry and wish for that task to just be done already. All those people might use a project’s discussion board, chatrooms, issue trackers, or just social media, to vent that frustration. And honestly, I kinda get that.</p>

<p>Unfortunately, all this sums up if you are on the receiving end of those vents. You could leave all that stuff alone and just ignore it, but you know that this will turn your project’s communication channel into a wasteland that nobody can use productively. Or you start moderating things, but this will make the people in question even angrier and thus will cause you even more work. There is no win-condition here, and no matter how Rainbow Unicorn’y your project is, you <em>will</em> run into those situations.</p>

<p>As soon as your project becomes big, a lot of people will be very angry with you, all the time, for all kinds of reasons. The project’s website with documentation went down while you were sleeping? You shipped a bug affecting a company that makes millions with an application that uses your library? You need more than eleven seconds to resolve a security issue and ship a release? You decide that you would like to take the project in a different direction and one of your contributors is not happy with it? You decide that you will not be looking at this one giant pull request this Sunday? You asked for … a donation? You will be yelled at, no matter what you do.</p>

<h3 id="responsibility-and-mental-stress">Responsibility, and mental stress</h3>

<p>I am trying to make this post as generic as possible, but this is a section where I have to talk about <em>me</em>. Many people are fine with the things I wrote above, and they can just deal with the constant negative things and just feed off the positive experiences. Unfortunately, I am not that kind of person. Nobody would call 2020 or 2021 <em>good</em> years, but for me, my (F)OSS work reached a point where I had to hit the emergency brake. While I am usually okay with not letting yelling people get to me, brains do this funny thing where they accumulate multiple simultaneous problems into a state where everything wants to explode.</p>

<p>I worked on a project that was always very important to me for years. Not just because I used it a lot, but also because I thought it was an important project and because I liked the community around it. Over time, I naturally “evolved” from writing code into spending most of my time with the other non-code’y things I mentioned above, and honestly, I quite liked it. At one point, I decided that the project’s less-than-ideal public-facing website, as well as developer and user documentation, is something that needs more attention. So I did what every rational human would do and came up with a plan to rebuild everything in that category completely from scratch. You will not be surprised to learn that, while this decision made sense and the plans I came up with were pretty good, this did not get done. There just were too many other things that needed to be done, and I am not the kind of person who gets a lot of satisfaction out of spending all of my free time writing documentation and marketing texts.</p>

<p>However, this left me in a peculiar spot. We all agreed that this work was important, I started this work, and I owned this work. More often than not, when I felt like working on that project, I did not feel like working on the documentation piece. But because I felt this work was the <em>most important</em> thing I could do, I convinced myself that I should prioritize that work and not do other things. This, however, only resulted in me not doing anything at all. Eventually, I felt <em>bad</em> for not working on that project and then tried to force myself into it. This <em>worked</em> a bit, but my output was, naturally, not the best quality. Because the project was important to me, and because I can be a bit of a perfectionist, this led into a spiral where I felt bad for the work that was done and thus felt like not working on it, while also feeling bad for not working on it. Very fun state to be in!</p>

<p>I tried powering through that, and this is how it went:</p>

<p class="center"><img src="/statics/blog/20211212/github-graph.png" alt='A screenshot of the "GitHub Contribution Graph". The first half of the graph shows a lot of activity, where the majority of squares are marked. The second half, however, shows a significant drop in activity.' class="center">
(<em>Screenshot of my “GitHub Contribution Graph”, taken in May 2021. You can clearly see the point where I decided I had enough: December 2020.</em>)</p>

<p>This “documentation project” issue alone would have been resolvable. I could have just ended that project or gotten other people into contributing more to those efforts. Unfortunately, such problems never come alone in large projects because you’re not working alone and you’re not in a bubble. In my case, these feelings were paired with me using that project less and less, with a not insignificant amount of people constantly demanding to implement certain features, asking “why is X not done yet?”, and continuously criticizing some of my decisions and some of the project’s decision in a very aggressive manner.</p>

<p>I ended up completely dropping out of that project as a way of preserving my mental health. In fact, I dropped out of all my (F)OSS projects, and I even deleted some of my “code dump” projects on GitHub.</p>

<p>Now, I’m not going to write about burnout, especially (F)OSS maintainer’s burnout, or about the unreasonable expectations people have towards project maintainers. If you have read this post this far, you most likely have read articles about this that explained things far better than I could do. But this whole ordeal has absolutely contributed to my decision to massively scale down the number of “open” and “free” things I work on. If I want to release a project as Open Source, then I absolutely want to make sure that these things do not become an issue again. However, for most projects, this kind of preparation is simply not worth it.</p>

<h2 id="hardware-projects-and-hardware-designs">Hardware projects and hardware designs</h2>

<p>Enough about software. Sometimes, I do hardware projects as well: everything from 3D printed designs to electrical engineering. These projects are lesser-known, mainly because I’ve never really shared them besides some post on social media and some chats with friends, but they exist nonetheless<sup id="fnref:1"></sup>. All the reasons I previously explained still apply here, and I do not want these projects to be open for collaboration most of the time. However, there are additional points here, and the most important one is:</p>

<p>I’m not an expert on these things.</p>

<p>Hardware projects are always a bit more complicated than software projects. If software goes wrong, at least for the kinds of software I create, you might get a crash or two, or something might not work correctly, but no considerable harm will be done. For hardware projects, the consequences of a “bug” are far more severe: You could waste a lot of material and energy trying to reproduce a 3D print. You could actually physically <em>break</em> stuff while trying to modify an existing appliance. Hardware projects could result in broken components, or worse: in broken devices you attached my projects to. I don’t want to be responsible for any of that.</p>

<p>When I work on a hardware project, I very much only build things for myself. The measurements are <em>exactly</em> what I need and fine-tuned to what I know I can produce. Electronics are designed to work in the environment I build and the limitations I set up. The firmware does precisely what I need it to in a very stubborn way, and especially the “smart” “devices” usually depend on other pieces of infrastructure that are very special to my home.</p>

<p>While turning those projects into things that could be useful in other environments and more generalized setups, I consider them a playground (and learning ground) for myself, and I generally do not want to spend the time on making it more useful to more than just me.</p>

<h2 id="artsy-and-creative-things">Artsy and creative things</h2>

<p>I used to publish all my photos and other stuff using a license that allowed usage of my things without any license fees, even in commercial environments. The only limitation was that you needed to properly credit me as the author. These days, I do not use free licenses for my contents anymore.</p>

<p>“Clearly state who made this thing” sounds like a simple requirement, but it was frustrating how frequently this was violated. Frequently, users of “alternative social networks” posted my content without any credit whatsoever and then reacted aggressively and defensively when asked to stop doing that and asked to respect the license terms. This is especially ironic since it’s the same group of people that frequently <em>shames</em> artists for not using those kinds of licenses in the first place.</p>

<p>However, what finally tipped me over into no longer using this kind of license was when a multi-billion dollar company used several of my photos from a certain location in a print brochure to advertise their expensive all-inclusive holiday packages to that exact location. Being a nice guy, I started by sending them a friendly email, asking them to maybe consider not violating my license, and instructing them how and where to properly credit me according to the license. As you would expect, I received zero response to that.</p>

<p>So I ended up hiring a lawyer and pursuing legal action against that company. Unfortunately, this turned out to be a huge pain. Many legal systems are based around the concept of <em>damages</em> and <em>indemnification</em>, but as it turns out, it’s really hard to claim damage when you’re literally giving away stuff for free. Try finding an attorney with experience in international copyright affairs if the monetary damage you claim is Zero! It’s also super frustrating if the same case involves parties from many different countries, where Copyright appears to be even weirder than it is in Germany. Ultimately, after way more than a year of legal battle, the best outcome we could achieve was that that company paid a laughable amount of money (actually less than my camera setup that took this photo is worth), stops printing new flyers with my photos, and that the company has to cover my legal expenses in this case.</p>

<p>If dealing with such topics is part of sharing things online anyway, then at least I want to have some control over it. I share things because I want others to look at them and not because I want others to re-use them. I can achieve what I want to achieve by simply not using the kinds of licenses that have caused me issues before, and as time has shown, the individuals who redistribute things without any credit or care will do it anyway.</p>

<h2 id="but-what-if-you-really-want-to-use-something-i-did">But what if you <em>really</em> want to use something I did?</h2>

<p>There is a chance that you’ve reached this article because I linked to it somewhere else. In that case, you might still be really interested in using or getting access to a thing I did. If that is the case, simply reach out to me. You can find contact information on <a href="/me/card.html">my profile on this website</a>.</p>

<p>If you’re a private individual who wants to use a photo on a personal website, or you want to build something on top of a hardware project I did, this should be really simple to work out. Get in touch, and let’s have a chat. If you have commercial interests or are a company, I still encourage you to reach out. However, please note that I’m unlikely to give away things for free depending on what we’re talking about and depending on your use case. At the same time, I can provide you with legal and taxable invoices for almost all countries, so I am sure you will be fine.</p>

<p>If you made it this far into this text… I hope you have a nice day. Stay safe, take care!</p>

+ 202
- 0
cache/2022/6e3580538a14b52ac9cb5fd54dfa1384/index.html View File

@@ -0,0 +1,202 @@
<!doctype html><!-- This is a valid HTML5 document. -->
<!-- Screen readers, SEO, extensions and so on. -->
<html lang="fr">
<!-- Has to be within the first 1024 bytes, hence before the `title` element
See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
<meta charset="utf-8">
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
<!-- The viewport meta is quite crowded and we are responsible for that.
See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
<meta name="viewport" content="width=device-width,initial-scale=1">
<!-- Required to make a valid HTML5 document. -->
<title>writing as a practice (archive) — David Larlet</title>
<meta name="description" content="Publication mise en cache pour en conserver une trace.">
<!-- That good ol' feed, subscribe :). -->
<link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/">
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png">
<link rel="manifest" href="/static/david/icons2/site.webmanifest">
<link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c">
<link rel="shortcut icon" href="/static/david/icons2/favicon.ico">
<meta name="msapplication-TileColor" content="#f7f7f7">
<meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml">
<meta name="theme-color" content="#f7f7f7" media="(prefers-color-scheme: light)">
<meta name="theme-color" content="#272727" media="(prefers-color-scheme: dark)">
<!-- Documented, feel free to shoot an email. -->
<link rel="stylesheet" href="/static/david/css/style_2021-01-20.css">
<!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. -->
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<script>
function toggleTheme(themeName) {
document.documentElement.classList.toggle(
'forced-dark',
themeName === 'dark'
)
document.documentElement.classList.toggle(
'forced-light',
themeName === 'light'
)
}
const selectedTheme = localStorage.getItem('theme')
if (selectedTheme !== 'undefined') {
toggleTheme(selectedTheme)
}
</script>

<meta name="robots" content="noindex, nofollow">
<meta content="origin-when-cross-origin" name="referrer">
<!-- Canonical URL for SEO purposes -->
<link rel="canonical" href="https://winnielim.org/journal/writing-as-a-practice/">

<body class="remarkdown h1-underline h2-underline h3-underline em-underscore hr-center ul-star pre-tick" data-instant-intensity="viewport-all">


<article>
<header>
<h1>writing as a practice</h1>
</header>
<nav>
<p class="center">
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="https://winnielim.org/journal/writing-as-a-practice/" title="Lien vers le contenu original">Source originale</a>
</p>
</nav>
<hr>
<p>For most of my life, I depended on my feelings to do things. Writing was one of them. I could write regularly because I loved it and I actively wanted to write. But something has changed in the past few years. I am not really sure what exactly has changed, but if I were to hypothesise I think gaining inner peace is not really good for writing – at least in my shoes.</p>

<p>I am definitely not at peace, but my inner state is a lot less noisy than before. I was always simmering with some level of suffering that was induced by some form of self-torture. Thus I had looked forward to writing as a form of catharsis. There was so much pent-up energy, so much repressed sadness and anger.</p>

<p>Now I am a lot more moderate in my thinking and actions, so as a result everything else is also more moderate. Moderation is not a really good state for writing because it doesn’t compel – it doesn’t make our emotions well up ready to burst at any moment. Slowly, I sort of lost the desire to write. I say ‘sort of’ because now I can see that it is not that I truly lost the desire to write, it is just that I was so used to feeling a sort of emotion that would compel me to write, and I associated that with the actual desire to do so. </p>

<hr class="wp-block-separator">

<p>I didn’t “feel” like writing this piece for example, but I designated time to write this because I intellectually thought it was important. Now that I am actually in the middle it I am enjoying the process and the sound of words unfolding from my fingers. So if I had waited to “feel” like writing I probably wouldn’t have written for a long while until some major event shakes my life.</p>

<p>I guess I need to get used to my mind pulsing a lot slower now – the words are still there, but not boiling over like before. I just need to set aside some time and space for them to gently appear instead of how they used to be so fast and furious.</p>

<hr class="wp-block-separator">

<p>After going back and forth on this for now I am settling into the position that publishing regularly is a healthy practice for me. I was tempted to totally stop publishing because I just wasn’t sure if there was any value. Maybe I’ll still change my mind some day, but currently I think the practice of publishing regularly keeps me honest. It can be awkward and embarrassing when I realised I no longer agree with what I wrote, but to have a public changelog of how I have evolved as a person is somewhat humbling and clarifying. </p>

<p>Somehow the thoughts and words that appear on this website is very different from the ones in my private journals. I seem to have a different persona that is only revealed on this website. I appreciate quite a bit of stuff I have written here in the past, stuff that perhaps I wouldn’t have a record of if I didn’t make it a regular habit to capture a somewhat weekly snapshot of my psyche.</p>

<hr class="wp-block-separator">

<p>With the intention of gifting myself more flexibility, I had an invisible rule that I could publish any day I wanted as long as it was once per week. But as the days went by I found myself elongating the days in-between. Instead of publishing once every seven days I was averaging ten, sometimes 14 – as once per week became the first and last days of two weeks. </p>

<p>A few weeks back I decided I would go back to publishing on sunday, rain or shine. It is just easier to have a fixed and regular practice when I know I should show up and write no matter what. But I wouldn’t have known if I didn’t <a href="https://winnielim.org/journal/changing-the-way-i-write-and-publish/" data-type="post" data-id="3578">try otherwise</a>. </p>

<p>I am trying to write drafts earlier though, instead of writing a full post in one sitting. Hopefully I’ll get to know my own cadence soon, and learn how to write meatier posts across multiple sittings in a more sustainable manner, on top of these stream-of-consciousness snapshots.</p>

<figure class="wp-block-image size-large is-resized"><img src="https://winnielim.org/wp-content/uploads/2022/03/winnielim-publishing-day-ii-1600x1067.png" alt="illustration on designated publishing day" class="wp-image-4295" srcset="https://winnielim.org/wp-content/uploads/2022/03/winnielim-publishing-day-ii-1600x1067.png 1600w, https://winnielim.org/wp-content/uploads/2022/03/winnielim-publishing-day-ii-700x467.png 700w, https://winnielim.org/wp-content/uploads/2022/03/winnielim-publishing-day-ii-300x200.png 300w, https://winnielim.org/wp-content/uploads/2022/03/winnielim-publishing-day-ii-768x512.png 768w, https://winnielim.org/wp-content/uploads/2022/03/winnielim-publishing-day-ii-1536x1024.png 1536w, https://winnielim.org/wp-content/uploads/2022/03/winnielim-publishing-day-ii-2048x1365.png 2048w" sizes="(max-width: 800px) 100vw, 800px"></figure>

<p>I guess this is a very long way to say that I am back to publishing every sunday – which I had been doing for years since 2011 before the recent few – if you show up here on monday you could probably read something new. In-between I am still hoping to write a few<a href="/notes" data-type="URL" data-id="/notes"> notes</a> here and there. I’ve always taken the ease of writing for granted because as mentioned I’ve always had thoughts bubbling over eagerly waiting to be translated into the written form, but as I get older and busier with other non-mind stuff like cooking, I have realised how much it takes to sit down, go into a light form of trance and write, even if it is just a short note.</p>

<p>But I think overall it is worth it if I bother to carve out this intentional space, because I learn so much from these past forgotten words my older selves have written.</p>
</article>


<hr>

<footer>
<p>
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="/david/log/" title="Accès au flux RSS"><svg class="icon icon-rss2">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-rss2"></use>
</svg> Suivre</a> •
<a href="http://larlet.com" title="Go to my English profile" data-instant><svg class="icon icon-user-tie">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-user-tie"></use>
</svg> Pro</a> •
<a href="mailto:david%40larlet.fr" title="Envoyer un courriel"><svg class="icon icon-mail">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-mail"></use>
</svg> Email</a> •
<abbr class="nowrap" title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340"><svg class="icon icon-hammer2">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-hammer2"></use>
</svg> Légal</abbr>
</p>
<template id="theme-selector">
<form>
<fieldset>
<legend><svg class="icon icon-brightness-contrast">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-brightness-contrast"></use>
</svg> Thème</legend>
<label>
<input type="radio" value="auto" name="chosen-color-scheme" checked> Auto
</label>
<label>
<input type="radio" value="dark" name="chosen-color-scheme"> Foncé
</label>
<label>
<input type="radio" value="light" name="chosen-color-scheme"> Clair
</label>
</fieldset>
</form>
</template>
</footer>
<script src="/static/david/js/instantpage-5.1.0.min.js" type="module"></script>
<script>
function loadThemeForm(templateName) {
const themeSelectorTemplate = document.querySelector(templateName)
const form = themeSelectorTemplate.content.firstElementChild
themeSelectorTemplate.replaceWith(form)

form.addEventListener('change', (e) => {
const chosenColorScheme = e.target.value
localStorage.setItem('theme', chosenColorScheme)
toggleTheme(chosenColorScheme)
})

const selectedTheme = localStorage.getItem('theme')
if (selectedTheme && selectedTheme !== 'undefined') {
form.querySelector(`[value="${selectedTheme}"]`).checked = true
}
}

const prefersColorSchemeDark = '(prefers-color-scheme: dark)'
window.addEventListener('load', () => {
let hasDarkRules = false
for (const styleSheet of Array.from(document.styleSheets)) {
let mediaRules = []
for (const cssRule of styleSheet.cssRules) {
if (cssRule.type !== CSSRule.MEDIA_RULE) {
continue
}
// WARNING: Safari does not have/supports `conditionText`.
if (cssRule.conditionText) {
if (cssRule.conditionText !== prefersColorSchemeDark) {
continue
}
} else {
if (cssRule.cssText.startsWith(prefersColorSchemeDark)) {
continue
}
}
mediaRules = mediaRules.concat(Array.from(cssRule.cssRules))
}

// WARNING: do not try to insert a Rule to a styleSheet you are
// currently iterating on, otherwise the browser will be stuck
// in a infinite loop…
for (const mediaRule of mediaRules) {
styleSheet.insertRule(mediaRule.cssText)
hasDarkRules = true
}
}
if (hasDarkRules) {
loadThemeForm('#theme-selector')
}
})
</script>
</body>
</html>

+ 65
- 0
cache/2022/6e3580538a14b52ac9cb5fd54dfa1384/index.md View File

@@ -0,0 +1,65 @@
title: writing as a practice
url: https://winnielim.org/journal/writing-as-a-practice/
hash_url: 6e3580538a14b52ac9cb5fd54dfa1384

<p>For most of my life, I depended on my feelings to do things. Writing was one of them. I could write regularly because I loved it and I actively wanted to write. But something has changed in the past few years. I am not really sure what exactly has changed, but if I were to hypothesise I think gaining inner peace is not really good for writing – at least in my shoes.</p>



<p>I am definitely not at peace, but my inner state is a lot less noisy than before. I was always simmering with some level of suffering that was induced by some form of self-torture. Thus I had looked forward to writing as a form of catharsis. There was so much pent-up energy, so much repressed sadness and anger.</p>



<p>Now I am a lot more moderate in my thinking and actions, so as a result everything else is also more moderate. Moderation is not a really good state for writing because it doesn’t compel – it doesn’t make our emotions well up ready to burst at any moment. Slowly, I sort of lost the desire to write. I say ‘sort of’ because now I can see that it is not that I truly lost the desire to write, it is just that I was so used to feeling a sort of emotion that would compel me to write, and I associated that with the actual desire to do so. </p>



<hr class="wp-block-separator">



<p>I didn’t “feel” like writing this piece for example, but I designated time to write this because I intellectually thought it was important. Now that I am actually in the middle it I am enjoying the process and the sound of words unfolding from my fingers. So if I had waited to “feel” like writing I probably wouldn’t have written for a long while until some major event shakes my life.</p>



<p>I guess I need to get used to my mind pulsing a lot slower now – the words are still there, but not boiling over like before. I just need to set aside some time and space for them to gently appear instead of how they used to be so fast and furious.</p>



<hr class="wp-block-separator">



<p>After going back and forth on this for now I am settling into the position that publishing regularly is a healthy practice for me. I was tempted to totally stop publishing because I just wasn’t sure if there was any value. Maybe I’ll still change my mind some day, but currently I think the practice of publishing regularly keeps me honest. It can be awkward and embarrassing when I realised I no longer agree with what I wrote, but to have a public changelog of how I have evolved as a person is somewhat humbling and clarifying. </p>



<p>Somehow the thoughts and words that appear on this website is very different from the ones in my private journals. I seem to have a different persona that is only revealed on this website. I appreciate quite a bit of stuff I have written here in the past, stuff that perhaps I wouldn’t have a record of if I didn’t make it a regular habit to capture a somewhat weekly snapshot of my psyche.</p>



<hr class="wp-block-separator">



<p>With the intention of gifting myself more flexibility, I had an invisible rule that I could publish any day I wanted as long as it was once per week. But as the days went by I found myself elongating the days in-between. Instead of publishing once every seven days I was averaging ten, sometimes 14 – as once per week became the first and last days of two weeks. </p>



<p>A few weeks back I decided I would go back to publishing on sunday, rain or shine. It is just easier to have a fixed and regular practice when I know I should show up and write no matter what. But I wouldn’t have known if I didn’t <a href="https://winnielim.org/journal/changing-the-way-i-write-and-publish/" data-type="post" data-id="3578">try otherwise</a>. </p>



<p>I am trying to write drafts earlier though, instead of writing a full post in one sitting. Hopefully I’ll get to know my own cadence soon, and learn how to write meatier posts across multiple sittings in a more sustainable manner, on top of these stream-of-consciousness snapshots.</p>



<figure class="wp-block-image size-large is-resized"><img src="https://winnielim.org/wp-content/uploads/2022/03/winnielim-publishing-day-ii-1600x1067.png" alt="illustration on designated publishing day" class="wp-image-4295" srcset="https://winnielim.org/wp-content/uploads/2022/03/winnielim-publishing-day-ii-1600x1067.png 1600w, https://winnielim.org/wp-content/uploads/2022/03/winnielim-publishing-day-ii-700x467.png 700w, https://winnielim.org/wp-content/uploads/2022/03/winnielim-publishing-day-ii-300x200.png 300w, https://winnielim.org/wp-content/uploads/2022/03/winnielim-publishing-day-ii-768x512.png 768w, https://winnielim.org/wp-content/uploads/2022/03/winnielim-publishing-day-ii-1536x1024.png 1536w, https://winnielim.org/wp-content/uploads/2022/03/winnielim-publishing-day-ii-2048x1365.png 2048w" sizes="(max-width: 800px) 100vw, 800px"></figure>



<p>I guess this is a very long way to say that I am back to publishing every sunday – which I had been doing for years since 2011 before the recent few – if you show up here on monday you could probably read something new. In-between I am still hoping to write a few<a href="/notes" data-type="URL" data-id="/notes"> notes</a> here and there. I’ve always taken the ease of writing for granted because as mentioned I’ve always had thoughts bubbling over eagerly waiting to be translated into the written form, but as I get older and busier with other non-mind stuff like cooking, I have realised how much it takes to sit down, go into a light form of trance and write, even if it is just a short note.</p>



<p>But I think overall it is worth it if I bother to carve out this intentional space, because I learn so much from these past forgotten words my older selves have written.</p>

+ 325
- 0
cache/2022/850c5e99f499d9703c9b9bc116914429/index.html View File

@@ -0,0 +1,325 @@
<!doctype html><!-- This is a valid HTML5 document. -->
<!-- Screen readers, SEO, extensions and so on. -->
<html lang="fr">
<!-- Has to be within the first 1024 bytes, hence before the `title` element
See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
<meta charset="utf-8">
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
<!-- The viewport meta is quite crowded and we are responsible for that.
See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
<meta name="viewport" content="width=device-width,initial-scale=1">
<!-- Required to make a valid HTML5 document. -->
<title>« Logiciel libre » et « Open Source », c'est pareil ou pas ? (archive) — David Larlet</title>
<meta name="description" content="Publication mise en cache pour en conserver une trace.">
<!-- That good ol' feed, subscribe :). -->
<link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/">
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png">
<link rel="manifest" href="/static/david/icons2/site.webmanifest">
<link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c">
<link rel="shortcut icon" href="/static/david/icons2/favicon.ico">
<meta name="msapplication-TileColor" content="#f7f7f7">
<meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml">
<meta name="theme-color" content="#f7f7f7" media="(prefers-color-scheme: light)">
<meta name="theme-color" content="#272727" media="(prefers-color-scheme: dark)">
<!-- Documented, feel free to shoot an email. -->
<link rel="stylesheet" href="/static/david/css/style_2021-01-20.css">
<!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. -->
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<script>
function toggleTheme(themeName) {
document.documentElement.classList.toggle(
'forced-dark',
themeName === 'dark'
)
document.documentElement.classList.toggle(
'forced-light',
themeName === 'light'
)
}
const selectedTheme = localStorage.getItem('theme')
if (selectedTheme !== 'undefined') {
toggleTheme(selectedTheme)
}
</script>

<meta name="robots" content="noindex, nofollow">
<meta content="origin-when-cross-origin" name="referrer">
<!-- Canonical URL for SEO purposes -->
<link rel="canonical" href="https://www.bortzmeyer.org/free-software-open-source.html">

<body class="remarkdown h1-underline h2-underline h3-underline em-underscore hr-center ul-star pre-tick" data-instant-intensity="viewport-all">


<article>
<header>
<h1>« Logiciel libre » et « Open Source », c'est pareil ou pas ?</h1>
</header>
<nav>
<p class="center">
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="https://www.bortzmeyer.org/free-software-open-source.html" title="Lien vers le contenu original">Source originale</a>
</p>
</nav>
<hr>
<div class="para"><p>On entend parfois, dans les discussions autour des
<b><a class="wikipedia" hreflang="fr" href="https://fr.wikipedia.org/wiki/Licence%20de%20logiciel" title="Consultez l'article &quot;Licence de logiciel&quot; de l'encyclopédie libre Wikipedia">licences logicielles</a></b>, des affirmations du
genre « tel logiciel n'est pas libre mais il est <i class="foreign" xml:lang="en">open
source</i> ». Quelle est la différence ? Y en a-t-il une,
d'ailleurs ?</p></div>
<div class="para"><p>Commençons par les textes originaux. Le concept de
<b><a class="wikipedia" hreflang="fr" href="https://fr.wikipedia.org/wiki/Logiciel%20libre" title="Consultez l'article &quot;Logiciel libre&quot; de l'encyclopédie libre Wikipedia">logiciel libre</a></b> a été popularisé par
<b><a class="wikipedia" hreflang="fr" href="https://fr.wikipedia.org/wiki/Richard%20Stallman" title="Consultez l'article &quot;Richard Stallman&quot; de l'encyclopédie libre Wikipedia">Richard Stallman</a></b> et la
<i class="foreign" xml:lang="en"><b><a class="wikipedia" hreflang="fr" href="https://fr.wikipedia.org/wiki/Free%20Software%20Foundation" title="Consultez l'article &quot;Free Software Foundation&quot; de l'encyclopédie libre Wikipedia">Free Software
Foundation</a></b></i>. Le
logiciel libre se définit par <b class="emphasis"><a href="https://www.gnu.org/philosophy/free-sw.html">quatre libertés</a></b> :
</p><ul>
<li>Liberté de faire tourner le logiciel, c'est-à-dire de
l'utiliser à des fins quelconques.</li>
<li>Liberté d'étudier le programme, ce qui implique notamment
l'accès à son <b><a class="wikipedia" hreflang="fr" href="https://fr.wikipedia.org/wiki/Code%20source" title="Consultez l'article &quot;Code source&quot; de l'encyclopédie libre Wikipedia">code source</a></b>.</li>
<li>Liberté de distribuer des copies du logiciel,</li>
<li>y compris des copies modifiées.</li>
</ul><p>
On notera que la gratuité n'est pas mentionnée. En
<b><a class="wikipedia" hreflang="fr" href="https://fr.wikipedia.org/wiki/anglais" title="Consultez l'article &quot;anglais&quot; de l'encyclopédie libre Wikipedia">anglais</a></b>, le terme de
<i class="foreign" xml:lang="en">free software</i> a parfois engendré des
malentendus, <i class="foreign" xml:lang="en"><a href="https://en.wiktionary.org/wiki/free" hreflang="en">free</a></i> pouvant vouloir dire « libre »
mais aussi « gratuit ». Comme souvent en politique, ces malentendus
étaient parfois de bonne foi, et malhonnêtes dans
d'autres, certains faisant semblant de ne pas comprendre que la
liberté n'a rien à voir avec la gratuité.</p></div>
<div class="para"><p>Stallman aime donc répéter que, dans <i class="foreign" xml:lang="en">free
software</i>, c'est <i class="foreign" xml:lang="en">free as in free speech, not
free as in free beer</i>. Bonne explication, mais difficile
à traduire en <b><a class="wikipedia" hreflang="fr" href="https://fr.wikipedia.org/wiki/fran%C3%A7ais" title="Consultez l'article &quot;français&quot; de l'encyclopédie libre Wikipedia">français</a></b> puisque, justement,
en français, il y a deux mots différents pour « libre »
et « gratuit ».</p></div>
<div class="para"><p>Et <i class="foreign" xml:lang="en">open source</i> ? Notons que ce n'est pas un
hasard si le terme en anglais est populaire chez les gens dont le
métier est d'embrouiller le langage, les vendeurs ou les politiciens, par
exemple. Utiliser un terme en anglais permet de rester dans le
flou, et d'essayer de plaire à tout le monde, en n'utilisant pas
de termes précis. Le terme a été
popularisé par <b><a class="wikipedia" hreflang="fr" href="https://fr.wikipedia.org/wiki/Eric%20Raymond" title="Consultez l'article &quot;Eric Raymond&quot; de l'encyclopédie libre Wikipedia">Eric Raymond</a></b> et quelques
autres en 1998. Ils avançaient deux arguments essentiels en faveur de ce
nouveau terme : l'ambiguité entre « libre »
et « gratuit » (qui, on l'a vu, n'existe pas en français, rendant
tout à fait inutile l'utilisation du terme <i class="foreign" xml:lang="en">open
source</i>), et surtout le fait que la liberté faisait peur,
notamment au patronat, et que, si on voulait populariser le
logiciel libre auprès des gens qui ont la main sur la carte de
crédit de l'entreprise, il fallait changer le nom. (Il y avait
bien sûr également des raisons non avouées, comme essayer de
remplacer Stallman au poste de symbole du logiciel libre.)</p></div>
<div class="para"><p>Le terme a clairement été un grand succès, malgré le fait qu'il
soit tout aussi ambigu que l'autre (<i class="foreign" xml:lang="en">open source</i>
ou « source ouverte » désignait déjà <b><a class="wikipedia" hreflang="fr" href="https://fr.wikipedia.org/wiki/Renseignement%20d'origine%20source%20ouverte" title="Consultez l'article &quot;Renseignement d'origine source ouverte&quot; de l'encyclopédie libre Wikipedia">tout
à fait autre chose</a></b>). Que mettaient-ils derrière ce
terme ? Les promoteurs du terme <i class="foreign" xml:lang="en">open source</i> ont
produit une <a href="https://opensource.org/osd">définition</a>. Elle est moins
percutante que les « quatre libertés », et plus longue, mais elle
revient quasiment au même. Notamment, elle précise clairement
qu'<i class="foreign" xml:lang="en">open source</i> ne veut pas uniquement dire
qu'on a accès au <b><a class="wikipedia" hreflang="fr" href="https://fr.wikipedia.org/wiki/Code%20source" title="Consultez l'article &quot;Code source&quot; de l'encyclopédie libre Wikipedia">code source</a></b>.</p></div>

<div class="para"><p>Si on regarde la <a href="https://www.gnu.org/licenses/license-list.html">liste des
licences libres reconnues par la FSF</a>, et qu'on la compare
avec <a href="https://opensource.org/licenses/category">celle des promoteurs du terme open source</a>, on ne
voit en effet pas de différence. On cite parfois la question de
l'obligation de réciprocité
(<i class="foreign" xml:lang="en"><b><a class="wikipedia" hreflang="fr" href="https://fr.wikipedia.org/wiki/copyleft" title="Consultez l'article &quot;copyleft&quot; de l'encyclopédie libre Wikipedia">copyleft</a></b></i> en anglais, ou
« partage à l'identique » - <i class="foreign" xml:lang="en">Share Alike</i> - dans
les <b><a class="wikipedia" hreflang="fr" href="https://fr.wikipedia.org/wiki/Licence%20Creative%20Commons" title="Consultez l'article &quot;Licence Creative Commons&quot; de l'encyclopédie libre Wikipedia">licences Creative Commons</a></b>)
comme différence entre logiciel libre et <i class="foreign" xml:lang="en">open
source</i>. Mais cette distinction n'est jamais faite par
des gens qui participent au logiciel libre, elle n'arrive que dans
des raccourcis médiatiques. L'obligation de réciprocité (un
individu ou une entreprise peuvent
distribuer le logiciel, même modifié, et même le vendre, mais on a
l'obligation de reconnaitre au destinataire les mêmes libertés que
celles dont ils ont bénéficié) n'est en effet pas mentionnée dans
les quatre libertés qui définissent le logiciel libre. Les
personnes qui ne se sont pas renseignées avant et qui disent que
le logiciel libre requiert l'obligation de réciprocité sont donc
plus stricts sur la définition <a href="https://www.gnu.org/licenses/gpl-faq.html#DoesFreeSoftwareMeanUsingTheGPL">que
Richard Stallman lui-même</a>, alors qu'il est généralement
considéré comme un modèle de strictitude.
</p></div>
<div class="para"><p>Bien qu'il existe des cas
compliqués de licences qui peuvent être vues comme libres selon
une définition et pas selon une autre, ces cas sont très
marginaux. L'immense majorité des <b><a class="wikipedia" hreflang="fr" href="https://fr.wikipedia.org/wiki/Logiciel%20%20%20%20%20libre" title="Consultez l'article &quot;Logiciel libre&quot; de l'encyclopédie libre Wikipedia">logiciels libres</a></b> est sous une licence que les
deux définitions classent comme libre. Parmi les
exceptions, on note (trouvée par Exagone313) l'amusante licence
<b><a class="wikipedia" hreflang="fr" href="https://fr.wikipedia.org/wiki/WTFPL" title="Consultez l'article &quot;WTFPL&quot; de l'encyclopédie libre Wikipedia">Foutez ce que
vous voulez</a></b>, apparemment <a href="https://opensource.org/minutes20090304">refusée par
l'Open Source Initiative</a> mais <a href="https://www.gnu.org/licenses/license-list.html">acceptée par la
FSF</a>. Mais elle est peu utilisée. (Si vous avez
d'autres références <b class="emphasis">précises</b> d'une exception, d'une licence
qui est dans une des listes de licences libres mais pas dans
l'autre, je suis preneur. En indiquant des logiciels qui utilisent
cette licence, car la plupart des licences candidates pour cet
exercice sont peu ou pas utilisées.)</p></div>
<div class="para"><p>Cette rareté des licences acceptées sous une définition mais
pas sous l'autre semble plaider pour une conclusion simple « logiciel libre
ou <i class="foreign" xml:lang="en">open source</i>, on s'en fiche, c'est
pareil ».</p></div>
<div class="para"><p>À noter que <b><a class="wikipedia" hreflang="fr" href="https://fr.wikipedia.org/wiki/Wikip%C3%A9dia" title="Consultez l'article &quot;Wikipédia&quot; de l'encyclopédie libre Wikipedia">Wikipédia</a></b> <b><a class="wikipedia" hreflang="fr" href="https://fr.wikipedia.org/wiki/Open%20source" title="Consultez l'article &quot;Open source&quot; de l'encyclopédie libre Wikipedia">reprend
cette définition</a></b> : « La désignation open source, ou
"code source ouvert", s'applique aux logiciels (et s'étend
maintenant aux œuvres de l'esprit) dont la licence respecte des
critères précisément établis par l'Open Source Initiative,
c'est-à-dire les possibilités de libre redistribution, d'accès au
code source et de création de travaux dérivés. » Et ajoute « La
différence formelle entre open source et logiciel libre (en
anglais : free software) n'a quasiment pas de conséquence dans
l'évaluation des licences. » (Le bandeau en haut de
l'article dit « Ne doit pas être confondu avec Logiciel libre »,
alors même que l'article explique que c'est pareil...) Le
<b><a class="wikipedia" hreflang="fr" href="https://fr.wikipedia.org/wiki/Wiktionnaire" title="Consultez l'article &quot;Wiktionnaire&quot; de l'encyclopédie libre Wikipedia">Wiktionnaire</a></b> dit également que les deux
termes sont synonymes.</p></div>
<div class="para"><p>Mais, évidemment, en matière de langage, les arguments
d'autorité et les références aux textes antiques ont leurs
limites. Le langage évolue (pas toujours dans le bon sens) et ce
qui est important, c'est aussi ce que veulent dire les gens. L'usage
compte. Ceux et
celles qui utilisent le terme <i class="foreign" xml:lang="en">open source</i>
veulent-ils dire la même chose que celles et ceux qui disent
logiciel libre ? Il est difficile de répondre à cette question. En
effet, si on n'utilise pas la définition « officielle », laquelle
utilise-t-on ? J'ai la nette impression que les gens qui utilisent
<i class="foreign" xml:lang="en">open source</i> n'ont pas de définition précise et
l'utilisent un peu au petit bonheur la chance. Quand on demande à
quelqu'un qui a utilisé le terme <i class="foreign" xml:lang="en">open source</i> ce
qu'ielle entend par là, on reçoit en général une réponse vague, et
souvent fausse (comme par exemple de définir <i class="foreign" xml:lang="en">open
source</i> par « accès au code source »). Les commerciaux
utilisent ce terme pour dire « logiciel libre » mais en moins
politique (la liberté, ça fait peur aux clients), les journalistes
l'utilisent parce que dans un article sur l'informatique, il faut
mettre de l'anglais, beaucoup de gens répètent simplement le terme
qu'ils ont entendu dans les médias, sans réfléchir. Si on veut une
définition fondée sur l'usage (et non pas sur la définition
formelle de l'<b><a class="wikipedia" hreflang="fr" href="https://fr.wikipedia.org/wiki/Open%20Source%20%20%20%20Initiative" title="Consultez l'article &quot;Open Source Initiative&quot; de l'encyclopédie libre Wikipedia">OSI</a></b>), on pourrait arriver à quelque chose du
genre « quelque chose qui va du logiciel libre [inclus] à diverses
formes de logiciels privateurs manifestant un peu d'ouverture ».</p></div>
<div class="para"><p>En conclusion et résumé :
</p><ul>
<li>« Logiciel libre » et « <i class="foreign" xml:lang="en">Open Source</i> »
désignent quasiment exactement les mêmes licences et donc les
mêmes logiciels. Il n'y a donc pas de différence pratique.</li>
<li>Mais dans l'usage, la plupart des emplois de
« <i class="foreign" xml:lang="en">Open Source</i> » désignent quelque chose de
vague et de pas bien défini.</li>
<li>Et les mots sont importants : utiliser « <i class="foreign" xml:lang="en">Open
Source</i> » n'est pas neutre et veut dire en général qu'on
n'est pas spécialement attaché à la liberté.</li>
</ul></div>
</article>


<hr>

<footer>
<p>
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="/david/log/" title="Accès au flux RSS"><svg class="icon icon-rss2">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-rss2"></use>
</svg> Suivre</a> •
<a href="http://larlet.com" title="Go to my English profile" data-instant><svg class="icon icon-user-tie">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-user-tie"></use>
</svg> Pro</a> •
<a href="mailto:david%40larlet.fr" title="Envoyer un courriel"><svg class="icon icon-mail">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-mail"></use>
</svg> Email</a> •
<abbr class="nowrap" title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340"><svg class="icon icon-hammer2">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-hammer2"></use>
</svg> Légal</abbr>
</p>
<template id="theme-selector">
<form>
<fieldset>
<legend><svg class="icon icon-brightness-contrast">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-brightness-contrast"></use>
</svg> Thème</legend>
<label>
<input type="radio" value="auto" name="chosen-color-scheme" checked> Auto
</label>
<label>
<input type="radio" value="dark" name="chosen-color-scheme"> Foncé
</label>
<label>
<input type="radio" value="light" name="chosen-color-scheme"> Clair
</label>
</fieldset>
</form>
</template>
</footer>
<script src="/static/david/js/instantpage-5.1.0.min.js" type="module"></script>
<script>
function loadThemeForm(templateName) {
const themeSelectorTemplate = document.querySelector(templateName)
const form = themeSelectorTemplate.content.firstElementChild
themeSelectorTemplate.replaceWith(form)

form.addEventListener('change', (e) => {
const chosenColorScheme = e.target.value
localStorage.setItem('theme', chosenColorScheme)
toggleTheme(chosenColorScheme)
})

const selectedTheme = localStorage.getItem('theme')
if (selectedTheme && selectedTheme !== 'undefined') {
form.querySelector(`[value="${selectedTheme}"]`).checked = true
}
}

const prefersColorSchemeDark = '(prefers-color-scheme: dark)'
window.addEventListener('load', () => {
let hasDarkRules = false
for (const styleSheet of Array.from(document.styleSheets)) {
let mediaRules = []
for (const cssRule of styleSheet.cssRules) {
if (cssRule.type !== CSSRule.MEDIA_RULE) {
continue
}
// WARNING: Safari does not have/supports `conditionText`.
if (cssRule.conditionText) {
if (cssRule.conditionText !== prefersColorSchemeDark) {
continue
}
} else {
if (cssRule.cssText.startsWith(prefersColorSchemeDark)) {
continue
}
}
mediaRules = mediaRules.concat(Array.from(cssRule.cssRules))
}

// WARNING: do not try to insert a Rule to a styleSheet you are
// currently iterating on, otherwise the browser will be stuck
// in a infinite loop…
for (const mediaRule of mediaRules) {
styleSheet.insertRule(mediaRule.cssText)
hasDarkRules = true
}
}
if (hasDarkRules) {
loadThemeForm('#theme-selector')
}
})
</script>
</body>
</html>

+ 158
- 0
cache/2022/850c5e99f499d9703c9b9bc116914429/index.md View File

@@ -0,0 +1,158 @@
title: « Logiciel libre » et « Open Source », c'est pareil ou pas ?
url: https://www.bortzmeyer.org/free-software-open-source.html
hash_url: 850c5e99f499d9703c9b9bc116914429

<div class="para"><p>On entend parfois, dans les discussions autour des
<b><a class="wikipedia" hreflang="fr" href="https://fr.wikipedia.org/wiki/Licence%20de%20logiciel" title="Consultez l'article &quot;Licence de logiciel&quot; de l'encyclopédie libre Wikipedia">licences logicielles</a></b>, des affirmations du
genre « tel logiciel n'est pas libre mais il est <i class="foreign" xml:lang="en">open
source</i> ». Quelle est la différence ? Y en a-t-il une,
d'ailleurs ?</p></div>
<div class="para"><p>Commençons par les textes originaux. Le concept de
<b><a class="wikipedia" hreflang="fr" href="https://fr.wikipedia.org/wiki/Logiciel%20libre" title="Consultez l'article &quot;Logiciel libre&quot; de l'encyclopédie libre Wikipedia">logiciel libre</a></b> a été popularisé par
<b><a class="wikipedia" hreflang="fr" href="https://fr.wikipedia.org/wiki/Richard%20Stallman" title="Consultez l'article &quot;Richard Stallman&quot; de l'encyclopédie libre Wikipedia">Richard Stallman</a></b> et la
<i class="foreign" xml:lang="en"><b><a class="wikipedia" hreflang="fr" href="https://fr.wikipedia.org/wiki/Free%20Software%20Foundation" title="Consultez l'article &quot;Free Software Foundation&quot; de l'encyclopédie libre Wikipedia">Free Software
Foundation</a></b></i>. Le
logiciel libre se définit par <b class="emphasis"><a href="https://www.gnu.org/philosophy/free-sw.html">quatre libertés</a></b> :
</p><ul>
<li>Liberté de faire tourner le logiciel, c'est-à-dire de
l'utiliser à des fins quelconques.</li>
<li>Liberté d'étudier le programme, ce qui implique notamment
l'accès à son <b><a class="wikipedia" hreflang="fr" href="https://fr.wikipedia.org/wiki/Code%20source" title="Consultez l'article &quot;Code source&quot; de l'encyclopédie libre Wikipedia">code source</a></b>.</li>
<li>Liberté de distribuer des copies du logiciel,</li>
<li>y compris des copies modifiées.</li>
</ul><p>
On notera que la gratuité n'est pas mentionnée. En
<b><a class="wikipedia" hreflang="fr" href="https://fr.wikipedia.org/wiki/anglais" title="Consultez l'article &quot;anglais&quot; de l'encyclopédie libre Wikipedia">anglais</a></b>, le terme de
<i class="foreign" xml:lang="en">free software</i> a parfois engendré des
malentendus, <i class="foreign" xml:lang="en"><a href="https://en.wiktionary.org/wiki/free" hreflang="en">free</a></i> pouvant vouloir dire « libre »
mais aussi « gratuit ». Comme souvent en politique, ces malentendus
étaient parfois de bonne foi, et malhonnêtes dans
d'autres, certains faisant semblant de ne pas comprendre que la
liberté n'a rien à voir avec la gratuité.</p></div>
<div class="para"><p>Stallman aime donc répéter que, dans <i class="foreign" xml:lang="en">free
software</i>, c'est <i class="foreign" xml:lang="en">free as in free speech, not
free as in free beer</i>. Bonne explication, mais difficile
à traduire en <b><a class="wikipedia" hreflang="fr" href="https://fr.wikipedia.org/wiki/fran%C3%A7ais" title="Consultez l'article &quot;français&quot; de l'encyclopédie libre Wikipedia">français</a></b> puisque, justement,
en français, il y a deux mots différents pour « libre »
et « gratuit ».</p></div>
<div class="para"><p>Et <i class="foreign" xml:lang="en">open source</i> ? Notons que ce n'est pas un
hasard si le terme en anglais est populaire chez les gens dont le
métier est d'embrouiller le langage, les vendeurs ou les politiciens, par
exemple. Utiliser un terme en anglais permet de rester dans le
flou, et d'essayer de plaire à tout le monde, en n'utilisant pas
de termes précis. Le terme a été
popularisé par <b><a class="wikipedia" hreflang="fr" href="https://fr.wikipedia.org/wiki/Eric%20Raymond" title="Consultez l'article &quot;Eric Raymond&quot; de l'encyclopédie libre Wikipedia">Eric Raymond</a></b> et quelques
autres en 1998. Ils avançaient deux arguments essentiels en faveur de ce
nouveau terme : l'ambiguité entre « libre »
et « gratuit » (qui, on l'a vu, n'existe pas en français, rendant
tout à fait inutile l'utilisation du terme <i class="foreign" xml:lang="en">open
source</i>), et surtout le fait que la liberté faisait peur,
notamment au patronat, et que, si on voulait populariser le
logiciel libre auprès des gens qui ont la main sur la carte de
crédit de l'entreprise, il fallait changer le nom. (Il y avait
bien sûr également des raisons non avouées, comme essayer de
remplacer Stallman au poste de symbole du logiciel libre.)</p></div>
<div class="para"><p>Le terme a clairement été un grand succès, malgré le fait qu'il
soit tout aussi ambigu que l'autre (<i class="foreign" xml:lang="en">open source</i>
ou « source ouverte » désignait déjà <b><a class="wikipedia" hreflang="fr" href="https://fr.wikipedia.org/wiki/Renseignement%20d'origine%20source%20ouverte" title="Consultez l'article &quot;Renseignement d'origine source ouverte&quot; de l'encyclopédie libre Wikipedia">tout
à fait autre chose</a></b>). Que mettaient-ils derrière ce
terme ? Les promoteurs du terme <i class="foreign" xml:lang="en">open source</i> ont
produit une <a href="https://opensource.org/osd">définition</a>. Elle est moins
percutante que les « quatre libertés », et plus longue, mais elle
revient quasiment au même. Notamment, elle précise clairement
qu'<i class="foreign" xml:lang="en">open source</i> ne veut pas uniquement dire
qu'on a accès au <b><a class="wikipedia" hreflang="fr" href="https://fr.wikipedia.org/wiki/Code%20source" title="Consultez l'article &quot;Code source&quot; de l'encyclopédie libre Wikipedia">code source</a></b>.</p></div>

<div class="para"><p>Si on regarde la <a href="https://www.gnu.org/licenses/license-list.html">liste des
licences libres reconnues par la FSF</a>, et qu'on la compare
avec <a href="https://opensource.org/licenses/category">celle des promoteurs du terme open source</a>, on ne
voit en effet pas de différence. On cite parfois la question de
l'obligation de réciprocité
(<i class="foreign" xml:lang="en"><b><a class="wikipedia" hreflang="fr" href="https://fr.wikipedia.org/wiki/copyleft" title="Consultez l'article &quot;copyleft&quot; de l'encyclopédie libre Wikipedia">copyleft</a></b></i> en anglais, ou
« partage à l'identique » - <i class="foreign" xml:lang="en">Share Alike</i> - dans
les <b><a class="wikipedia" hreflang="fr" href="https://fr.wikipedia.org/wiki/Licence%20Creative%20Commons" title="Consultez l'article &quot;Licence Creative Commons&quot; de l'encyclopédie libre Wikipedia">licences Creative Commons</a></b>)
comme différence entre logiciel libre et <i class="foreign" xml:lang="en">open
source</i>. Mais cette distinction n'est jamais faite par
des gens qui participent au logiciel libre, elle n'arrive que dans
des raccourcis médiatiques. L'obligation de réciprocité (un
individu ou une entreprise peuvent
distribuer le logiciel, même modifié, et même le vendre, mais on a
l'obligation de reconnaitre au destinataire les mêmes libertés que
celles dont ils ont bénéficié) n'est en effet pas mentionnée dans
les quatre libertés qui définissent le logiciel libre. Les
personnes qui ne se sont pas renseignées avant et qui disent que
le logiciel libre requiert l'obligation de réciprocité sont donc
plus stricts sur la définition <a href="https://www.gnu.org/licenses/gpl-faq.html#DoesFreeSoftwareMeanUsingTheGPL">que
Richard Stallman lui-même</a>, alors qu'il est généralement
considéré comme un modèle de strictitude.
</p></div>
<div class="para"><p>Bien qu'il existe des cas
compliqués de licences qui peuvent être vues comme libres selon
une définition et pas selon une autre, ces cas sont très
marginaux. L'immense majorité des <b><a class="wikipedia" hreflang="fr" href="https://fr.wikipedia.org/wiki/Logiciel%20%20%20%20%20libre" title="Consultez l'article &quot;Logiciel libre&quot; de l'encyclopédie libre Wikipedia">logiciels libres</a></b> est sous une licence que les
deux définitions classent comme libre. Parmi les
exceptions, on note (trouvée par Exagone313) l'amusante licence
<b><a class="wikipedia" hreflang="fr" href="https://fr.wikipedia.org/wiki/WTFPL" title="Consultez l'article &quot;WTFPL&quot; de l'encyclopédie libre Wikipedia">Foutez ce que
vous voulez</a></b>, apparemment <a href="https://opensource.org/minutes20090304">refusée par
l'Open Source Initiative</a> mais <a href="https://www.gnu.org/licenses/license-list.html">acceptée par la
FSF</a>. Mais elle est peu utilisée. (Si vous avez
d'autres références <b class="emphasis">précises</b> d'une exception, d'une licence
qui est dans une des listes de licences libres mais pas dans
l'autre, je suis preneur. En indiquant des logiciels qui utilisent
cette licence, car la plupart des licences candidates pour cet
exercice sont peu ou pas utilisées.)</p></div>
<div class="para"><p>Cette rareté des licences acceptées sous une définition mais
pas sous l'autre semble plaider pour une conclusion simple « logiciel libre
ou <i class="foreign" xml:lang="en">open source</i>, on s'en fiche, c'est
pareil ».</p></div>
<div class="para"><p>À noter que <b><a class="wikipedia" hreflang="fr" href="https://fr.wikipedia.org/wiki/Wikip%C3%A9dia" title="Consultez l'article &quot;Wikipédia&quot; de l'encyclopédie libre Wikipedia">Wikipédia</a></b> <b><a class="wikipedia" hreflang="fr" href="https://fr.wikipedia.org/wiki/Open%20source" title="Consultez l'article &quot;Open source&quot; de l'encyclopédie libre Wikipedia">reprend
cette définition</a></b> : « La désignation open source, ou
"code source ouvert", s'applique aux logiciels (et s'étend
maintenant aux œuvres de l'esprit) dont la licence respecte des
critères précisément établis par l'Open Source Initiative,
c'est-à-dire les possibilités de libre redistribution, d'accès au
code source et de création de travaux dérivés. » Et ajoute « La
différence formelle entre open source et logiciel libre (en
anglais : free software) n'a quasiment pas de conséquence dans
l'évaluation des licences. » (Le bandeau en haut de
l'article dit « Ne doit pas être confondu avec Logiciel libre »,
alors même que l'article explique que c'est pareil...) Le
<b><a class="wikipedia" hreflang="fr" href="https://fr.wikipedia.org/wiki/Wiktionnaire" title="Consultez l'article &quot;Wiktionnaire&quot; de l'encyclopédie libre Wikipedia">Wiktionnaire</a></b> dit également que les deux
termes sont synonymes.</p></div>
<div class="para"><p>Mais, évidemment, en matière de langage, les arguments
d'autorité et les références aux textes antiques ont leurs
limites. Le langage évolue (pas toujours dans le bon sens) et ce
qui est important, c'est aussi ce que veulent dire les gens. L'usage
compte. Ceux et
celles qui utilisent le terme <i class="foreign" xml:lang="en">open source</i>
veulent-ils dire la même chose que celles et ceux qui disent
logiciel libre ? Il est difficile de répondre à cette question. En
effet, si on n'utilise pas la définition « officielle », laquelle
utilise-t-on ? J'ai la nette impression que les gens qui utilisent
<i class="foreign" xml:lang="en">open source</i> n'ont pas de définition précise et
l'utilisent un peu au petit bonheur la chance. Quand on demande à
quelqu'un qui a utilisé le terme <i class="foreign" xml:lang="en">open source</i> ce
qu'ielle entend par là, on reçoit en général une réponse vague, et
souvent fausse (comme par exemple de définir <i class="foreign" xml:lang="en">open
source</i> par « accès au code source »). Les commerciaux
utilisent ce terme pour dire « logiciel libre » mais en moins
politique (la liberté, ça fait peur aux clients), les journalistes
l'utilisent parce que dans un article sur l'informatique, il faut
mettre de l'anglais, beaucoup de gens répètent simplement le terme
qu'ils ont entendu dans les médias, sans réfléchir. Si on veut une
définition fondée sur l'usage (et non pas sur la définition
formelle de l'<b><a class="wikipedia" hreflang="fr" href="https://fr.wikipedia.org/wiki/Open%20Source%20%20%20%20Initiative" title="Consultez l'article &quot;Open Source Initiative&quot; de l'encyclopédie libre Wikipedia">OSI</a></b>), on pourrait arriver à quelque chose du
genre « quelque chose qui va du logiciel libre [inclus] à diverses
formes de logiciels privateurs manifestant un peu d'ouverture ».</p></div>
<div class="para"><p>En conclusion et résumé :
</p><ul>
<li>« Logiciel libre » et « <i class="foreign" xml:lang="en">Open Source</i> »
désignent quasiment exactement les mêmes licences et donc les
mêmes logiciels. Il n'y a donc pas de différence pratique.</li>
<li>Mais dans l'usage, la plupart des emplois de
« <i class="foreign" xml:lang="en">Open Source</i> » désignent quelque chose de
vague et de pas bien défini.</li>
<li>Et les mots sont importants : utiliser « <i class="foreign" xml:lang="en">Open
Source</i> » n'est pas neutre et veut dire en général qu'on
n'est pas spécialement attaché à la liberté.</li>
</ul></div>

+ 280
- 0
cache/2022/891705d1555d09a941fd1f7685de9370/index.html View File

@@ -0,0 +1,280 @@
<!doctype html><!-- This is a valid HTML5 document. -->
<!-- Screen readers, SEO, extensions and so on. -->
<html lang="fr">
<!-- Has to be within the first 1024 bytes, hence before the `title` element
See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
<meta charset="utf-8">
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
<!-- The viewport meta is quite crowded and we are responsible for that.
See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
<meta name="viewport" content="width=device-width,initial-scale=1">
<!-- Required to make a valid HTML5 document. -->
<title>dataklasses: A different spin on dataclasses. (archive) — David Larlet</title>
<meta name="description" content="Publication mise en cache pour en conserver une trace.">
<!-- That good ol' feed, subscribe :). -->
<link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/">
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png">
<link rel="manifest" href="/static/david/icons2/site.webmanifest">
<link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c">
<link rel="shortcut icon" href="/static/david/icons2/favicon.ico">
<meta name="msapplication-TileColor" content="#f7f7f7">
<meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml">
<meta name="theme-color" content="#f7f7f7" media="(prefers-color-scheme: light)">
<meta name="theme-color" content="#272727" media="(prefers-color-scheme: dark)">
<!-- Documented, feel free to shoot an email. -->
<link rel="stylesheet" href="/static/david/css/style_2021-01-20.css">
<!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. -->
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<script>
function toggleTheme(themeName) {
document.documentElement.classList.toggle(
'forced-dark',
themeName === 'dark'
)
document.documentElement.classList.toggle(
'forced-light',
themeName === 'light'
)
}
const selectedTheme = localStorage.getItem('theme')
if (selectedTheme !== 'undefined') {
toggleTheme(selectedTheme)
}
</script>

<meta name="robots" content="noindex, nofollow">
<meta content="origin-when-cross-origin" name="referrer">
<!-- Canonical URL for SEO purposes -->
<link rel="canonical" href="https://github.com/dabeaz/dataklasses#questions-and-answers">

<body class="remarkdown h1-underline h2-underline h3-underline em-underscore hr-center ul-star pre-tick" data-instant-intensity="viewport-all">


<article>
<header>
<h1>dataklasses: A different spin on dataclasses.</h1>
</header>
<nav>
<p class="center">
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="https://github.com/dabeaz/dataklasses#questions-and-answers" title="Lien vers le contenu original">Source originale</a>
</p>
</nav>
<hr>
<p>Dataklasses is a library that allows you to quickly define data
classes using Python type hints. Here's an example of how you use it:</p>
<p>```python
from dataklasses import dataklass</p>
<p>@dataklass
class Coordinates:
x: int
y: int
```</p>
<p>The resulting class works in a well civilised way, providing the usual
<code>__init__()</code>, <code>__repr__()</code>, and <code>__eq__()</code> methods that you'd normally
have to type out by hand:</p>
<p>```python</p>
<blockquote>
<blockquote>
<blockquote>
<p>a = Coordinates(2, 3)
a
Coordinates(2, 3)
a.x
2
a.y
3
b = Coordinates(2, 3)
a == b
True</p>
<p>```</p>
</blockquote>
</blockquote>
</blockquote>
<p>It's easy! Almost too easy.</p>
<h2>Wait, doesn't this already exist?</h2>
<p>No, it doesn't. Yes, certain naysayers will be quick to point out the
existence of <code>@dataclass</code> from the standard library. Ok, sure, THAT
exists. However, it's slow and complicated. Dataklasses are neither
of those things. The entire <code>dataklasses</code> module is less than 100
lines. The resulting classes import 15-20 times faster than
dataclasses. See the <code>perf.py</code> file for a benchmark.</p>
<h2>Theory of Operation</h2>
<p>While out walking with his puppy, Dave had a certain insight about the nature
of Python byte-code. Coming back to the house, he had to try it out:</p>
<p>```python</p>
<blockquote>
<blockquote>
<blockquote>
<p>def <strong>init1</strong>(self, x, y):
... self.x = x
... self.y = y
...
def <strong>init2</strong>(self, foo, bar):
... self.foo = foo
... self.bar = bar
...
<strong>init1</strong>.<strong>code</strong>.co_code == <strong>init2</strong>.<strong>code</strong>.co_code
True</p>
<p>```</p>
</blockquote>
</blockquote>
</blockquote>
<p>How intriguing! The underlying byte-code is exactly the same even
though the functions are using different argument and attribute names.
Aha! Now, we're onto something interesting.</p>
<p>The <code>dataclasses</code> module in the standard library works by collecting
type hints, generating code strings, and executing them using the
<code>exec()</code> function. This happens for every single class definition
where it's used. If it sounds slow, that's because it is. In fact, it
defeats any benefit of module caching in Python's import system.</p>
<p>Dataklasses are different. They start out in the same manner--code is
first generated by collecting type hints and using <code>exec()</code>. However,
the underlying byte-code is cached and reused in subsequent class
definitions whenever possible. Caching is good. </p>
<h2>A Short Story</h2>
<p>Once upon a time, there was this programming language that I'll refer
to as "Lava." Anyways, anytime you started a program written in Lava,
you could just tell by the awkward silence and inactivity of your
machine before the fans kicked in. "Ah shit, this is written in Lava"
you'd exclaim.</p>
<h2>Questions and Answers</h2>
<p><strong>Q: What methods does <code>dataklass</code> generate?</strong></p>
<p>A: By default <code>__init__()</code>, <code>__repr__()</code>, and <code>__eq__()</code> methods are generated.
<code>__match_args__</code> is also defined to assist with pattern matching.</p>
<p><strong>Q: Does <code>dataklass</code> enforce the specified types?</strong></p>
<p>A: No. The types are merely clues about what the value might be and
the Python language does not provide any enforcement on its own. </p>
<p><strong>Q: Are there any additional features?</strong></p>
<p>A: No. You can either have features or you can have performance. Pick one.</p>
<p><strong>Q: Does <code>dataklass</code> use any advanced magic such as metaclasses?</strong></p>
<p>A: No. </p>
<p><strong>Q: How do I install <code>dataklasses</code>?</strong></p>
<p>A: There is no <code>setup.py</code> file, installer, or an official release. You
install it by copying the code into your own project. <code>dataklasses.py</code> is
small. You are encouraged to modify it to your own purposes.</p>
<p><strong>Q: What versions of Python does it work with?</strong></p>
<p>A: The code will work with versions 3.9 and later.</p>
<p><strong>Q: But what if new features get added?</strong></p>
<p>A: What new features? The best new features are no new features. </p>
<p><strong>Q: Who maintains dataklasses?</strong></p>
<p>A: If you're using it, you do. You maintain dataklasses.</p>
<p><strong>Q: Is this actually a serious project?</strong></p>
<p>A: It's best to think of dataklasses as more of an idea than a project.
There are many tools and libraries that perform some form of code generation.
Dataklasses is a proof-of-concept for a different approach to that. If you're
a minimalist like me, you'll find it to be perfectly functional. If you're
looking for a lot of knobs to turn, you should probably move along.</p>
<p><strong>Q: Should I give dataklasses a GitHub star?</strong></p>
<p>A: Yes, because it will help me look superior to the other parents with
kids in the middle-school robot club.</p>
<p><strong>Q: Who wrote this?</strong></p>
<p>A: <code>dataklasses</code> is the work of David Beazley. http://www.dabeaz.com.</p>
</article>


<hr>

<footer>
<p>
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="/david/log/" title="Accès au flux RSS"><svg class="icon icon-rss2">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-rss2"></use>
</svg> Suivre</a> •
<a href="http://larlet.com" title="Go to my English profile" data-instant><svg class="icon icon-user-tie">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-user-tie"></use>
</svg> Pro</a> •
<a href="mailto:david%40larlet.fr" title="Envoyer un courriel"><svg class="icon icon-mail">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-mail"></use>
</svg> Email</a> •
<abbr class="nowrap" title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340"><svg class="icon icon-hammer2">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-hammer2"></use>
</svg> Légal</abbr>
</p>
<template id="theme-selector">
<form>
<fieldset>
<legend><svg class="icon icon-brightness-contrast">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-brightness-contrast"></use>
</svg> Thème</legend>
<label>
<input type="radio" value="auto" name="chosen-color-scheme" checked> Auto
</label>
<label>
<input type="radio" value="dark" name="chosen-color-scheme"> Foncé
</label>
<label>
<input type="radio" value="light" name="chosen-color-scheme"> Clair
</label>
</fieldset>
</form>
</template>
</footer>
<script src="/static/david/js/instantpage-5.1.0.min.js" type="module"></script>
<script>
function loadThemeForm(templateName) {
const themeSelectorTemplate = document.querySelector(templateName)
const form = themeSelectorTemplate.content.firstElementChild
themeSelectorTemplate.replaceWith(form)

form.addEventListener('change', (e) => {
const chosenColorScheme = e.target.value
localStorage.setItem('theme', chosenColorScheme)
toggleTheme(chosenColorScheme)
})

const selectedTheme = localStorage.getItem('theme')
if (selectedTheme && selectedTheme !== 'undefined') {
form.querySelector(`[value="${selectedTheme}"]`).checked = true
}
}

const prefersColorSchemeDark = '(prefers-color-scheme: dark)'
window.addEventListener('load', () => {
let hasDarkRules = false
for (const styleSheet of Array.from(document.styleSheets)) {
let mediaRules = []
for (const cssRule of styleSheet.cssRules) {
if (cssRule.type !== CSSRule.MEDIA_RULE) {
continue
}
// WARNING: Safari does not have/supports `conditionText`.
if (cssRule.conditionText) {
if (cssRule.conditionText !== prefersColorSchemeDark) {
continue
}
} else {
if (cssRule.cssText.startsWith(prefersColorSchemeDark)) {
continue
}
}
mediaRules = mediaRules.concat(Array.from(cssRule.cssRules))
}

// WARNING: do not try to insert a Rule to a styleSheet you are
// currently iterating on, otherwise the browser will be stuck
// in a infinite loop…
for (const mediaRule of mediaRules) {
styleSheet.insertRule(mediaRule.cssText)
hasDarkRules = true
}
}
if (hasDarkRules) {
loadThemeForm('#theme-selector')
}
})
</script>
</body>
</html>

+ 141
- 0
cache/2022/891705d1555d09a941fd1f7685de9370/index.md View File

@@ -0,0 +1,141 @@
title: dataklasses: A different spin on dataclasses.
url: https://github.com/dabeaz/dataklasses#questions-and-answers
hash_url: 891705d1555d09a941fd1f7685de9370

Dataklasses is a library that allows you to quickly define data
classes using Python type hints. Here's an example of how you use it:

```python
from dataklasses import dataklass

@dataklass
class Coordinates:
x: int
y: int
```

The resulting class works in a well civilised way, providing the usual
`__init__()`, `__repr__()`, and `__eq__()` methods that you'd normally
have to type out by hand:

```python
>>> a = Coordinates(2, 3)
>>> a
Coordinates(2, 3)
>>> a.x
2
>>> a.y
3
>>> b = Coordinates(2, 3)
>>> a == b
True
>>>
```

It's easy! Almost too easy.

## Wait, doesn't this already exist?

No, it doesn't. Yes, certain naysayers will be quick to point out the
existence of `@dataclass` from the standard library. Ok, sure, THAT
exists. However, it's slow and complicated. Dataklasses are neither
of those things. The entire `dataklasses` module is less than 100
lines. The resulting classes import 15-20 times faster than
dataclasses. See the `perf.py` file for a benchmark.

## Theory of Operation

While out walking with his puppy, Dave had a certain insight about the nature
of Python byte-code. Coming back to the house, he had to try it out:

```python
>>> def __init1__(self, x, y):
... self.x = x
... self.y = y
...
>>> def __init2__(self, foo, bar):
... self.foo = foo
... self.bar = bar
...
>>> __init1__.__code__.co_code == __init2__.__code__.co_code
True
>>>
```

How intriguing! The underlying byte-code is exactly the same even
though the functions are using different argument and attribute names.
Aha! Now, we're onto something interesting.

The `dataclasses` module in the standard library works by collecting
type hints, generating code strings, and executing them using the
`exec()` function. This happens for every single class definition
where it's used. If it sounds slow, that's because it is. In fact, it
defeats any benefit of module caching in Python's import system.

Dataklasses are different. They start out in the same manner--code is
first generated by collecting type hints and using `exec()`. However,
the underlying byte-code is cached and reused in subsequent class
definitions whenever possible. Caching is good.

## A Short Story

Once upon a time, there was this programming language that I'll refer
to as "Lava." Anyways, anytime you started a program written in Lava,
you could just tell by the awkward silence and inactivity of your
machine before the fans kicked in. "Ah shit, this is written in Lava"
you'd exclaim.

## Questions and Answers

**Q: What methods does `dataklass` generate?**

A: By default `__init__()`, `__repr__()`, and `__eq__()` methods are generated.
`__match_args__` is also defined to assist with pattern matching.

**Q: Does `dataklass` enforce the specified types?**

A: No. The types are merely clues about what the value might be and
the Python language does not provide any enforcement on its own.

**Q: Are there any additional features?**

A: No. You can either have features or you can have performance. Pick one.

**Q: Does `dataklass` use any advanced magic such as metaclasses?**

A: No.

**Q: How do I install `dataklasses`?**

A: There is no `setup.py` file, installer, or an official release. You
install it by copying the code into your own project. `dataklasses.py` is
small. You are encouraged to modify it to your own purposes.

**Q: What versions of Python does it work with?**

A: The code will work with versions 3.9 and later.

**Q: But what if new features get added?**

A: What new features? The best new features are no new features.

**Q: Who maintains dataklasses?**

A: If you're using it, you do. You maintain dataklasses.

**Q: Is this actually a serious project?**

A: It's best to think of dataklasses as more of an idea than a project.
There are many tools and libraries that perform some form of code generation.
Dataklasses is a proof-of-concept for a different approach to that. If you're
a minimalist like me, you'll find it to be perfectly functional. If you're
looking for a lot of knobs to turn, you should probably move along.

**Q: Should I give dataklasses a GitHub star?**

A: Yes, because it will help me look superior to the other parents with
kids in the middle-school robot club.

**Q: Who wrote this?**

A: `dataklasses` is the work of David Beazley. http://www.dabeaz.com.

+ 184
- 0
cache/2022/8d9cffcd9bdc116b8934310706def4bc/index.html View File

@@ -0,0 +1,184 @@
<!doctype html><!-- This is a valid HTML5 document. -->
<!-- Screen readers, SEO, extensions and so on. -->
<html lang="fr">
<!-- Has to be within the first 1024 bytes, hence before the `title` element
See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
<meta charset="utf-8">
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
<!-- The viewport meta is quite crowded and we are responsible for that.
See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
<meta name="viewport" content="width=device-width,initial-scale=1">
<!-- Required to make a valid HTML5 document. -->
<title>Le pillage de la communauté des logiciels libres (archive) — David Larlet</title>
<meta name="description" content="Publication mise en cache pour en conserver une trace.">
<!-- That good ol' feed, subscribe :). -->
<link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/">
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png">
<link rel="manifest" href="/static/david/icons2/site.webmanifest">
<link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c">
<link rel="shortcut icon" href="/static/david/icons2/favicon.ico">
<meta name="msapplication-TileColor" content="#f7f7f7">
<meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml">
<meta name="theme-color" content="#f7f7f7" media="(prefers-color-scheme: light)">
<meta name="theme-color" content="#272727" media="(prefers-color-scheme: dark)">
<!-- Documented, feel free to shoot an email. -->
<link rel="stylesheet" href="/static/david/css/style_2021-01-20.css">
<!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. -->
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<script>
function toggleTheme(themeName) {
document.documentElement.classList.toggle(
'forced-dark',
themeName === 'dark'
)
document.documentElement.classList.toggle(
'forced-light',
themeName === 'light'
)
}
const selectedTheme = localStorage.getItem('theme')
if (selectedTheme !== 'undefined') {
toggleTheme(selectedTheme)
}
</script>

<meta name="robots" content="noindex, nofollow">
<meta content="origin-when-cross-origin" name="referrer">
<!-- Canonical URL for SEO purposes -->
<link rel="canonical" href="https://www.monde-diplomatique.fr/2022/01/O_NEIL/64221">

<body class="remarkdown h1-underline h2-underline h3-underline em-underscore hr-center ul-star pre-tick" data-instant-intensity="viewport-all">


<article>
<header>
<h1>Le pillage de la communauté des logiciels libres</h1>
</header>
<nav>
<p class="center">
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="https://www.monde-diplomatique.fr/2022/01/O_NEIL/64221" title="Lien vers le contenu original">Source originale</a>
</p>
</nav>
<hr>
<p><span class="mot-lettrine"><span class="lettrine">E</span>n</span> marge de l’industrie des nouvelles technologies, dans les années 1990, un autre monde numérique émerge. Des développeurs bénévoles distants géographiquement se structurent en communautés pour construire de manière collaborative des logiciels concurrents des offres dites «<small class="fine"> </small>propriétaires<small class="fine"> </small>» : le système d’exploitation Linux, le serveur Web Apache ou le lecteur multimédia VLC en sont des exemples connus. Ils abandonnent les droits exclusifs sur leur production non seulement parce qu’ils perçoivent des bénéfices non financiers (plaisir, apprentissage, réputation, offres d’emploi), mais aussi pour des raisons morales : une licence dite «<small class="fine"> </small>copyleft<small class="fine"> </small>» (comme la licence publique générale, GPL) accorde aux utilisateurs les droits d’exécution, de copie, de modification et de distribution du code informatique. Elle impose aussi le maintien de ces libertés dans toutes les versions dérivées du logiciel<span class="spip_note_ref"> (<a href="https://www.monde-diplomatique.fr/2022/01/O_NEIL/64221#nb1" class="spip_note" rel="appendix" title="Lire Philippe Rivière, « Logiciels libres : et pourtant, ils tournent », (...)" id="nh1">1</a>)</span>. Où en est aujourd’hui le mouvement du logiciel libre<small class="fine"> </small>?</p>
<p>La réponse n’incite guère à l’optimisme : il a été coopté, intégré et récupéré par les colosses de la Silicon Valley, Google, Apple, Facebook, Amazon et Microsoft (Gafam). Au point que les logiciels open source (pour «<small class="fine"> </small>code source ouvert<small class="fine"> </small>», un terme adopté dans le milieu industriel pour parler du logiciel libre sans parler de… libertés<small class="fine"> </small>! <span class="spip_note_ref"> (<a href="https://www.monde-diplomatique.fr/2022/01/O_NEIL/64221#nb2" class="spip_note" rel="appendix" title="Evgeni Morozov, « The meme hustler », The Baffler, n° 22, Cambridge (...)" id="nh2">2</a>)</span>) se trouvent désormais au cœur de l’économie numérique. Selon un sondage réalisé en 2018 auprès de 1 200 professionnels de l’informatique, plus de neuf applications sur dix contiennent des fragments de programmes issus du monde «<small class="fine"> </small>libre<small class="fine"> </small>»<span class="spip_note_ref"> (<a href="https://www.monde-diplomatique.fr/2022/01/O_NEIL/64221#nb3" class="spip_note" rel="appendix" title="Keenan Szulik, « Open source is everywhere », Tidelift, 12 avril  (...)" id="nh3">3</a>)</span>. L’intégration débute au début des années 2000 chez IBM et s’achève en 2018 avec le rachat par Microsoft de la plate-forme de développement collaborative GitHub pour 7,5 milliards de dollars. Les entreprises paient certains développeurs, profitent du travail gratuit des bénévoles, et les intellectuels critiques qui voyaient dans le «<small class="fine"> </small>libre<small class="fine"> </small>» un outil d’émancipation en sont pour leurs frais<span class="spip_note_ref"> (<a href="https://www.monde-diplomatique.fr/2022/01/O_NEIL/64221#nb4" class="spip_note" rel="appendix" title="Lire Sébastien Broca, « L’étrange destin du logiciel libre », Le Monde (...)" id="nh4">4</a>)</span>.</p>
<p>Dans ce processus d’appropriation, deux acteurs ont joué un rôle essentiel de passerelle entre le monde des entreprises et celui des projets<span class="spip_note_ref"> (<a href="https://www.monde-diplomatique.fr/2022/01/O_NEIL/64221#nb5" class="spip_note" rel="appendix" title="Cf. Benjamin Birkinbine, Incorporating the Digital Commons : Corporate (...)" id="nh5">5</a>)</span>. En premier lieu, GitHub, la plate-forme de stockage de lignes de code libre, créée en 2005 et devenue un nœud central fort de quelque 40 millions d’utilisateurs et de 190 millions de dépôts. Cette centralité même a découragé les activistes «<small class="fine"> </small>libristes<small class="fine"> </small>» de la quitter après son rachat par Microsoft. Le succès de GitHub découle de son modèle collaboratif et du fait que les contributions bénévoles, recensées sur les profils individuels des développeurs, constituent de fait leur curriculum vitae.</p>
<p>L’autre acteur-clé est la Fondation Linux. Lancée en 2000 pour garantir un emploi indépendant au créateur américano-finlandais du système d’exploitation libre Linux, M. Linus Torvalds, elle devait prémunir le projet de toute dépendance à une entreprise. Son activité consiste à faciliter l’usage de Linux en produisant des spécifications techniques, du code et des certifications professionnelles. Sur le plan juridique, il s’agit d’un consortium à but non lucratif qui défend les intérêts des entreprises membres, parmi lesquelles on retrouve… la plupart des Gafam. Le développement de son activité donne le vertige : alors qu’elle menait, en 2013, 10 projets, générait 23 millions de dollars de revenus et comptait 39 employés, la Fondation Linux enregistrait cinq ans plus tard 156 projets, 81 millions de dollars de revenus et 178 employés<span class="spip_note_ref"> (<a href="https://www.monde-diplomatique.fr/2022/01/O_NEIL/64221#nb6" class="spip_note" rel="appendix" title="Bradford Biddle, « Linux Foundation is eating the world », Journal of Open Law, (...)" id="nh6">6</a>)</span>.</p>
<p>Dans son abondante communication, la fondation insiste sur l’importance de la documentation et de la sécurité afin de <i>«<small class="fine"> </small>professionnaliser<small class="fine"> </small>»</i> le développement et de rassurer les entreprises non technologiques qui utilisent des logiciels libres. Elle veille à donner une image rassembleuse : lors de ses conférences à gros budget, des intervenants d’Intel ou de GitHub prennent la défense des pauvres «<small class="fine"> </small>devs<small class="fine"> </small>» (développeurs) chinois empêchés de contribuer aux biens communs par les autorités. Surtout, la Fondation Linux martèle l’idée qu’entreprises et projets collaboratifs forment une «<small class="fine"> </small>communauté<small class="fine"> </small>». Ce même terme de <i>community</i> se retrouve systématiquement dans les présentations d’intervenants des sociétés marchandes pour souligner la convergence d’intérêts entre bénévoles et salariés contribuant au même projet<span class="spip_note_ref"> (<a href="https://www.monde-diplomatique.fr/2022/01/O_NEIL/64221#nb7" class="spip_note" rel="appendix" title="Mathieu O’Neil, Xiaolan Cai, Laure Muselli, Fred Pailler et Stefano (...)" id="nh7">7</a>)</span>. Les entreprises qui publient du code sur GitHub insistent également sur la «<small class="fine"> </small>gouvernance communautaire<small class="fine"> </small>» de leurs projets, car n’importe qui peut soumettre une modification à l’approbation de l’auteur originel — ce qui permet à des sociétés commerciales de conserver le dernier mot tout en singeant l’horizontalité… On retrouve enfin la même vision d’une «<small class="fine"> </small>communauté unie<small class="fine"> </small>» dans les articles de médias spécialisés traitant de la coproduction entre sociétés commerciales et projets bénévoles.</p>
<p>Une telle concordance ne doit rien au hasard. Cette inversion orwellienne du sens associé à des termes positifs comme «<small class="fine"> </small>communauté<small class="fine"> </small>», «<small class="fine"> </small>collaboration<small class="fine"> </small>» et «<small class="fine"> </small>ouverture<small class="fine"> </small>» constitue une caractéristique du capitalisme de surveillance<span class="spip_note_ref"> (<a href="https://www.monde-diplomatique.fr/2022/01/O_NEIL/64221#nb8" class="spip_note" rel="appendix" title="Lire Soshana Zuboff, « Un capitalisme de surveillance », Le Monde diplomatique, (...)" id="nh8">8</a>)</span>. En réalité, les intérêts des communautés bénévoles et des entreprises prédatrices ne se rejoignent que dans la mesure où les premières subissent une prédation numérique croissante de la part des secondes. Les Gafam captent, par exemple, les recherches produites avec le monde universitaire : entre 2014 et 2019, 78,3<small class="fine"> </small>% des 17 405 publications d’employés de Microsoft furent coécrites avec des chercheurs<small class="fine"> </small>; au cours de la même période, l’entreprise obtint 76 109 brevets, dont seulement 0,2<small class="fine"> </small>% furent partagés<span class="spip_note_ref"> (<a href="https://www.monde-diplomatique.fr/2022/01/O_NEIL/64221#nb9" class="spip_note" rel="appendix" title="Cf. Cecilia Rikap et Bengt-Ake Lundvall, « Big tech, knowledge predation and (...)" id="nh9">9</a>)</span>. Une autre technique consiste pour les entreprises à multiplier les offres de recherche et développement (R&amp;D) auprès des jeunes développeurs<small class="fine"> </small>; une fois les innovations dévoilées par leurs auteurs, l’entreprise coupe les ponts et crée sa propre version. Les divisions d’Alphabet (maison mère de Google), les laboratoires Google ATAP et Google X, en ont fait leur spécialité, mais Facebook n’est pas en reste<span class="spip_note_ref"> (<a href="https://www.monde-diplomatique.fr/2022/01/O_NEIL/64221#nb10" class="spip_note" rel="appendix" title="The Wall Street Journal, New York, 9 août 2017 ; Fortune, New York, 15 juin  (...)" id="nh10">10</a>)</span>.</p>
<p>Pourquoi les licences copyleft comme la GPL n’ont-elles pas protégé le monde «<small class="fine"> </small>libre<small class="fine"> </small>» des attaques des Gafam<small class="fine"> </small>? D’abord parce que Google les a récupérées — avant de les torpiller. L’entreprise californienne a en effet construit sa domination en faisant de Linux le socle des téléphones Android. Or la licence publique obligeait Google à publier le code source des modifications qu’il apportait à ce logiciel libre. Du moins jusqu’à ce que la société fondée par Larry Page et Sergey Brin développe son propre système d’exploitation, Fuchsia, et lui associe une licence non copyleft.</p>
<p>La GPL a également pâti du développement de l’informatique en nuage <i>(cloud),</i> c’est-à-dire du stockage et du traitement des données sur des serveurs centralisés plutôt que sur les ordinateurs des utilisateurs. En effet, la plupart des licences copyleft, y compris la licence publique générale, ne garantissent l’accès, la modification et la redistribution du code source des logiciels que s’ils sont distribués aux utilisateurs, autrement dit s’ils sont transférés et installés sur leurs ordinateurs. Mais elles n’opèrent pas quand le logiciel tourne sur les serveurs des Gafam : le copyleft ne s’active pas, car le logiciel n’est pas distribué mais utilisé à distance. Le monde «<small class="fine"> </small>libre<small class="fine"> </small>» a bien tenté de créer des licences copyleft efficaces contre la «<small class="fine"> </small>cloudification<small class="fine"> </small>», avec, par exemple, la licence publique générale Affero, mais Google a combattu celle-ci bec et ongles. Si elle avait été adoptée par de nombreux acteurs, cette licence aurait forcé Google et consorts à partager le code source des logiciels qui tournent sur leurs serveurs, même pour les utilisateurs qui interagissent avec ces logiciels à distance. Le mastodonte de la Silicon Valley a donc purement et simplement interdit son utilisation dans ses produits<span class="spip_note_ref"> (<a href="https://www.monde-diplomatique.fr/2022/01/O_NEIL/64221#nb11" class="spip_note" rel="appendix" title="« AGPL policy », Google Open Source." id="nh11">11</a>)</span>.</p>
<p>En matière de logiciel libre, les entreprises technologiques ne présentent pas une attitude monolithique. L’examen des propos tenus par leurs employés lors de trois grandes conférences open source révèle une division claire entre, d’un côté, les grands groupes de type Gafam et, de l’autre, les sociétés de taille plus réduite. Face au modèle économique et aux prétentions communautaires des premières, les secondes affichent une vision critique et plus axée sur la soutenabilité des projets. Leurs représentants insistent sur l’importance des licences et du respect des principes «<small class="fine"> </small>libristes<small class="fine"> </small>», quand les employés des Gafam répètent que la question ne présente aujourd’hui plus guère d’intérêt pour une majorité de contributeurs.</p>
<p>Le partage et la transparence constituent deux valeurs fondatrices du logiciel libre. Si les Gafam consacrent tant de temps et de ressources à nourrir l’illusion de leur appartenance à l’univers collaboratif bénévole, c’est qu’elles savent leur position moralement intenable. Pour les combattre il faut donc répéter cette vérité : les principes fondateurs du logiciel libre sont systématiquement et cyniquement bafoués par ces entreprises. Mais vers quelle cible faut-il diriger cette critique<small class="fine"> </small>? Le grand public<small class="fine"> </small>? Les développeurs<small class="fine"> </small>?</p>
<p>Le grand public se soucie peu des principes du logiciel libre<small class="fine"> </small>; il se montre en revanche sensible aux questions de vie privée et de surveillance. À la faveur des scandales qui entachent la réputation des Gafam, il pourrait graduellement adopter les plates-formes et services décentralisés issus du monde «<small class="fine"> </small>libre<small class="fine"> </small>», à l’instar de l’«<small class="fine"> </small>archipélisation<small class="fine"> </small>» que propose l’association Framasoft pour nouer des partenariats entre structures de natures différentes, du standard ouvert Matrix pour la communication en temps réel sécurisée et décentralisée, ou encore de Nextcloud, solution d’hébergement de fichiers et de collaboration à l’architecture ouverte<span class="spip_note_ref"> (<a href="https://www.monde-diplomatique.fr/2022/01/O_NEIL/64221#nb12" class="spip_note" rel="appendix" title="Cf. https://framasoft.org ; https://matrix.org ; https://nextcloud.com" id="nh12">12</a>)</span>. Le réalisme commande toutefois de reconnaître que ces solutions, malgré leur succès ponctuel, ne peuvent rivaliser avec l’offre de services quasi infinie proposée par les Gafam.</p>
<p>Si le combat n’a jamais été équilibré, le statut d’employé de certains développeurs open source dans les grandes entreprises et le discours dominant qui définit l’innovation uniquement en termes d’investissements privés et de start-up paralysent la résistance. Les communautés des «<small class="fine"> </small>libristes<small class="fine"> </small>» se sont traditionnellement constituées comme des entités collectives pour répondre à des tentatives d’appropriation de programmes. La situation appelle un large débat en leur sein. Quand Oracle acquiert Sun Microsystems en 2010, l’opération menace certains projets open source soutenus par Sun, et des membres de la communauté décident de constituer une version libre alternative du système de gestion de base de données MySQL, qu’ils rebaptisent alors MariaDB. Mais soustraire ainsi à l’appropriation toute l’infrastructure numérique d’Internet bâtie sur des logiciels libres (tels que Linux, Kubernetes, et plus généralement toute la pile logicielle sur laquelle reposent les <i>clouds</i> commerciaux), et par là même les moteurs de recherche, réseaux sociaux et autres plates-formes de service destinés aux entreprises ou au grand public, n’est guère envisageable sans soutien public.</p>
<p>À rebours de la culture des deux acteurs, il s’agit à présent de connecter le libre et l’État. Dans un contexte d’automatisation et de chômage croissants se posent la question de la reconnaissance des contributions volontaires et celle de l’articulation entre les secteurs coopératifs, étatiques et privés. Les Économistes atterrés et Bernard Stiegler ont par exemple proposé des variantes de «<small class="fine"> </small>droits communs du travail<small class="fine"> </small>», qui permettraient à celles et ceux qui contribuent aux communs d’accumuler des droits d’accès à des services sociaux<span class="spip_note_ref"> (<a href="https://www.monde-diplomatique.fr/2022/01/O_NEIL/64221#nb13" class="spip_note" rel="appendix" title="Cf. Calimaq (Lionel Maurel), « Droits communs du travail et droit au travail (...)" id="nh13">13</a>)</span>. La communauté du logiciel libre peut-elle se constituer en entité politique qui réfléchit, au-delà du logiciel, sur la société dans son ensemble<small class="fine"> </small>? Peut-elle se confronter aux orthodoxies productivistes, au développement infini de la puissance de calcul<small class="fine"> </small>? Tout le passé indique le contraire. Son succès, pourtant, en dépend.</p>
</article>


<hr>

<footer>
<p>
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="/david/log/" title="Accès au flux RSS"><svg class="icon icon-rss2">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-rss2"></use>
</svg> Suivre</a> •
<a href="http://larlet.com" title="Go to my English profile" data-instant><svg class="icon icon-user-tie">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-user-tie"></use>
</svg> Pro</a> •
<a href="mailto:david%40larlet.fr" title="Envoyer un courriel"><svg class="icon icon-mail">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-mail"></use>
</svg> Email</a> •
<abbr class="nowrap" title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340"><svg class="icon icon-hammer2">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-hammer2"></use>
</svg> Légal</abbr>
</p>
<template id="theme-selector">
<form>
<fieldset>
<legend><svg class="icon icon-brightness-contrast">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-brightness-contrast"></use>
</svg> Thème</legend>
<label>
<input type="radio" value="auto" name="chosen-color-scheme" checked> Auto
</label>
<label>
<input type="radio" value="dark" name="chosen-color-scheme"> Foncé
</label>
<label>
<input type="radio" value="light" name="chosen-color-scheme"> Clair
</label>
</fieldset>
</form>
</template>
</footer>
<script src="/static/david/js/instantpage-5.1.0.min.js" type="module"></script>
<script>
function loadThemeForm(templateName) {
const themeSelectorTemplate = document.querySelector(templateName)
const form = themeSelectorTemplate.content.firstElementChild
themeSelectorTemplate.replaceWith(form)

form.addEventListener('change', (e) => {
const chosenColorScheme = e.target.value
localStorage.setItem('theme', chosenColorScheme)
toggleTheme(chosenColorScheme)
})

const selectedTheme = localStorage.getItem('theme')
if (selectedTheme && selectedTheme !== 'undefined') {
form.querySelector(`[value="${selectedTheme}"]`).checked = true
}
}

const prefersColorSchemeDark = '(prefers-color-scheme: dark)'
window.addEventListener('load', () => {
let hasDarkRules = false
for (const styleSheet of Array.from(document.styleSheets)) {
let mediaRules = []
for (const cssRule of styleSheet.cssRules) {
if (cssRule.type !== CSSRule.MEDIA_RULE) {
continue
}
// WARNING: Safari does not have/supports `conditionText`.
if (cssRule.conditionText) {
if (cssRule.conditionText !== prefersColorSchemeDark) {
continue
}
} else {
if (cssRule.cssText.startsWith(prefersColorSchemeDark)) {
continue
}
}
mediaRules = mediaRules.concat(Array.from(cssRule.cssRules))
}

// WARNING: do not try to insert a Rule to a styleSheet you are
// currently iterating on, otherwise the browser will be stuck
// in a infinite loop…
for (const mediaRule of mediaRules) {
styleSheet.insertRule(mediaRule.cssText)
hasDarkRules = true
}
}
if (hasDarkRules) {
loadThemeForm('#theme-selector')
}
})
</script>
</body>
</html>

+ 17
- 0
cache/2022/8d9cffcd9bdc116b8934310706def4bc/index.md View File

@@ -0,0 +1,17 @@
title: Le pillage de la communauté des logiciels libres
url: https://www.monde-diplomatique.fr/2022/01/O_NEIL/64221
hash_url: 8d9cffcd9bdc116b8934310706def4bc

<p><span class="mot-lettrine"><span class="lettrine">E</span>n</span> marge de l’industrie des nouvelles technologies, dans les années 1990, un autre monde numérique émerge. Des développeurs bénévoles distants géographiquement se structurent en communautés pour construire de manière collaborative des logiciels concurrents des offres dites «<small class="fine"> </small>propriétaires<small class="fine"> </small>» : le système d’exploitation Linux, le serveur Web Apache ou le lecteur multimédia VLC en sont des exemples connus. Ils abandonnent les droits exclusifs sur leur production non seulement parce qu’ils perçoivent des bénéfices non financiers (plaisir, apprentissage, réputation, offres d’emploi), mais aussi pour des raisons morales : une licence dite «<small class="fine"> </small>copyleft<small class="fine"> </small>» (comme la licence publique générale, GPL) accorde aux utilisateurs les droits d’exécution, de copie, de modification et de distribution du code informatique. Elle impose aussi le maintien de ces libertés dans toutes les versions dérivées du logiciel<span class="spip_note_ref"> (<a href="https://www.monde-diplomatique.fr/2022/01/O_NEIL/64221#nb1" class="spip_note" rel="appendix" title="Lire Philippe Rivière, « Logiciels libres : et pourtant, ils tournent », (...)" id="nh1">1</a>)</span>. Où en est aujourd’hui le mouvement du logiciel libre<small class="fine"> </small>?</p>
<p>La réponse n’incite guère à l’optimisme : il a été coopté, intégré et récupéré par les colosses de la Silicon Valley, Google, Apple, Facebook, Amazon et Microsoft (Gafam). Au point que les logiciels open source (pour «<small class="fine"> </small>code source ouvert<small class="fine"> </small>», un terme adopté dans le milieu industriel pour parler du logiciel libre sans parler de… libertés<small class="fine"> </small>! <span class="spip_note_ref"> (<a href="https://www.monde-diplomatique.fr/2022/01/O_NEIL/64221#nb2" class="spip_note" rel="appendix" title="Evgeni Morozov, « The meme hustler », The Baffler, n° 22, Cambridge (...)" id="nh2">2</a>)</span>) se trouvent désormais au cœur de l’économie numérique. Selon un sondage réalisé en 2018 auprès de 1 200 professionnels de l’informatique, plus de neuf applications sur dix contiennent des fragments de programmes issus du monde «<small class="fine"> </small>libre<small class="fine"> </small>»<span class="spip_note_ref"> (<a href="https://www.monde-diplomatique.fr/2022/01/O_NEIL/64221#nb3" class="spip_note" rel="appendix" title="Keenan Szulik, « Open source is everywhere », Tidelift, 12 avril  (...)" id="nh3">3</a>)</span>. L’intégration débute au début des années 2000 chez IBM et s’achève en 2018 avec le rachat par Microsoft de la plate-forme de développement collaborative GitHub pour 7,5 milliards de dollars. Les entreprises paient certains développeurs, profitent du travail gratuit des bénévoles, et les intellectuels critiques qui voyaient dans le «<small class="fine"> </small>libre<small class="fine"> </small>» un outil d’émancipation en sont pour leurs frais<span class="spip_note_ref"> (<a href="https://www.monde-diplomatique.fr/2022/01/O_NEIL/64221#nb4" class="spip_note" rel="appendix" title="Lire Sébastien Broca, « L’étrange destin du logiciel libre », Le Monde (...)" id="nh4">4</a>)</span>.</p>
<p>Dans ce processus d’appropriation, deux acteurs ont joué un rôle essentiel de passerelle entre le monde des entreprises et celui des projets<span class="spip_note_ref"> (<a href="https://www.monde-diplomatique.fr/2022/01/O_NEIL/64221#nb5" class="spip_note" rel="appendix" title="Cf. Benjamin Birkinbine, Incorporating the Digital Commons : Corporate (...)" id="nh5">5</a>)</span>. En premier lieu, GitHub, la plate-forme de stockage de lignes de code libre, créée en 2005 et devenue un nœud central fort de quelque 40 millions d’utilisateurs et de 190 millions de dépôts. Cette centralité même a découragé les activistes «<small class="fine"> </small>libristes<small class="fine"> </small>» de la quitter après son rachat par Microsoft. Le succès de GitHub découle de son modèle collaboratif et du fait que les contributions bénévoles, recensées sur les profils individuels des développeurs, constituent de fait leur curriculum vitae.</p>
<p>L’autre acteur-clé est la Fondation Linux. Lancée en 2000 pour garantir un emploi indépendant au créateur américano-finlandais du système d’exploitation libre Linux, M. Linus Torvalds, elle devait prémunir le projet de toute dépendance à une entreprise. Son activité consiste à faciliter l’usage de Linux en produisant des spécifications techniques, du code et des certifications professionnelles. Sur le plan juridique, il s’agit d’un consortium à but non lucratif qui défend les intérêts des entreprises membres, parmi lesquelles on retrouve… la plupart des Gafam. Le développement de son activité donne le vertige : alors qu’elle menait, en 2013, 10 projets, générait 23 millions de dollars de revenus et comptait 39 employés, la Fondation Linux enregistrait cinq ans plus tard 156 projets, 81 millions de dollars de revenus et 178 employés<span class="spip_note_ref"> (<a href="https://www.monde-diplomatique.fr/2022/01/O_NEIL/64221#nb6" class="spip_note" rel="appendix" title="Bradford Biddle, « Linux Foundation is eating the world », Journal of Open Law, (...)" id="nh6">6</a>)</span>.</p>
<p>Dans son abondante communication, la fondation insiste sur l’importance de la documentation et de la sécurité afin de <i>«<small class="fine"> </small>professionnaliser<small class="fine"> </small>»</i> le développement et de rassurer les entreprises non technologiques qui utilisent des logiciels libres. Elle veille à donner une image rassembleuse : lors de ses conférences à gros budget, des intervenants d’Intel ou de GitHub prennent la défense des pauvres «<small class="fine"> </small>devs<small class="fine"> </small>» (développeurs) chinois empêchés de contribuer aux biens communs par les autorités. Surtout, la Fondation Linux martèle l’idée qu’entreprises et projets collaboratifs forment une «<small class="fine"> </small>communauté<small class="fine"> </small>». Ce même terme de <i>community</i> se retrouve systématiquement dans les présentations d’intervenants des sociétés marchandes pour souligner la convergence d’intérêts entre bénévoles et salariés contribuant au même projet<span class="spip_note_ref"> (<a href="https://www.monde-diplomatique.fr/2022/01/O_NEIL/64221#nb7" class="spip_note" rel="appendix" title="Mathieu O’Neil, Xiaolan Cai, Laure Muselli, Fred Pailler et Stefano (...)" id="nh7">7</a>)</span>. Les entreprises qui publient du code sur GitHub insistent également sur la «<small class="fine"> </small>gouvernance communautaire<small class="fine"> </small>» de leurs projets, car n’importe qui peut soumettre une modification à l’approbation de l’auteur originel — ce qui permet à des sociétés commerciales de conserver le dernier mot tout en singeant l’horizontalité… On retrouve enfin la même vision d’une «<small class="fine"> </small>communauté unie<small class="fine"> </small>» dans les articles de médias spécialisés traitant de la coproduction entre sociétés commerciales et projets bénévoles.</p>
<p>Une telle concordance ne doit rien au hasard. Cette inversion orwellienne du sens associé à des termes positifs comme «<small class="fine"> </small>communauté<small class="fine"> </small>», «<small class="fine"> </small>collaboration<small class="fine"> </small>» et «<small class="fine"> </small>ouverture<small class="fine"> </small>» constitue une caractéristique du capitalisme de surveillance<span class="spip_note_ref"> (<a href="https://www.monde-diplomatique.fr/2022/01/O_NEIL/64221#nb8" class="spip_note" rel="appendix" title="Lire Soshana Zuboff, « Un capitalisme de surveillance », Le Monde diplomatique, (...)" id="nh8">8</a>)</span>. En réalité, les intérêts des communautés bénévoles et des entreprises prédatrices ne se rejoignent que dans la mesure où les premières subissent une prédation numérique croissante de la part des secondes. Les Gafam captent, par exemple, les recherches produites avec le monde universitaire : entre 2014 et 2019, 78,3<small class="fine"> </small>% des 17 405 publications d’employés de Microsoft furent coécrites avec des chercheurs<small class="fine"> </small>; au cours de la même période, l’entreprise obtint 76 109 brevets, dont seulement 0,2<small class="fine"> </small>% furent partagés<span class="spip_note_ref"> (<a href="https://www.monde-diplomatique.fr/2022/01/O_NEIL/64221#nb9" class="spip_note" rel="appendix" title="Cf. Cecilia Rikap et Bengt-Ake Lundvall, « Big tech, knowledge predation and (...)" id="nh9">9</a>)</span>. Une autre technique consiste pour les entreprises à multiplier les offres de recherche et développement (R&amp;D) auprès des jeunes développeurs<small class="fine"> </small>; une fois les innovations dévoilées par leurs auteurs, l’entreprise coupe les ponts et crée sa propre version. Les divisions d’Alphabet (maison mère de Google), les laboratoires Google ATAP et Google X, en ont fait leur spécialité, mais Facebook n’est pas en reste<span class="spip_note_ref"> (<a href="https://www.monde-diplomatique.fr/2022/01/O_NEIL/64221#nb10" class="spip_note" rel="appendix" title="The Wall Street Journal, New York, 9 août 2017 ; Fortune, New York, 15 juin  (...)" id="nh10">10</a>)</span>.</p>
<p>Pourquoi les licences copyleft comme la GPL n’ont-elles pas protégé le monde «<small class="fine"> </small>libre<small class="fine"> </small>» des attaques des Gafam<small class="fine"> </small>? D’abord parce que Google les a récupérées — avant de les torpiller. L’entreprise californienne a en effet construit sa domination en faisant de Linux le socle des téléphones Android. Or la licence publique obligeait Google à publier le code source des modifications qu’il apportait à ce logiciel libre. Du moins jusqu’à ce que la société fondée par Larry Page et Sergey Brin développe son propre système d’exploitation, Fuchsia, et lui associe une licence non copyleft.</p>
<p>La GPL a également pâti du développement de l’informatique en nuage <i>(cloud),</i> c’est-à-dire du stockage et du traitement des données sur des serveurs centralisés plutôt que sur les ordinateurs des utilisateurs. En effet, la plupart des licences copyleft, y compris la licence publique générale, ne garantissent l’accès, la modification et la redistribution du code source des logiciels que s’ils sont distribués aux utilisateurs, autrement dit s’ils sont transférés et installés sur leurs ordinateurs. Mais elles n’opèrent pas quand le logiciel tourne sur les serveurs des Gafam : le copyleft ne s’active pas, car le logiciel n’est pas distribué mais utilisé à distance. Le monde «<small class="fine"> </small>libre<small class="fine"> </small>» a bien tenté de créer des licences copyleft efficaces contre la «<small class="fine"> </small>cloudification<small class="fine"> </small>», avec, par exemple, la licence publique générale Affero, mais Google a combattu celle-ci bec et ongles. Si elle avait été adoptée par de nombreux acteurs, cette licence aurait forcé Google et consorts à partager le code source des logiciels qui tournent sur leurs serveurs, même pour les utilisateurs qui interagissent avec ces logiciels à distance. Le mastodonte de la Silicon Valley a donc purement et simplement interdit son utilisation dans ses produits<span class="spip_note_ref"> (<a href="https://www.monde-diplomatique.fr/2022/01/O_NEIL/64221#nb11" class="spip_note" rel="appendix" title="« AGPL policy », Google Open Source." id="nh11">11</a>)</span>.</p>
<p>En matière de logiciel libre, les entreprises technologiques ne présentent pas une attitude monolithique. L’examen des propos tenus par leurs employés lors de trois grandes conférences open source révèle une division claire entre, d’un côté, les grands groupes de type Gafam et, de l’autre, les sociétés de taille plus réduite. Face au modèle économique et aux prétentions communautaires des premières, les secondes affichent une vision critique et plus axée sur la soutenabilité des projets. Leurs représentants insistent sur l’importance des licences et du respect des principes «<small class="fine"> </small>libristes<small class="fine"> </small>», quand les employés des Gafam répètent que la question ne présente aujourd’hui plus guère d’intérêt pour une majorité de contributeurs.</p>
<p>Le partage et la transparence constituent deux valeurs fondatrices du logiciel libre. Si les Gafam consacrent tant de temps et de ressources à nourrir l’illusion de leur appartenance à l’univers collaboratif bénévole, c’est qu’elles savent leur position moralement intenable. Pour les combattre il faut donc répéter cette vérité : les principes fondateurs du logiciel libre sont systématiquement et cyniquement bafoués par ces entreprises. Mais vers quelle cible faut-il diriger cette critique<small class="fine"> </small>? Le grand public<small class="fine"> </small>? Les développeurs<small class="fine"> </small>?</p>
<p>Le grand public se soucie peu des principes du logiciel libre<small class="fine"> </small>; il se montre en revanche sensible aux questions de vie privée et de surveillance. À la faveur des scandales qui entachent la réputation des Gafam, il pourrait graduellement adopter les plates-formes et services décentralisés issus du monde «<small class="fine"> </small>libre<small class="fine"> </small>», à l’instar de l’«<small class="fine"> </small>archipélisation<small class="fine"> </small>» que propose l’association Framasoft pour nouer des partenariats entre structures de natures différentes, du standard ouvert Matrix pour la communication en temps réel sécurisée et décentralisée, ou encore de Nextcloud, solution d’hébergement de fichiers et de collaboration à l’architecture ouverte<span class="spip_note_ref"> (<a href="https://www.monde-diplomatique.fr/2022/01/O_NEIL/64221#nb12" class="spip_note" rel="appendix" title="Cf. https://framasoft.org ; https://matrix.org ; https://nextcloud.com" id="nh12">12</a>)</span>. Le réalisme commande toutefois de reconnaître que ces solutions, malgré leur succès ponctuel, ne peuvent rivaliser avec l’offre de services quasi infinie proposée par les Gafam.</p>
<p>Si le combat n’a jamais été équilibré, le statut d’employé de certains développeurs open source dans les grandes entreprises et le discours dominant qui définit l’innovation uniquement en termes d’investissements privés et de start-up paralysent la résistance. Les communautés des «<small class="fine"> </small>libristes<small class="fine"> </small>» se sont traditionnellement constituées comme des entités collectives pour répondre à des tentatives d’appropriation de programmes. La situation appelle un large débat en leur sein. Quand Oracle acquiert Sun Microsystems en 2010, l’opération menace certains projets open source soutenus par Sun, et des membres de la communauté décident de constituer une version libre alternative du système de gestion de base de données MySQL, qu’ils rebaptisent alors MariaDB. Mais soustraire ainsi à l’appropriation toute l’infrastructure numérique d’Internet bâtie sur des logiciels libres (tels que Linux, Kubernetes, et plus généralement toute la pile logicielle sur laquelle reposent les <i>clouds</i> commerciaux), et par là même les moteurs de recherche, réseaux sociaux et autres plates-formes de service destinés aux entreprises ou au grand public, n’est guère envisageable sans soutien public.</p>
<p>À rebours de la culture des deux acteurs, il s’agit à présent de connecter le libre et l’État. Dans un contexte d’automatisation et de chômage croissants se posent la question de la reconnaissance des contributions volontaires et celle de l’articulation entre les secteurs coopératifs, étatiques et privés. Les Économistes atterrés et Bernard Stiegler ont par exemple proposé des variantes de «<small class="fine"> </small>droits communs du travail<small class="fine"> </small>», qui permettraient à celles et ceux qui contribuent aux communs d’accumuler des droits d’accès à des services sociaux<span class="spip_note_ref"> (<a href="https://www.monde-diplomatique.fr/2022/01/O_NEIL/64221#nb13" class="spip_note" rel="appendix" title="Cf. Calimaq (Lionel Maurel), « Droits communs du travail et droit au travail (...)" id="nh13">13</a>)</span>. La communauté du logiciel libre peut-elle se constituer en entité politique qui réfléchit, au-delà du logiciel, sur la société dans son ensemble<small class="fine"> </small>? Peut-elle se confronter aux orthodoxies productivistes, au développement infini de la puissance de calcul<small class="fine"> </small>? Tout le passé indique le contraire. Son succès, pourtant, en dépend.</p>

+ 209
- 0
cache/2022/985e33814839a9c113720a5142caec0e/index.html View File

@@ -0,0 +1,209 @@
<!doctype html><!-- This is a valid HTML5 document. -->
<!-- Screen readers, SEO, extensions and so on. -->
<html lang="fr">
<!-- Has to be within the first 1024 bytes, hence before the `title` element
See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
<meta charset="utf-8">
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
<!-- The viewport meta is quite crowded and we are responsible for that.
See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
<meta name="viewport" content="width=device-width,initial-scale=1">
<!-- Required to make a valid HTML5 document. -->
<title>Long Distance Thinking (archive) — David Larlet</title>
<meta name="description" content="Publication mise en cache pour en conserver une trace.">
<!-- That good ol' feed, subscribe :). -->
<link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/">
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png">
<link rel="manifest" href="/static/david/icons2/site.webmanifest">
<link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c">
<link rel="shortcut icon" href="/static/david/icons2/favicon.ico">
<meta name="msapplication-TileColor" content="#f7f7f7">
<meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml">
<meta name="theme-color" content="#f7f7f7" media="(prefers-color-scheme: light)">
<meta name="theme-color" content="#272727" media="(prefers-color-scheme: dark)">
<!-- Documented, feel free to shoot an email. -->
<link rel="stylesheet" href="/static/david/css/style_2021-01-20.css">
<!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. -->
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<script>
function toggleTheme(themeName) {
document.documentElement.classList.toggle(
'forced-dark',
themeName === 'dark'
)
document.documentElement.classList.toggle(
'forced-light',
themeName === 'light'
)
}
const selectedTheme = localStorage.getItem('theme')
if (selectedTheme !== 'undefined') {
toggleTheme(selectedTheme)
}
</script>

<meta name="robots" content="noindex, nofollow">
<meta content="origin-when-cross-origin" name="referrer">
<!-- Canonical URL for SEO purposes -->
<link rel="canonical" href="https://simonsarris.substack.com/p/long-distance-thinking">

<body class="remarkdown h1-underline h2-underline h3-underline em-underscore hr-center ul-star pre-tick" data-instant-intensity="viewport-all">


<article>
<header>
<h1>Long Distance Thinking</h1>
</header>
<nav>
<p class="center">
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="https://simonsarris.substack.com/p/long-distance-thinking" title="Lien vers le contenu original">Source originale</a>
</p>
</nav>
<hr>
<blockquote><p><em>THE TRUTH MUST DAZZLE GRADUALLY</em></p><p><em>OR EVERY MAN BE BLIND</em></p><p><em>— Emily Dickinson</em></p></blockquote>
<p>The knowledge of a carpenter is in his hands. The apprentice must work with his own to discover it.</p>
<p>Here is some terrible advice: <em>“If you can't explain it to a 6-year-old, you don't understand it yourself.”</em> Typically attributed to Einstein, the phrase only became popular long after his death, around the new millennium. It is somewhat unsurprising that an age of shorter attention spans would give currency to such a quote. Present day we find ourselves at peak <em>explain it to a six year old</em>:</p>
<div class="captioned-image-container"><figure><a class="image-link image2" target="_blank" rel="nofollow" href="https://cdn.substack.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2Ff2218eaa-e9fb-42af-aa69-07593e18d30c_1174x733.png"><img src="https://cdn.substack.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2Ff2218eaa-e9fb-42af-aa69-07593e18d30c_1174x733.png" data-attrs='{"src":"https://bucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com/public/images/f2218eaa-e9fb-42af-aa69-07593e18d30c_1174x733.png","fullscreen":null,"imageSize":null,"height":733,"width":1174,"resizeWidth":null,"bytes":62822,"alt":null,"title":null,"type":"image/png","href":null}' class="sizing-normal" alt=""></a><figcaption class="image-caption">(Google ngrams can only be 5 words long. "explain it to a child" has a richer ngram history, but follows the same ballooning post-2000)</figcaption></figure></div>
<p>Many concepts can be explained concisely, in simple language, and we should all strive for clarity. But the aphorism is a mistake, for a number of thoughts approximate the carpenter’s craft, and to meaningfully reveal them requires time and attention. Sometimes these cannot simply be told to another at all, they must be grown. For a topical example, we know that <em>maturity</em> <em>itself</em> cannot be imparted to a six year old, no matter how good a summary we might give. Despite our understanding, we know it is something that can only come to each of us in time. This pattern is more common than we think. True things are disclosed slowly.</p>
<p>Articulating ideas as simply as possible is attractive, not least because getting people to agree with us is attractive. But we have a tendency to overrate ideas that can be shared easily, with the most apparent advantages. By constant simplifying, we may be lulled into abridging our own ideas a little too much, and sooner or later our audience—or ourselves—might come to expect only these truncated thoughts. What is easy to explain is not necessarily what is best. What is easy to understand is not necessarily what is true.</p>
<p>A practical example:</p>
<div class="captioned-image-container"><figure><a class="image-link image2" target="_blank" rel="nofollow" href="https://cdn.substack.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F10ed4fee-5592-4059-83bd-0b92f24e40b6_2643x1444.jpeg"><img src="https://cdn.substack.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F10ed4fee-5592-4059-83bd-0b92f24e40b6_2643x1444.jpeg" data-attrs='{"src":"https://bucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com/public/images/10ed4fee-5592-4059-83bd-0b92f24e40b6_2643x1444.jpeg","fullscreen":null,"imageSize":null,"height":601,"width":1100,"resizeWidth":null,"bytes":728430,"alt":null,"title":null,"type":"image/jpeg","href":null}' class="sizing-normal" alt=""></a><figcaption class="image-caption">Aerial fire detection</figcaption></figure></div>
<p>In the 1930’s, the US government saw an enormous opportunity. By leveraging the latest technologies, for the first time it seemed possible to extinguish even the smallest and remotest fires. The reasoning is easy to explain: Though it may take considerable resources, successfully locating and suppressing <em>all</em> fires early, even possibly harmless ones, will prevent large fires from ever forming, saving net resources. (Note that most of the concern at the time was centered around loss of timber stock for industry and national defense, and not about settlements burning down.)</p>
<p>Technologically armed to the teeth, aggressive firefighting policies quickly became the rule.</p>
<div class="captioned-image-container"><figure><a class="image-link image2" target="_blank" rel="nofollow" href="https://cdn.substack.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2Feef6d222-043b-47ed-a92c-e55eda06d436_2552x2052.jpeg"><img src="https://cdn.substack.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2Feef6d222-043b-47ed-a92c-e55eda06d436_2552x2052.jpeg" data-attrs='{"src":"https://bucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com/public/images/eef6d222-043b-47ed-a92c-e55eda06d436_2552x2052.jpeg","fullscreen":null,"imageSize":null,"height":884,"width":1100,"resizeWidth":null,"bytes":937178,"alt":null,"title":null,"type":"image/jpeg","href":null}' class="sizing-normal" alt=""></a><figcaption class="image-caption">High tech communications, chemicals, and transportation of the early 1900’s</figcaption></figure></div>
<div class="captioned-image-container"><figure><a class="image-link image2" target="_blank" rel="nofollow" href="https://cdn.substack.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F0dcb48e6-78f6-46d2-b276-7754329ecf99_2048x1594.jpeg"><img src="https://cdn.substack.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F0dcb48e6-78f6-46d2-b276-7754329ecf99_2048x1594.jpeg" data-attrs='{"src":"https://bucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com/public/images/0dcb48e6-78f6-46d2-b276-7754329ecf99_2048x1594.jpeg","fullscreen":null,"imageSize":null,"height":856,"width":1100,"resizeWidth":null,"bytes":553589,"alt":null,"title":null,"type":"image/jpeg","href":null}' class="sizing-normal" alt=""></a><figcaption class="image-caption">A smokejumper, ready to parachute on a remote fire, and his spotter</figcaption></figure></div>
<p>This firefighting policy came into serious question decades later. By the 1960s, it was apparent that no new giant sequoia had grown in California forests, because fire is an essential part of their lifecycle. Fires also had utility in timber production—they clear understory, allowing more valuable timber stock to grow. And in dry climates like the western United States, with an absence of fire, flammable material simply accumulates, creating more dangerous situations years later. As problems surfaced and compounded, in response, there has been a slow and experimental shift from <em>fire fighting</em> to <em>fire management</em>.</p>
<p>New technology enables new solutions. A quick thought becomes policy, which becomes a long disaster, which teaches us, at last, to think a little longer. It is right of us to call fire management an “experimental” policy, for we cannot make policy about the natural world as if it is a board game of rules and resources. We simply do not know all the rules. We can only intervene and wait for the surprising consequences we never predicted. Fire policy was an experiment all along, it was only ever a question of how much we were willing to assume at one time.</p>
<p>The archives of human cleverness are filled with blunders. When read in a good mood, history is a blooper reel. But it should not be lost on us that history never repeats, and modern technology enables ever more leverage. The more technology you can harness to commit an idea, and the faster your idea can spread, the greater the magnitude of something going wrong with a single decision. Scale is a capricious beast, one that becomes easier to summon and harder to predict. Be very careful when you let it in the house.</p>
<p>~ ~ ~</p>
<blockquote><p><em>Now, there is a law written in the darkest of the Books of Life, and it is this: If you look at a thing nine hundred and ninety-nine times, you are perfectly safe; if you look at it the thousandth time, you are in frightful danger of seeing it for the first time.<br>— G.K. Chesterton</em></p></blockquote>
<p>Philosophy begins in wonder, and the art of it is to keep this wonder with you. Many questions are worth asking, re-asking, revisiting, rethinking. One must seek Knowledge, but be a little wary of finding it. Perhaps excessive, but one could say the idea of possessing knowledge represents a kind of complacency. This is what Socrates meant: <em>Once you think you know, you stop looking.</em> You cease your wonder.</p>
<p>These letters are intended partly as a catalog of long distance thoughts. They are commentary on topics that cannot be conveyed compactly, that I ask aloud and re-ask in a number of ways. Some topics, I think, can <em>only</em> be approached this way. Scale is one of them, it is simply a topic too large, with too many sides, to see at once. You must come back to it often and continue to grasp at it. It will rear its head again.</p>
<p>More faint: If you read <strong><a href="https://simonsarris.substack.com/p/that-which-is-unique-breaks" rel="">that which is unique breaks</a></strong> and about <strong><a href="https://simonsarris.substack.com/p/the-most-precious-resource-is-agency" rel="">agency</a></strong> and my <strong><a href="https://simonsarris.substack.com/p/in-praise-of-the-gods" rel="">praise of the gods</a></strong>, and perhaps others, and read between the lines, you will find a thin thread that binds them. The thread vexes people, it manifests in different ways, and it doesn’t quite have a name. People grope at the topic, try to name, summarize, rationalize, even begin advocating ideologies and assigning blame. There is an intense desire to make it digestible. This PowerPoint-ification leads to all kinds of silly outcomes. Not all sources of light are worth staring at: Some summaries illuminate. Most obscure. Better to think a little longer, if you want to take the thread seriously.</p>
<p>There is a somewhat obvious term for long distance thinking: Contemplation. We pass over this word too quickly to really consider what it means. It has fallen out of favor, outside of the occasional raiding of a thesaurus. I find it interesting that even the definition of <em>contemplate</em> has suffered from over-summarizing. The first dictionary definition, in today’s Merriam-Webster:</p>
<blockquote><p><strong>To think deeply or carefully about (something)</strong></p><p><em>I stopped to contemplate [=ponder] what might have happened.<br>He contemplated the meaning of the poem for a long time.<br>Life without them is too awful to contemplate. [=too awful to even think about]</em></p></blockquote>
<p>Compare the brevity, and examples, to its first definition in Webster’s 1913 edition:</p>
<blockquote><p><strong>To look at on all sides or in all its bearings; to view or consider with continued attention; to regard with deliberate care; to meditate on; to study.</strong></p><p><em>To love, at least contemplate and admire,<br>What I see excellent.<br>—Milton</em></p><p><em>We thus dilate<br>Our spirits to the size of that they contemplate.<br>—Byron</em></p></blockquote>
<p>And that same definition in Webster’s 1828 dictionary, his first edition:</p>
<blockquote><p><strong>To view or consider with continued attention; to study; to meditate on. This word expresses the attention of the mind, but sometimes in connection with that of the eyes; as, to </strong><em><strong>contemplate</strong></em><strong> the heavens. More generally, the act of the mind only is intended; as, to </strong><em><strong>contemplate</strong></em><strong> the wonders of redemption; to </strong><em><strong>contemplate</strong></em><strong> the state of the nation and its future prospects.</strong></p></blockquote>
<p>Language is a growing medium for thought, and here we witness something like soil compaction. Why? That nameless thread, it’s at work here, too.</p>
<p>(Aside: It is not only interesting how compacted the thinking has become, but how much of the spirit of an age is present in each work. Webster was deeply religious and nationalist, and considered his dictionary a project of “federal language”, a way to distinguish American language and thought from British. These shine through in his very personal 1828 definitions. The 1912 edition is interesting for using quotes from literature, with only last names, simply assuming the reader is familiar with them, or will know how to find them otherwise. The modern dictionary lacks confidence that the reader can fully parse the example sentences without some parentheticals.)</p>
<p>One way to tease out thinking is to create new language, so if I cannot say “contemplation” and be understood, I will say something else, and hope you consider it as I do.</p>
<p>There’s something closer to the carpenter’s craft that is required of long thoughts. Napoleon, who set up so many republics, kingdoms, and confederations, gave this mention (warning, lament), <em>“A form of government that is not the result of a long sequence of shared experiences, efforts, and endeavors can never take root.”</em> Civilization only exists at long distances, too.</p>
<p>The cure for over-summary, I think, is something akin to cultivation. States and maturity need good growing conditions and time. The wonder we should concern ourselves with: What else has been hidden by summary? What thoughts must we resist abridging? Those giant sequoias echo a reminder to ask ourselves, what are the unseen things today that could be growing?</p>
<p>Another time,</p>
<p>s s</p>
<p>~~~</p>
<p><em>p.s. “If you can't explain it to a 6-year-old, you don't understand it yourself.” — Another small disagreement, more implicit. You shouldn’t be so concerned about whether or not you understand something before you try to explain and share. Some things can only grow in the light of others.</em></p>
<p>~~~</p>
<p><em>The top image is Saint Jermone in his Study, Albrecht Dürer, 1511</em></p>
<p><em>The black and white photographs are from the U.S. Forest Service- Pacific Northwest Region, circle 1920-1950</em></p>
</article>


<hr>

<footer>
<p>
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="/david/log/" title="Accès au flux RSS"><svg class="icon icon-rss2">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-rss2"></use>
</svg> Suivre</a> •
<a href="http://larlet.com" title="Go to my English profile" data-instant><svg class="icon icon-user-tie">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-user-tie"></use>
</svg> Pro</a> •
<a href="mailto:david%40larlet.fr" title="Envoyer un courriel"><svg class="icon icon-mail">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-mail"></use>
</svg> Email</a> •
<abbr class="nowrap" title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340"><svg class="icon icon-hammer2">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-hammer2"></use>
</svg> Légal</abbr>
</p>
<template id="theme-selector">
<form>
<fieldset>
<legend><svg class="icon icon-brightness-contrast">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-brightness-contrast"></use>
</svg> Thème</legend>
<label>
<input type="radio" value="auto" name="chosen-color-scheme" checked> Auto
</label>
<label>
<input type="radio" value="dark" name="chosen-color-scheme"> Foncé
</label>
<label>
<input type="radio" value="light" name="chosen-color-scheme"> Clair
</label>
</fieldset>
</form>
</template>
</footer>
<script src="/static/david/js/instantpage-5.1.0.min.js" type="module"></script>
<script>
function loadThemeForm(templateName) {
const themeSelectorTemplate = document.querySelector(templateName)
const form = themeSelectorTemplate.content.firstElementChild
themeSelectorTemplate.replaceWith(form)

form.addEventListener('change', (e) => {
const chosenColorScheme = e.target.value
localStorage.setItem('theme', chosenColorScheme)
toggleTheme(chosenColorScheme)
})

const selectedTheme = localStorage.getItem('theme')
if (selectedTheme && selectedTheme !== 'undefined') {
form.querySelector(`[value="${selectedTheme}"]`).checked = true
}
}

const prefersColorSchemeDark = '(prefers-color-scheme: dark)'
window.addEventListener('load', () => {
let hasDarkRules = false
for (const styleSheet of Array.from(document.styleSheets)) {
let mediaRules = []
for (const cssRule of styleSheet.cssRules) {
if (cssRule.type !== CSSRule.MEDIA_RULE) {
continue
}
// WARNING: Safari does not have/supports `conditionText`.
if (cssRule.conditionText) {
if (cssRule.conditionText !== prefersColorSchemeDark) {
continue
}
} else {
if (cssRule.cssText.startsWith(prefersColorSchemeDark)) {
continue
}
}
mediaRules = mediaRules.concat(Array.from(cssRule.cssRules))
}

// WARNING: do not try to insert a Rule to a styleSheet you are
// currently iterating on, otherwise the browser will be stuck
// in a infinite loop…
for (const mediaRule of mediaRules) {
styleSheet.insertRule(mediaRule.cssText)
hasDarkRules = true
}
}
if (hasDarkRules) {
loadThemeForm('#theme-selector')
}
})
</script>
</body>
</html>

+ 8
- 0
cache/2022/985e33814839a9c113720a5142caec0e/index.md
File diff suppressed because it is too large
View File


+ 262
- 0
cache/2022/9ad9f5ea367dbd74e4aeeb8471747247/index.html View File

@@ -0,0 +1,262 @@
<!doctype html><!-- This is a valid HTML5 document. -->
<!-- Screen readers, SEO, extensions and so on. -->
<html lang="fr">
<!-- Has to be within the first 1024 bytes, hence before the `title` element
See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
<meta charset="utf-8">
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
<!-- The viewport meta is quite crowded and we are responsible for that.
See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
<meta name="viewport" content="width=device-width,initial-scale=1">
<!-- Required to make a valid HTML5 document. -->
<title>Make it boring - jlwagner.net (archive) — David Larlet</title>
<meta name="description" content="Publication mise en cache pour en conserver une trace.">
<!-- That good ol' feed, subscribe :). -->
<link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/">
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png">
<link rel="manifest" href="/static/david/icons2/site.webmanifest">
<link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c">
<link rel="shortcut icon" href="/static/david/icons2/favicon.ico">
<meta name="msapplication-TileColor" content="#f7f7f7">
<meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml">
<meta name="theme-color" content="#f7f7f7" media="(prefers-color-scheme: light)">
<meta name="theme-color" content="#272727" media="(prefers-color-scheme: dark)">
<!-- Documented, feel free to shoot an email. -->
<link rel="stylesheet" href="/static/david/css/style_2021-01-20.css">
<!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. -->
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<script>
function toggleTheme(themeName) {
document.documentElement.classList.toggle(
'forced-dark',
themeName === 'dark'
)
document.documentElement.classList.toggle(
'forced-light',
themeName === 'light'
)
}
const selectedTheme = localStorage.getItem('theme')
if (selectedTheme !== 'undefined') {
toggleTheme(selectedTheme)
}
</script>

<meta name="robots" content="noindex, nofollow">
<meta content="origin-when-cross-origin" name="referrer">
<!-- Canonical URL for SEO purposes -->
<link rel="canonical" href="https://jlwagner.net/blog/make-it-boring/">

<body class="remarkdown h1-underline h2-underline h3-underline em-underscore hr-center ul-star pre-tick" data-instant-intensity="viewport-all">


<article>
<header>
<h1>Make it boring - jlwagner.net</h1>
</header>
<nav>
<p class="center">
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="https://jlwagner.net/blog/make-it-boring/" title="Lien vers le contenu original">Source originale</a>
</p>
</nav>
<hr>
<p>
A good case can be made for why <em>boring</em> can be preferable to <em>exciting</em>. Read about <a href="https://en.wikipedia.org/wiki/Subprime_mortgage_crisis" rel="noopener">the subprime mortgage</a> crisis sometime, and you'll see that things got hairy because someone, somewhere, thought that investing in mortgage-backed securities should be less boring and more <em>exciting</em>. If those financial instruments as well as the subprime lending market that exploded beneath them had been reasonably regulated and yielded boringly predictable returns, the world might be a better place today.
</p>
<p>
I feel similarly about the state of web development, and I worry when I think about where it's all headed. We're hurtling toward <a href="https://httparchive.org/reports/state-of-javascript#bytesJs" rel="noopener">a bubble of our own</a>. A bubble which exists partly because we're not operating with sensible defaults. Web developers are accustomed to starting projects with the massive overhead of JavaScript frameworks like React — not to mention all that gets installed with it — as well as ancillary packages, module bundlers, and all this... <em>stuff</em>. Stuff that clutters the already densely occupied space of our minds, which inevitably seems to burden the people who use what we make.
</p>
<h3 id="i-was-young-and-wanted-to-do-it-all">I was young and wanted to do it all</h3>
<p>
Remember the first time you made a web page? I do. From the instant I opened a WYSIWYG editor-generated HTML file with notepad.exe in 1995 and saw how much was possible with so little, I was all in on the web. I made websites so frivolously excessive by shoehorning in every new little thing I learned. Garish color schemes, <code>&lt;font&gt;</code> tags, animated GIF backgrounds, guestbooks, oh and who could forget Flash? Three of my personal websites were crappy 2Advanced knockoff Flash sites. I was eager to show off everything I knew, so I churned out Frankenstein monsters that stitched together every new thing I learned.
</p>
<p>
It was only by the time I started my professional career in 2005 that I started to rein in my excesses. I have to remember that it took me <em>ten years</em> of undisciplined experimentation before I began to consider what it meant to build things people would <em>want</em> to use. I need to continually remind myself of this as I consider the new devs out there joining the ranks of the employed.
</p>
<h3 id="the-web-your-exciting-new-job">The web: your exciting new job</h3>
<p>
Most new developers aren't entering the workforce today with a decade of learning and experimentation already under their belts. They're people who are simultaneously new to — and really excited about — building for the web <em>and</em> making a living from it.
</p>
<p>
This isn't a perspective I can speak to. My path was radically different. I didn't join a web developer bootcamp and start making a living off of those skills within a year. I had the benefit of time from middle school to the end of college to experiment and do all the wrong things. I made slow, unusable, inaccessible websites. As my knowledge and skills increased, I made slightly faster, more usable, and more accessible websites.
</p>
<p>
Most new developers haven't had this luxury. Particularly in the U.S., where their flaming baptism into the industry occurs in an increasingly hostile economic environment. New developers will learn the skills that are deemed the most valuable. When you're fresh off an expensive training program and you need to make money <em>now</em>, you're going to chase what makes that money — and a tech company will only pick you up if their HR department can check the boxes. That means you're going to be learning the framework du jour, and for a time, probably little else as you inevitably take time to get up to speed.
</p>
<p>
Front-end development has been this way to an extent for at least the past decade. Read the resume of any veteran front-end web developer, and you'll find it resembles a geological column of skills. It might start with MooTools, YUI, and Dojo underneath jQuery, which itself is underneath Backbone and Knockout, which brings us roughly to where we are today with React and friends. The industry has always chased what's <em>so hot right now</em>. The industry has set us up from day one to chase the new and shiny to pay the bills, while our duty to educate ourselves on core web technologies has been relegated to "some day".
</p>
<p>
We do all of this in the name of productivity — <a href="https://rachelandrew.co.uk/archives/2019/01/30/html-css-and-our-vanishing-industry-entry-points/" rel="noopener">even at our own peril</a>. Whether it was jQuery in the late aughts or React now, these tools were designed to make us more productive — and they do! But, if developers were pressed to admit it, they're also a product of our desire to make our work less <em>boring</em> and more <em>exciting</em>. It fuels what I like to call <em>laptop sticker culture</em> — something I'm certainly guilty of — where everything we do feels badass and glamorous. Shouldn't our work be more fun and <em>exciting?</em>
</p>
<h3 id="the-jaw-achingly-boring-essence-of-things">The jaw-achingly boring essence of things</h3>
<p>
People are propelled by their interests, and web developers have a lot of space to be interested in all sorts of stuff. For you, it may be <em>JavaScript 'n Friends</em>, or HTML and CSS. Maybe it's all that stuff, but put aside your preferences for a moment and answer me this: what are you helping people to <em>do?</em> If the answer involves any remotely routine or crucial purpose, consider putting aside your personal desire for excitement. Instead, make boring things that are usable, accessible, and <em>fast</em>. Ours is a job done by people for people, not a glamorous rockstar gig. Plumbers might get excited about <a href="https://en.wikipedia.org/wiki/Cross-linked_polyethylene" rel="noopener">PEX piping</a>, but they also understand that their job is to ensure the water gets from the main to the faucet as expeditiously as before.
</p>
<p>
Water and data flow through pipes of their own, but whether data flows easily from server to client depends. The environmental constraints imposed on developers by the network, devices, and the browsers people use are legion. Factors such as network bandwidth and latency are obvious, whereas others such as server protocol, device capabilities, and a multitude of others are subtle. Then there is your biggest factor: the people using the thing you make, each one of them a unique case study of capabilities and limitations that we must account for as best we can.
</p>
<p>
If you use a JavaScript framework and a toolchain to manage your code and its output — and my intent isn't to shame you if you do — simply <em>using</em> those tools won't do the difficult work of design for you. Even as developers, our job is not solely to identify and remove excesses in code. We also need to question and seek to trim excesses in design which may look good in a design comp, but only serve to frustrate and impede people in practice. These excesses in development and design aren't simply related, they <em>depend</em> on one another to exist. The more complex a design is, the more it will cost to develop it.
<em>
Every interaction you simplify, every boondoggle you can remove,
represents a benefit to the person who uses what you make.
</em>
</p>
<p>
So make it <em>boring.</em>
</p>
<h3 id="boring-is-unobtrusive">Boring is unobtrusive</h3>
<p>
A website is at its worst when it creates obstacles for people. Obtrusive design is the result of every project manager, business analyst, designer, and developer unwilling or unable to question ill-considered business requirements or design decisions. <a href="https://bigmedium.com/ideas/boring-design-systems.html" rel="noopener">In a piece striking a similar tone</a> on making design systems boring, Josh Clark had the following to say:
</p>
<blockquote cite="https://bigmedium.com/ideas/boring-design-systems.html">
"The more common the problem, the better. Design systems should prioritize the mundane."
</blockquote>
<p>
Prioritizing the mundane <em>necessarily involves avoiding obtrusiveness.</em> Without acknowledging that simple truth, we can only create fast, accessible, and usable experiences entirely by accident.
</p>
<p>
To wit: a perfect example of obtrusive design was <a href="https://en.wikipedia.org/wiki/HotSauce" rel="noopener">Apple's HotSauce</a>, which provided a 3D visualization of sitemaps. Instead of aiming for a mundane, utilitarian way to present this information, the visualization chosen instead was seen as cumbersome and pointless. When folks browse a list of URLs from a website, they don't care what that experience would be like if they were on the deck of the <em>Enterprise</em>. They crave a <em>boringly predictable</em> way to access that information <em>quickly</em>.
</p>
<p>
Eminently usable designs and architectures result when simplicity is the default. It's why unadorned HTML works. It beautifully solves the problem of presenting documents to the screen that we don't even consider all the careful thought that went into the user agent stylesheets that provide its utterly boring presentation. We can take a lesson from this, especially during a time when more web <em>sites</em> are consumed as web <em>apps</em>, and make them more resilient by adhering to semantics and native web technologies. As it stands, we're serving heaps of <code>&lt;div&gt;</code> burgers on silver platters of JavaScript with a generous helping of layout framework sauce not everyone can choke down.
</p>
<p>
To that end, accessibility advocates aren't yelling at you to use <a href="https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility#HTML" rel="noopener">semantic HTML</a> because it's exciting, but because it's well understood how users benefit from it. This doesn't mean your choice of tools makes building great websites impossible, but it <em>does</em> require you to understand how their overhead is a liability right from the very start. That is, <em>unless</em> you're cognizant of the pitfalls and know how to avoid them. That kind of knowledge takes years of trial, error, and continuing education to get right — knowledge you can't gain by starting your career using JavaScript frameworks and toolchains exclusively while ignoring what HTML and CSS brings to the table.
</p>
<h3 id="boring-is-expected">Boring is expected</h3>
<p>
Boring and predictable are <em>expected qualities of the essential</em>. Traffic lights functioning as expected? Awesome. The plane's landing gear doesn't fall off on approach? Even better. While we as developers and designers aren't in charge of those critically essential things, we <em>are</em> responsible for the services people expect to be available. Some of these services, such as resources for federal aid and assistance, are <em>critical</em> fixtures in an economically hostile landscape. We must go the extra mile to make sure that they're highly available, accessible, and fast.
</p>
<p>
Central to that endeavor is recognizing that the browser gives you a <em>ton</em> of stuff for free. Relying on those freebies requires a willingness to not <code>npm install</code> a solution for every problem — <em>especially</em> those that are best solved with CSS and HTML. Those technologies may seem boring, but boring is fast. Boring is usable. Boring is resilient and fault tolerant. Boring is <em>accessible</em>. When we rely wholesale on JavaScript to build for the web, we're inevitably reinventing things. At worst, our reinventions of rock-solid HTML features — such as <a href="https://developer.mozilla.org/en-US/docs/Learn/HTML/Forms/Form_validation" rel="noopener">client-side form validation</a>  — break in unexpected ways despite our carefully written tests. At best, a flawless reimplementation of those features adds unnecessary code to applications, and depends on a technology less fault-tolerant than CSS and HTML.
</p>
<p>
If your initial reaction to reading this is to assert that people hate boring websites, you must reconcile that assertion with the emergence of " <a href="https://css-tricks.com/reader-mode-the-button-to-beat/" rel="noopener">reader mode</a> " features in most desktop, phone, and tablet browsers. These features are, in essence, "boring mode" toggles that reduce a page's functionality to its core. People are so tired of coping with stuttering, JavaScript-laden pages that they'll gladly strip away everything "interesting" to make those pages <em>usable</em>. Still, reading mode doesn't work on all pages, particularly those dependent on JavaScript for even the base level of functionality. Nor should we expect it to. Reader mode was never designed to address those use cases. Solving human problems requires a human touch, after all.
</p>
<h3 id="the-web-is-in-your-care">The web is in your care</h3>
<p>
No tool or amount or automation is a substitute for expertise built years of experience in solving human problems. It's <em>realizing</em> that while an accessibility inspector can <em>tell</em> you that you should use <code>&lt;label&gt;</code> elements for form fields, you need to know the human reasons for <em>why</em> such a pattern is preferable over meaningless <code>&lt;span&gt;</code>s. It's <em>understanding</em> that while icons might look good in your design comp, relying on language to communicate those actions is more sensible. It's <em>knowing</em> that while a layout problem can be solved by <code>npm install</code>ing a module, such problems are best solved by CSS.
</p>
<p>
For all of my whinging about the evils of JavaScript and the sinful <em>excitement</em> it brings, I still believe it has value. We <em>do</em> need to rebalance our use of it against CSS and HTML, however, because the status quo of how we build for the web can't continue without consequences. JavaScript works best when we use it with progressive enhancement in mind. When we can build a baseline <em>everyone</em> benefits from, and <em>then</em> <a href="https://alistapart.com/article/understandingprogressiveenhancement#section4" rel="noopener">add that candy coating</a> to enhance usability further for that subset of people who can benefit from it, we're not just building better experiences, but more <em>inclusive</em> ones. That's the good work we should all strive to do.
</p>
<p>
If you care about the web — as I <em>know</em> you do — you'll come to find out that this work isn't boring at all, but really rather delightful and rewarding. What’s more, your choice of framework isn’t mutually incompatible with making stuff for the web that people love to use. It <em>does</em> make that goal harder to achieve, but continuing education and forethought will go a long way in helping you to get the balance right.
</p>
<p>
As developers, we have two objectives: Work to make things better this week than they were last week, and continue our education to ensure the success of the first objective. With a stronger embrace of HTML and CSS, I genuinely believe our work can never be boring, so long as it helps us deliver on these objectives in the spirit of making the web better for all people.
</p>
<p>
<em>Special thanks to <a href="https://www.zeldman.com/" rel="noopener">Jeffrey Zeldman</a>, whose industry expertise, advice, and insight helped me to shape these thoughts into a more coherent narrative.</em>
</p>
</article>


<hr>

<footer>
<p>
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="/david/log/" title="Accès au flux RSS"><svg class="icon icon-rss2">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-rss2"></use>
</svg> Suivre</a> •
<a href="http://larlet.com" title="Go to my English profile" data-instant><svg class="icon icon-user-tie">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-user-tie"></use>
</svg> Pro</a> •
<a href="mailto:david%40larlet.fr" title="Envoyer un courriel"><svg class="icon icon-mail">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-mail"></use>
</svg> Email</a> •
<abbr class="nowrap" title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340"><svg class="icon icon-hammer2">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-hammer2"></use>
</svg> Légal</abbr>
</p>
<template id="theme-selector">
<form>
<fieldset>
<legend><svg class="icon icon-brightness-contrast">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-brightness-contrast"></use>
</svg> Thème</legend>
<label>
<input type="radio" value="auto" name="chosen-color-scheme" checked> Auto
</label>
<label>
<input type="radio" value="dark" name="chosen-color-scheme"> Foncé
</label>
<label>
<input type="radio" value="light" name="chosen-color-scheme"> Clair
</label>
</fieldset>
</form>
</template>
</footer>
<script src="/static/david/js/instantpage-5.1.0.min.js" type="module"></script>
<script>
function loadThemeForm(templateName) {
const themeSelectorTemplate = document.querySelector(templateName)
const form = themeSelectorTemplate.content.firstElementChild
themeSelectorTemplate.replaceWith(form)

form.addEventListener('change', (e) => {
const chosenColorScheme = e.target.value
localStorage.setItem('theme', chosenColorScheme)
toggleTheme(chosenColorScheme)
})

const selectedTheme = localStorage.getItem('theme')
if (selectedTheme && selectedTheme !== 'undefined') {
form.querySelector(`[value="${selectedTheme}"]`).checked = true
}
}

const prefersColorSchemeDark = '(prefers-color-scheme: dark)'
window.addEventListener('load', () => {
let hasDarkRules = false
for (const styleSheet of Array.from(document.styleSheets)) {
let mediaRules = []
for (const cssRule of styleSheet.cssRules) {
if (cssRule.type !== CSSRule.MEDIA_RULE) {
continue
}
// WARNING: Safari does not have/supports `conditionText`.
if (cssRule.conditionText) {
if (cssRule.conditionText !== prefersColorSchemeDark) {
continue
}
} else {
if (cssRule.cssText.startsWith(prefersColorSchemeDark)) {
continue
}
}
mediaRules = mediaRules.concat(Array.from(cssRule.cssRules))
}

// WARNING: do not try to insert a Rule to a styleSheet you are
// currently iterating on, otherwise the browser will be stuck
// in a infinite loop…
for (const mediaRule of mediaRules) {
styleSheet.insertRule(mediaRule.cssText)
hasDarkRules = true
}
}
if (hasDarkRules) {
loadThemeForm('#theme-selector')
}
})
</script>
</body>
</html>

+ 95
- 0
cache/2022/9ad9f5ea367dbd74e4aeeb8471747247/index.md View File

@@ -0,0 +1,95 @@
title: Make it boring - jlwagner.net
url: https://jlwagner.net/blog/make-it-boring/
hash_url: 9ad9f5ea367dbd74e4aeeb8471747247

<p>
A good case can be made for why <em>boring</em> can be preferable to <em>exciting</em>. Read about <a href="https://en.wikipedia.org/wiki/Subprime_mortgage_crisis" rel="noopener">the subprime mortgage</a> crisis sometime, and you'll see that things got hairy because someone, somewhere, thought that investing in mortgage-backed securities should be less boring and more <em>exciting</em>. If those financial instruments as well as the subprime lending market that exploded beneath them had been reasonably regulated and yielded boringly predictable returns, the world might be a better place today.
</p>
<p>
I feel similarly about the state of web development, and I worry when I think about where it's all headed. We're hurtling toward <a href="https://httparchive.org/reports/state-of-javascript#bytesJs" rel="noopener">a bubble of our own</a>. A bubble which exists partly because we're not operating with sensible defaults. Web developers are accustomed to starting projects with the massive overhead of JavaScript frameworks like React — not to mention all that gets installed with it — as well as ancillary packages, module bundlers, and all this... <em>stuff</em>. Stuff that clutters the already densely occupied space of our minds, which inevitably seems to burden the people who use what we make.
</p>
<h3 id="i-was-young-and-wanted-to-do-it-all">I was young and wanted to do it all</h3>
<p>
Remember the first time you made a web page? I do. From the instant I opened a WYSIWYG editor-generated HTML file with notepad.exe in 1995 and saw how much was possible with so little, I was all in on the web. I made websites so frivolously excessive by shoehorning in every new little thing I learned. Garish color schemes, <code>&lt;font&gt;</code> tags, animated GIF backgrounds, guestbooks, oh and who could forget Flash? Three of my personal websites were crappy 2Advanced knockoff Flash sites. I was eager to show off everything I knew, so I churned out Frankenstein monsters that stitched together every new thing I learned.
</p>
<p>
It was only by the time I started my professional career in 2005 that I started to rein in my excesses. I have to remember that it took me <em>ten years</em> of undisciplined experimentation before I began to consider what it meant to build things people would <em>want</em> to use. I need to continually remind myself of this as I consider the new devs out there joining the ranks of the employed.
</p>
<h3 id="the-web-your-exciting-new-job">The web: your exciting new job</h3>
<p>
Most new developers aren't entering the workforce today with a decade of learning and experimentation already under their belts. They're people who are simultaneously new to — and really excited about — building for the web <em>and</em> making a living from it.
</p>
<p>
This isn't a perspective I can speak to. My path was radically different. I didn't join a web developer bootcamp and start making a living off of those skills within a year. I had the benefit of time from middle school to the end of college to experiment and do all the wrong things. I made slow, unusable, inaccessible websites. As my knowledge and skills increased, I made slightly faster, more usable, and more accessible websites.
</p>
<p>
Most new developers haven't had this luxury. Particularly in the U.S., where their flaming baptism into the industry occurs in an increasingly hostile economic environment. New developers will learn the skills that are deemed the most valuable. When you're fresh off an expensive training program and you need to make money <em>now</em>, you're going to chase what makes that money — and a tech company will only pick you up if their HR department can check the boxes. That means you're going to be learning the framework du jour, and for a time, probably little else as you inevitably take time to get up to speed.
</p>
<p>
Front-end development has been this way to an extent for at least the past decade. Read the resume of any veteran front-end web developer, and you'll find it resembles a geological column of skills. It might start with MooTools, YUI, and Dojo underneath jQuery, which itself is underneath Backbone and Knockout, which brings us roughly to where we are today with React and friends. The industry has always chased what's <em>so hot right now</em>. The industry has set us up from day one to chase the new and shiny to pay the bills, while our duty to educate ourselves on core web technologies has been relegated to "some day".
</p>
<p>
We do all of this in the name of productivity — <a href="https://rachelandrew.co.uk/archives/2019/01/30/html-css-and-our-vanishing-industry-entry-points/" rel="noopener">even at our own peril</a>. Whether it was jQuery in the late aughts or React now, these tools were designed to make us more productive — and they do! But, if developers were pressed to admit it, they're also a product of our desire to make our work less <em>boring</em> and more <em>exciting</em>. It fuels what I like to call <em>laptop sticker culture</em> — something I'm certainly guilty of — where everything we do feels badass and glamorous. Shouldn't our work be more fun and <em>exciting?</em>
</p>
<h3 id="the-jaw-achingly-boring-essence-of-things">The jaw-achingly boring essence of things</h3>
<p>
People are propelled by their interests, and web developers have a lot of space to be interested in all sorts of stuff. For you, it may be <em>JavaScript 'n Friends</em>, or HTML and CSS. Maybe it's all that stuff, but put aside your preferences for a moment and answer me this: what are you helping people to <em>do?</em> If the answer involves any remotely routine or crucial purpose, consider putting aside your personal desire for excitement. Instead, make boring things that are usable, accessible, and <em>fast</em>. Ours is a job done by people for people, not a glamorous rockstar gig. Plumbers might get excited about <a href="https://en.wikipedia.org/wiki/Cross-linked_polyethylene" rel="noopener">PEX piping</a>, but they also understand that their job is to ensure the water gets from the main to the faucet as expeditiously as before.
</p>
<p>
Water and data flow through pipes of their own, but whether data flows easily from server to client depends. The environmental constraints imposed on developers by the network, devices, and the browsers people use are legion. Factors such as network bandwidth and latency are obvious, whereas others such as server protocol, device capabilities, and a multitude of others are subtle. Then there is your biggest factor: the people using the thing you make, each one of them a unique case study of capabilities and limitations that we must account for as best we can.
</p>
<p>
If you use a JavaScript framework and a toolchain to manage your code and its output — and my intent isn't to shame you if you do — simply <em>using</em> those tools won't do the difficult work of design for you. Even as developers, our job is not solely to identify and remove excesses in code. We also need to question and seek to trim excesses in design which may look good in a design comp, but only serve to frustrate and impede people in practice. These excesses in development and design aren't simply related, they <em>depend</em> on one another to exist. The more complex a design is, the more it will cost to develop it.
<em>
Every interaction you simplify, every boondoggle you can remove,
represents a benefit to the person who uses what you make.
</em>
</p>
<p>
So make it <em>boring.</em>
</p>
<h3 id="boring-is-unobtrusive">Boring is unobtrusive</h3>
<p>
A website is at its worst when it creates obstacles for people. Obtrusive design is the result of every project manager, business analyst, designer, and developer unwilling or unable to question ill-considered business requirements or design decisions. <a href="https://bigmedium.com/ideas/boring-design-systems.html" rel="noopener">In a piece striking a similar tone</a> on making design systems boring, Josh Clark had the following to say:
</p>
<blockquote cite="https://bigmedium.com/ideas/boring-design-systems.html">
"The more common the problem, the better. Design systems should prioritize the mundane."
</blockquote>
<p>
Prioritizing the mundane <em>necessarily involves avoiding obtrusiveness.</em> Without acknowledging that simple truth, we can only create fast, accessible, and usable experiences entirely by accident.
</p>
<p>
To wit: a perfect example of obtrusive design was <a href="https://en.wikipedia.org/wiki/HotSauce" rel="noopener">Apple's HotSauce</a>, which provided a 3D visualization of sitemaps. Instead of aiming for a mundane, utilitarian way to present this information, the visualization chosen instead was seen as cumbersome and pointless. When folks browse a list of URLs from a website, they don't care what that experience would be like if they were on the deck of the <em>Enterprise</em>. They crave a <em>boringly predictable</em> way to access that information <em>quickly</em>.
</p>
<p>
Eminently usable designs and architectures result when simplicity is the default. It's why unadorned HTML works. It beautifully solves the problem of presenting documents to the screen that we don't even consider all the careful thought that went into the user agent stylesheets that provide its utterly boring presentation. We can take a lesson from this, especially during a time when more web <em>sites</em> are consumed as web <em>apps</em>, and make them more resilient by adhering to semantics and native web technologies. As it stands, we're serving heaps of <code>&lt;div&gt;</code> burgers on silver platters of JavaScript with a generous helping of layout framework sauce not everyone can choke down.
</p>
<p>
To that end, accessibility advocates aren't yelling at you to use <a href="https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility#HTML" rel="noopener">semantic HTML</a> because it's exciting, but because it's well understood how users benefit from it. This doesn't mean your choice of tools makes building great websites impossible, but it <em>does</em> require you to understand how their overhead is a liability right from the very start. That is, <em>unless</em> you're cognizant of the pitfalls and know how to avoid them. That kind of knowledge takes years of trial, error, and continuing education to get right — knowledge you can't gain by starting your career using JavaScript frameworks and toolchains exclusively while ignoring what HTML and CSS brings to the table.
</p>
<h3 id="boring-is-expected">Boring is expected</h3>
<p>
Boring and predictable are <em>expected qualities of the essential</em>. Traffic lights functioning as expected? Awesome. The plane's landing gear doesn't fall off on approach? Even better. While we as developers and designers aren't in charge of those critically essential things, we <em>are</em> responsible for the services people expect to be available. Some of these services, such as resources for federal aid and assistance, are <em>critical</em> fixtures in an economically hostile landscape. We must go the extra mile to make sure that they're highly available, accessible, and fast.
</p>
<p>
Central to that endeavor is recognizing that the browser gives you a <em>ton</em> of stuff for free. Relying on those freebies requires a willingness to not <code>npm install</code> a solution for every problem — <em>especially</em> those that are best solved with CSS and HTML. Those technologies may seem boring, but boring is fast. Boring is usable. Boring is resilient and fault tolerant. Boring is <em>accessible</em>. When we rely wholesale on JavaScript to build for the web, we're inevitably reinventing things. At worst, our reinventions of rock-solid HTML features — such as <a href="https://developer.mozilla.org/en-US/docs/Learn/HTML/Forms/Form_validation" rel="noopener">client-side form validation</a>  — break in unexpected ways despite our carefully written tests. At best, a flawless reimplementation of those features adds unnecessary code to applications, and depends on a technology less fault-tolerant than CSS and HTML.
</p>
<p>
If your initial reaction to reading this is to assert that people hate boring websites, you must reconcile that assertion with the emergence of " <a href="https://css-tricks.com/reader-mode-the-button-to-beat/" rel="noopener">reader mode</a> " features in most desktop, phone, and tablet browsers. These features are, in essence, "boring mode" toggles that reduce a page's functionality to its core. People are so tired of coping with stuttering, JavaScript-laden pages that they'll gladly strip away everything "interesting" to make those pages <em>usable</em>. Still, reading mode doesn't work on all pages, particularly those dependent on JavaScript for even the base level of functionality. Nor should we expect it to. Reader mode was never designed to address those use cases. Solving human problems requires a human touch, after all.
</p>
<h3 id="the-web-is-in-your-care">The web is in your care</h3>
<p>
No tool or amount or automation is a substitute for expertise built years of experience in solving human problems. It's <em>realizing</em> that while an accessibility inspector can <em>tell</em> you that you should use <code>&lt;label&gt;</code> elements for form fields, you need to know the human reasons for <em>why</em> such a pattern is preferable over meaningless <code>&lt;span&gt;</code>s. It's <em>understanding</em> that while icons might look good in your design comp, relying on language to communicate those actions is more sensible. It's <em>knowing</em> that while a layout problem can be solved by <code>npm install</code>ing a module, such problems are best solved by CSS.
</p>
<p>
For all of my whinging about the evils of JavaScript and the sinful <em>excitement</em> it brings, I still believe it has value. We <em>do</em> need to rebalance our use of it against CSS and HTML, however, because the status quo of how we build for the web can't continue without consequences. JavaScript works best when we use it with progressive enhancement in mind. When we can build a baseline <em>everyone</em> benefits from, and <em>then</em> <a href="https://alistapart.com/article/understandingprogressiveenhancement#section4" rel="noopener">add that candy coating</a> to enhance usability further for that subset of people who can benefit from it, we're not just building better experiences, but more <em>inclusive</em> ones. That's the good work we should all strive to do.
</p>
<p>
If you care about the web — as I <em>know</em> you do — you'll come to find out that this work isn't boring at all, but really rather delightful and rewarding. What’s more, your choice of framework isn’t mutually incompatible with making stuff for the web that people love to use. It <em>does</em> make that goal harder to achieve, but continuing education and forethought will go a long way in helping you to get the balance right.
</p>
<p>
As developers, we have two objectives: Work to make things better this week than they were last week, and continue our education to ensure the success of the first objective. With a stronger embrace of HTML and CSS, I genuinely believe our work can never be boring, so long as it helps us deliver on these objectives in the spirit of making the web better for all people.
</p>
<p>
<em>Special thanks to <a href="https://www.zeldman.com/" rel="noopener">Jeffrey Zeldman</a>, whose industry expertise, advice, and insight helped me to shape these thoughts into a more coherent narrative.</em>
</p>

+ 199
- 0
cache/2022/9eac0872e78f3de333ff5df423060de2/index.html View File

@@ -0,0 +1,199 @@
<!doctype html><!-- This is a valid HTML5 document. -->
<!-- Screen readers, SEO, extensions and so on. -->
<html lang="fr">
<!-- Has to be within the first 1024 bytes, hence before the `title` element
See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
<meta charset="utf-8">
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
<!-- The viewport meta is quite crowded and we are responsible for that.
See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
<meta name="viewport" content="width=device-width,initial-scale=1">
<!-- Required to make a valid HTML5 document. -->
<title>Support open source that you use by paying the maintainers to talk to your team (archive) — David Larlet</title>
<meta name="description" content="Publication mise en cache pour en conserver une trace.">
<!-- That good ol' feed, subscribe :). -->
<link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/">
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png">
<link rel="manifest" href="/static/david/icons2/site.webmanifest">
<link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c">
<link rel="shortcut icon" href="/static/david/icons2/favicon.ico">
<meta name="msapplication-TileColor" content="#f7f7f7">
<meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml">
<meta name="theme-color" content="#f7f7f7" media="(prefers-color-scheme: light)">
<meta name="theme-color" content="#272727" media="(prefers-color-scheme: dark)">
<!-- Documented, feel free to shoot an email. -->
<link rel="stylesheet" href="/static/david/css/style_2021-01-20.css">
<!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. -->
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<script>
function toggleTheme(themeName) {
document.documentElement.classList.toggle(
'forced-dark',
themeName === 'dark'
)
document.documentElement.classList.toggle(
'forced-light',
themeName === 'light'
)
}
const selectedTheme = localStorage.getItem('theme')
if (selectedTheme !== 'undefined') {
toggleTheme(selectedTheme)
}
</script>

<meta name="robots" content="noindex, nofollow">
<meta content="origin-when-cross-origin" name="referrer">
<!-- Canonical URL for SEO purposes -->
<link rel="canonical" href="https://simonwillison.net/2022/Feb/23/support-open-source/">

<body class="remarkdown h1-underline h2-underline h3-underline em-underscore hr-center ul-star pre-tick" data-instant-intensity="viewport-all">


<article>
<header>
<h1>Support open source that you use by paying the maintainers to talk to your team</h1>
</header>
<nav>
<p class="center">
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="https://simonwillison.net/2022/Feb/23/support-open-source/" title="Lien vers le contenu original">Source originale</a>
</p>
</nav>
<hr>
<h2>Support open source that you use by paying the maintainers to talk to your team</h2>

<p>I think I’ve come up with a novel hack for the challenge of getting your company to financially support the open source projects that it uses: reach out to the maintainers and <em>offer them generous speaking fees</em> for remote talks to your engineering team.</p>
<h4>The problem</h4>
<p>Everyone agrees that open source projects deserve more financial support. Actually supporting projects can be surprisingly difficult though:</p>
<ul>
<li>Many projects don’t offer any clear mechanism for sponsoring them.</li>
<li>More to the point: open source projects are often really bad at asking for or thinking about money—it’s rarely a core competency!</li>
<li>Projects that do often get the tiers wrong: a $5/month “buy a coffee” GitHub sponsorship isn’t really going to make a meaningful impact on a project.</li>
<li>But… making the case that a for-profit company should hand over money for something they’re getting for free is hard! You need a lot of buy-in from a lot of stakeholders for anything involving spending money—and many of the people who care about this within a company won’t have enough internal clout to get it to happen.</li>
</ul>
<p>If you can make sponsorship happen, great: you should do that. But if not… how about reaching out to the maintainers and offering to hire them for an hour-long “consultancy” speaking engagement instead?</p>
<p>Thanks to the rise of remote working and Zoom, giving a talk no longer requires traveling to a venue—which could easily turn an hour-long opportunity into a full day.</p>
<p>One-off paid speaking opportunities are much more likely to fit into a regular company’s model of how money should spent than monthly donations.</p>
<h4>What if they’re not experienced speakers?</h4>
<p>The obvious flaw in this idea is that being an open source maintainer doesn’t necessarily mean that someone is a great public speaker: speaking is a skill unto itself.</p>
<p>If that’s the case, I propose running the session as a moderated Q&amp;A instead.</p>
<p>Find a member of your team with speaking experience to act as a host. Gather questions from your other engineers in advance, and share them with your guest so that they can prepare. Then run the session as a Q&amp;A.</p>
<p>This takes a huge deal of pressure off the speaker, and means you get a conversation that’s much more targeted to your team’s interests and needs as well.</p>
<h4>So go and do it!</h4>
<p>Remember, the key problem we’re trying to solve here is how to financially support projects and maintainers that may not be very good at asking for the money.</p>
<p>I want to take the pressure off those maintainers to learn how to market and sell their services.</p>
<p>So reach out to some projects you use and ask them if you can pay them to spend an hour of their time talking to your team! I’m excited to see how well this works.</p>
<p><strong>Be generous</strong>: This isn’t about negotiating the best speaking rate from someone who may never have been paid to speak before. This is about compensating them for the enormous value that your company has gained from their work, and using a clever accounting trick to do so. So offer them a generous fee up front! Paying over the odds should be part of your goal here.</p>
<p>For larger companies there’s probably an upper cap on the amount that can be expensed easily. Finding out what that is might be helpful here too.</p>
<p>Your company likely has an existing education budget which might be a good source of funds for this kind of engagement.</p>
<p>(If your team would benefit from a talk from me about <a href="https://datasette.io/">Datasette</a>, <a href="https://sqlite-utils.datasette.io/">sqlite-utils</a>, <a href="https://simonwillison.net/2020/Oct/9/git-scraping/">Git scraping</a> or any of the other projects I have going on, please drop me a line at <code>swillison at gmail dot com</code>. You can also <a href="https://github.com/sponsors/simonw">sponsor my work on GitHub</a>!)</p>
<p>This post is being <a href="https://news.ycombinator.com/item?id=30446039">discussed on Hacker News</a>.</p>
</article>


<hr>

<footer>
<p>
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="/david/log/" title="Accès au flux RSS"><svg class="icon icon-rss2">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-rss2"></use>
</svg> Suivre</a> •
<a href="http://larlet.com" title="Go to my English profile" data-instant><svg class="icon icon-user-tie">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-user-tie"></use>
</svg> Pro</a> •
<a href="mailto:david%40larlet.fr" title="Envoyer un courriel"><svg class="icon icon-mail">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-mail"></use>
</svg> Email</a> •
<abbr class="nowrap" title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340"><svg class="icon icon-hammer2">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-hammer2"></use>
</svg> Légal</abbr>
</p>
<template id="theme-selector">
<form>
<fieldset>
<legend><svg class="icon icon-brightness-contrast">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-brightness-contrast"></use>
</svg> Thème</legend>
<label>
<input type="radio" value="auto" name="chosen-color-scheme" checked> Auto
</label>
<label>
<input type="radio" value="dark" name="chosen-color-scheme"> Foncé
</label>
<label>
<input type="radio" value="light" name="chosen-color-scheme"> Clair
</label>
</fieldset>
</form>
</template>
</footer>
<script src="/static/david/js/instantpage-5.1.0.min.js" type="module"></script>
<script>
function loadThemeForm(templateName) {
const themeSelectorTemplate = document.querySelector(templateName)
const form = themeSelectorTemplate.content.firstElementChild
themeSelectorTemplate.replaceWith(form)

form.addEventListener('change', (e) => {
const chosenColorScheme = e.target.value
localStorage.setItem('theme', chosenColorScheme)
toggleTheme(chosenColorScheme)
})

const selectedTheme = localStorage.getItem('theme')
if (selectedTheme && selectedTheme !== 'undefined') {
form.querySelector(`[value="${selectedTheme}"]`).checked = true
}
}

const prefersColorSchemeDark = '(prefers-color-scheme: dark)'
window.addEventListener('load', () => {
let hasDarkRules = false
for (const styleSheet of Array.from(document.styleSheets)) {
let mediaRules = []
for (const cssRule of styleSheet.cssRules) {
if (cssRule.type !== CSSRule.MEDIA_RULE) {
continue
}
// WARNING: Safari does not have/supports `conditionText`.
if (cssRule.conditionText) {
if (cssRule.conditionText !== prefersColorSchemeDark) {
continue
}
} else {
if (cssRule.cssText.startsWith(prefersColorSchemeDark)) {
continue
}
}
mediaRules = mediaRules.concat(Array.from(cssRule.cssRules))
}

// WARNING: do not try to insert a Rule to a styleSheet you are
// currently iterating on, otherwise the browser will be stuck
// in a infinite loop…
for (const mediaRule of mediaRules) {
styleSheet.insertRule(mediaRule.cssText)
hasDarkRules = true
}
}
if (hasDarkRules) {
loadThemeForm('#theme-selector')
}
})
</script>
</body>
</html>

+ 32
- 0
cache/2022/9eac0872e78f3de333ff5df423060de2/index.md View File

@@ -0,0 +1,32 @@
title: Support open source that you use by paying the maintainers to talk to your team
url: https://simonwillison.net/2022/Feb/23/support-open-source/
hash_url: 9eac0872e78f3de333ff5df423060de2

<h2>Support open source that you use by paying the maintainers to talk to your team</h2>

<p>I think I’ve come up with a novel hack for the challenge of getting your company to financially support the open source projects that it uses: reach out to the maintainers and <em>offer them generous speaking fees</em> for remote talks to your engineering team.</p>
<h4>The problem</h4>
<p>Everyone agrees that open source projects deserve more financial support. Actually supporting projects can be surprisingly difficult though:</p>
<ul>
<li>Many projects don’t offer any clear mechanism for sponsoring them.</li>
<li>More to the point: open source projects are often really bad at asking for or thinking about money—it’s rarely a core competency!</li>
<li>Projects that do often get the tiers wrong: a $5/month “buy a coffee” GitHub sponsorship isn’t really going to make a meaningful impact on a project.</li>
<li>But… making the case that a for-profit company should hand over money for something they’re getting for free is hard! You need a lot of buy-in from a lot of stakeholders for anything involving spending money—and many of the people who care about this within a company won’t have enough internal clout to get it to happen.</li>
</ul>
<p>If you can make sponsorship happen, great: you should do that. But if not… how about reaching out to the maintainers and offering to hire them for an hour-long “consultancy” speaking engagement instead?</p>
<p>Thanks to the rise of remote working and Zoom, giving a talk no longer requires traveling to a venue—which could easily turn an hour-long opportunity into a full day.</p>
<p>One-off paid speaking opportunities are much more likely to fit into a regular company’s model of how money should spent than monthly donations.</p>
<h4>What if they’re not experienced speakers?</h4>
<p>The obvious flaw in this idea is that being an open source maintainer doesn’t necessarily mean that someone is a great public speaker: speaking is a skill unto itself.</p>
<p>If that’s the case, I propose running the session as a moderated Q&amp;A instead.</p>
<p>Find a member of your team with speaking experience to act as a host. Gather questions from your other engineers in advance, and share them with your guest so that they can prepare. Then run the session as a Q&amp;A.</p>
<p>This takes a huge deal of pressure off the speaker, and means you get a conversation that’s much more targeted to your team’s interests and needs as well.</p>
<h4>So go and do it!</h4>
<p>Remember, the key problem we’re trying to solve here is how to financially support projects and maintainers that may not be very good at asking for the money.</p>
<p>I want to take the pressure off those maintainers to learn how to market and sell their services.</p>
<p>So reach out to some projects you use and ask them if you can pay them to spend an hour of their time talking to your team! I’m excited to see how well this works.</p>
<p><strong>Be generous</strong>: This isn’t about negotiating the best speaking rate from someone who may never have been paid to speak before. This is about compensating them for the enormous value that your company has gained from their work, and using a clever accounting trick to do so. So offer them a generous fee up front! Paying over the odds should be part of your goal here.</p>
<p>For larger companies there’s probably an upper cap on the amount that can be expensed easily. Finding out what that is might be helpful here too.</p>
<p>Your company likely has an existing education budget which might be a good source of funds for this kind of engagement.</p>
<p>(If your team would benefit from a talk from me about <a href="https://datasette.io/">Datasette</a>, <a href="https://sqlite-utils.datasette.io/">sqlite-utils</a>, <a href="https://simonwillison.net/2020/Oct/9/git-scraping/">Git scraping</a> or any of the other projects I have going on, please drop me a line at <code>swillison at gmail dot com</code>. You can also <a href="https://github.com/sponsors/simonw">sponsor my work on GitHub</a>!)</p>
<p>This post is being <a href="https://news.ycombinator.com/item?id=30446039">discussed on Hacker News</a>.</p>

+ 207
- 0
cache/2022/a400ea6d0c196bbcaefbe1cc9af84fbb/index.html View File

@@ -0,0 +1,207 @@
<!doctype html><!-- This is a valid HTML5 document. -->
<!-- Screen readers, SEO, extensions and so on. -->
<html lang="fr">
<!-- Has to be within the first 1024 bytes, hence before the `title` element
See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
<meta charset="utf-8">
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
<!-- The viewport meta is quite crowded and we are responsible for that.
See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
<meta name="viewport" content="width=device-width,initial-scale=1">
<!-- Required to make a valid HTML5 document. -->
<title>Workplace serendipity, invention, and lessons from Prohibition 1920-1933 (archive) — David Larlet</title>
<meta name="description" content="Publication mise en cache pour en conserver une trace.">
<!-- That good ol' feed, subscribe :). -->
<link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/">
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png">
<link rel="manifest" href="/static/david/icons2/site.webmanifest">
<link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c">
<link rel="shortcut icon" href="/static/david/icons2/favicon.ico">
<meta name="msapplication-TileColor" content="#f7f7f7">
<meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml">
<meta name="theme-color" content="#f7f7f7" media="(prefers-color-scheme: light)">
<meta name="theme-color" content="#272727" media="(prefers-color-scheme: dark)">
<!-- Documented, feel free to shoot an email. -->
<link rel="stylesheet" href="/static/david/css/style_2021-01-20.css">
<!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. -->
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<script>
function toggleTheme(themeName) {
document.documentElement.classList.toggle(
'forced-dark',
themeName === 'dark'
)
document.documentElement.classList.toggle(
'forced-light',
themeName === 'light'
)
}
const selectedTheme = localStorage.getItem('theme')
if (selectedTheme !== 'undefined') {
toggleTheme(selectedTheme)
}
</script>

<meta name="robots" content="noindex, nofollow">
<meta content="origin-when-cross-origin" name="referrer">
<!-- Canonical URL for SEO purposes -->
<link rel="canonical" href="https://interconnected.org/home/2022/03/14/saloons">

<body class="remarkdown h1-underline h2-underline h3-underline em-underscore hr-center ul-star pre-tick" data-instant-intensity="viewport-all">


<article>
<header>
<h1>Workplace serendipity, invention, and lessons from Prohibition 1920-1933</h1>
</header>
<nav>
<p class="center">
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="https://interconnected.org/home/2022/03/14/saloons" title="Lien vers le contenu original">Source originale</a>
</p>
</nav>
<hr>
<div class="f5 f4-l measure-wide" id="social-select-root">
<p class="measure-wide f6 f5-l lh-copy black-80">Behold the power of lubricated thinking and general hanging out:</p>
<blockquote class="bl bw2 pl2 b--orange ml0 italic i">
<p class="measure-wide f6 f5-l lh-copy black-80">closing the saloons during prohibition reduced patenting by ~15%.</p>
</blockquote>
<p class="measure-wide f6 f5-l lh-copy black-80">This is from the blog <em>Marginal Revolution</em> summarising a paper by Mike Andrews.</p>
<p class="measure-wide f6 f5-l lh-copy black-80"><em>(<a href="https://en.wikipedia.org/wiki/Prohibition_in_the_United_States">Prohibition in the US</a>: alcoholic beverages were banned from 1920 to 1933.)</em></p>
<p class="measure-wide f6 f5-l lh-copy black-80">Saloons! The all-conquering social media of their day: <q>By 1897 there were roughly a quarter of a million saloons, or 23 for every Starbucks franchise today.</q> (Saloons combined drinking with other services such as a telegraph station and a payday lender.)</p>
<p class="measure-wide f6 f5-l lh-copy black-80">The convincing bit of evidence considers women…</p>
<blockquote cite="https://marginalrevolution.com/marginalrevolution/2021/09/saloons-of-invention.html" class="quoteback bl bw2 pl2 b--orange ml0 italic i" data-author="Marginal Revolution" data-title="Saloons of Invention (2021)">
<p class="measure-wide f6 f5-l lh-copy black-80">Andrew’s compares countries that were forced dry by state prohibition laws with previously dry counties, so the estimates are local and from across the country. He has significant patent data including the location of inventors and a variety of important robustness tests. Women, for example, didn’t typically patronize the saloons but also continued to patent at similar rates in wet and dry counties.</p>

</blockquote>
<p class="measure-wide f6 f5-l lh-copy black-80"><em>Ref.</em></p>
<p class="measure-wide f6 f5-l lh-copy black-80">Andrews, Michael, <a href="https://ssrn.com/abstract=3489466">Bar Talk: Informal Social Interactions, Alcohol Prohibition, and Invention</a> (November 18, 2019).</p>
<p class="measure-wide f6 f5-l lh-copy black-80">You can grab the PDF at that link. Absolutely read the introduction (p2) but honestly it is all good.</p>
<hr class="h1 xh2-ns w1 xw2-ns ml4 mv4 bb bw1 b--white">
<p class="measure-wide f6 f5-l lh-copy black-80">The paper itself is about where <strong>new ideas</strong> come from: <q>the importance of informal interactions on the rate and direction of inventive activity.</q></p>
<p class="measure-wide f6 f5-l lh-copy black-80">Two key takeaways:</p>
<blockquote class="bl bw2 pl2 b--orange ml0 italic i">
<p class="measure-wide f6 f5-l lh-copy black-80">social interactions are important for invention because they facilitate the exposure to new ideas, in addition to simply making it easier for individuals to find collaborators.</p>
</blockquote>
<p class="measure-wide f6 f5-l lh-copy black-80">Serendipitous exposure to ideas! The ability to find collaborators!</p>
<p class="measure-wide f6 f5-l lh-copy black-80">Also: you need saloons <strong>in addition to</strong> collaboration at work. There is evidence that <q>informal interactions in bars and formal interactions in the workplace are complements in the invention production function.</q></p>
<p class="measure-wide f6 f5-l lh-copy black-80">All was not lost when the saloons were shut: <q>while disrupting these existing networks can have negative effects, people will form alternative networks</q> – but it takes time.</p>
<p class="measure-wide f6 f5-l lh-copy black-80">Finally – there is a question about whether alcohol itself is responsible for invention, rather than serendipitous social interactions. In a sublime bit of analysis (section 5), Andrews looks at per-county cirrhosis death rates (because actual alcohol consumption was not reported, due to the legal situation) and finds that, for patents, it’s the bars and not the booze.</p>
<hr class="h1 xh2-ns w1 xw2-ns ml4 mv4 bb bw1 b--white">
<p class="measure-wide f6 f5-l lh-copy black-80">Going remote over lockdown is like prohibition and the saloons closing, right?</p>
<p class="measure-wide f6 f5-l lh-copy black-80">So much of being in the office is about bumping into people as a meeting room turns over, and you catch the end of a conversation or see who’s there, and that reminds you of something, so you get to drop in some extra information. Or the lunches, or the geography of nearby desktops and being pulled into a fortuitous chat, and so on…</p>
<p class="measure-wide f6 f5-l lh-copy black-80">Could this kind of serendipity be achieved in software?</p>
<p class="measure-wide f6 f5-l lh-copy black-80">Last year I was speculating about <a href="/home/2021/06/15/doorways">video call software and anterooms</a> and now I want to extend this idea to anterooms where people can have chance encounters…</p>
<p class="measure-wide f6 f5-l lh-copy black-80">IMAGINE your Zoom icon on your phone is the anteroom. You leave your last call of the day, but notice the icon still pulsing with muffled sound. So you tap to peek in – and find that the people from your previous two meetings have randomly spotted each other and are still there, white-boarding on the wall, swapping notes.</p>
<p class="measure-wide f6 f5-l lh-copy black-80">Given places like Pixar and Xerox PARC shaped their physical architecture to select for serendipitous mixing and corridor conversations, to great success, why aren’t we using information architecture to do the same?</p>
<p class="measure-wide f6 f5-l lh-copy black-80"><em>(Hey this is a little of what I’m working on in the day job. We’re not building a virtual office as the primary use case but even so, we have our meetings on-platform now – and one of the incidental features is that you bump into people between calls, and can spot people hanging out and choose to swing by to say hi. It’s minor but effective and super neat. <a href="https://twitter.com/genmon/status/1501147689886564352">BTW we’re hiring.</a>)</em></p>
<p class="measure-wide f6 f5-l lh-copy black-80">The supplementary question is how you build trust and help people feel confident enough to share their half-baked ideas with people they half know. It’s not <em>just</em> about bumping into people outside meetings, but repeated encounters to build familiarity, and the environment of the bar or the liminal quality of the corridors, and having gregarious friends and colleagues to connect conversations, and so on and so on.</p>
</div>
</article>


<hr>

<footer>
<p>
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="/david/log/" title="Accès au flux RSS"><svg class="icon icon-rss2">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-rss2"></use>
</svg> Suivre</a> •
<a href="http://larlet.com" title="Go to my English profile" data-instant><svg class="icon icon-user-tie">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-user-tie"></use>
</svg> Pro</a> •
<a href="mailto:david%40larlet.fr" title="Envoyer un courriel"><svg class="icon icon-mail">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-mail"></use>
</svg> Email</a> •
<abbr class="nowrap" title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340"><svg class="icon icon-hammer2">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-hammer2"></use>
</svg> Légal</abbr>
</p>
<template id="theme-selector">
<form>
<fieldset>
<legend><svg class="icon icon-brightness-contrast">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-brightness-contrast"></use>
</svg> Thème</legend>
<label>
<input type="radio" value="auto" name="chosen-color-scheme" checked> Auto
</label>
<label>
<input type="radio" value="dark" name="chosen-color-scheme"> Foncé
</label>
<label>
<input type="radio" value="light" name="chosen-color-scheme"> Clair
</label>
</fieldset>
</form>
</template>
</footer>
<script src="/static/david/js/instantpage-5.1.0.min.js" type="module"></script>
<script>
function loadThemeForm(templateName) {
const themeSelectorTemplate = document.querySelector(templateName)
const form = themeSelectorTemplate.content.firstElementChild
themeSelectorTemplate.replaceWith(form)

form.addEventListener('change', (e) => {
const chosenColorScheme = e.target.value
localStorage.setItem('theme', chosenColorScheme)
toggleTheme(chosenColorScheme)
})

const selectedTheme = localStorage.getItem('theme')
if (selectedTheme && selectedTheme !== 'undefined') {
form.querySelector(`[value="${selectedTheme}"]`).checked = true
}
}

const prefersColorSchemeDark = '(prefers-color-scheme: dark)'
window.addEventListener('load', () => {
let hasDarkRules = false
for (const styleSheet of Array.from(document.styleSheets)) {
let mediaRules = []
for (const cssRule of styleSheet.cssRules) {
if (cssRule.type !== CSSRule.MEDIA_RULE) {
continue
}
// WARNING: Safari does not have/supports `conditionText`.
if (cssRule.conditionText) {
if (cssRule.conditionText !== prefersColorSchemeDark) {
continue
}
} else {
if (cssRule.cssText.startsWith(prefersColorSchemeDark)) {
continue
}
}
mediaRules = mediaRules.concat(Array.from(cssRule.cssRules))
}

// WARNING: do not try to insert a Rule to a styleSheet you are
// currently iterating on, otherwise the browser will be stuck
// in a infinite loop…
for (const mediaRule of mediaRules) {
styleSheet.insertRule(mediaRule.cssText)
hasDarkRules = true
}
}
if (hasDarkRules) {
loadThemeForm('#theme-selector')
}
})
</script>
</body>
</html>

+ 40
- 0
cache/2022/a400ea6d0c196bbcaefbe1cc9af84fbb/index.md View File

@@ -0,0 +1,40 @@
title: Workplace serendipity, invention, and lessons from Prohibition 1920-1933
url: https://interconnected.org/home/2022/03/14/saloons
hash_url: a400ea6d0c196bbcaefbe1cc9af84fbb

<div class="f5 f4-l measure-wide" id="social-select-root">
<p class="measure-wide f6 f5-l lh-copy black-80">Behold the power of lubricated thinking and general hanging out:</p>
<blockquote class="bl bw2 pl2 b--orange ml0 italic i">
<p class="measure-wide f6 f5-l lh-copy black-80">closing the saloons during prohibition reduced patenting by ~15%.</p>
</blockquote>
<p class="measure-wide f6 f5-l lh-copy black-80">This is from the blog <em>Marginal Revolution</em> summarising a paper by Mike Andrews.</p>
<p class="measure-wide f6 f5-l lh-copy black-80"><em>(<a href="https://en.wikipedia.org/wiki/Prohibition_in_the_United_States">Prohibition in the US</a>: alcoholic beverages were banned from 1920 to 1933.)</em></p>
<p class="measure-wide f6 f5-l lh-copy black-80">Saloons! The all-conquering social media of their day: <q>By 1897 there were roughly a quarter of a million saloons, or 23 for every Starbucks franchise today.</q> (Saloons combined drinking with other services such as a telegraph station and a payday lender.)</p>
<p class="measure-wide f6 f5-l lh-copy black-80">The convincing bit of evidence considers women…</p>
<blockquote cite="https://marginalrevolution.com/marginalrevolution/2021/09/saloons-of-invention.html" class="quoteback bl bw2 pl2 b--orange ml0 italic i" data-author="Marginal Revolution" data-title="Saloons of Invention (2021)">
<p class="measure-wide f6 f5-l lh-copy black-80">Andrew’s compares countries that were forced dry by state prohibition laws with previously dry counties, so the estimates are local and from across the country. He has significant patent data including the location of inventors and a variety of important robustness tests. Women, for example, didn’t typically patronize the saloons but also continued to patent at similar rates in wet and dry counties.</p>

</blockquote>
<p class="measure-wide f6 f5-l lh-copy black-80"><em>Ref.</em></p>
<p class="measure-wide f6 f5-l lh-copy black-80">Andrews, Michael, <a href="https://ssrn.com/abstract=3489466">Bar Talk: Informal Social Interactions, Alcohol Prohibition, and Invention</a> (November 18, 2019).</p>
<p class="measure-wide f6 f5-l lh-copy black-80">You can grab the PDF at that link. Absolutely read the introduction (p2) but honestly it is all good.</p>
<hr class="h1 xh2-ns w1 xw2-ns ml4 mv4 bb bw1 b--white">
<p class="measure-wide f6 f5-l lh-copy black-80">The paper itself is about where <strong>new ideas</strong> come from: <q>the importance of informal interactions on the rate and direction of inventive activity.</q></p>
<p class="measure-wide f6 f5-l lh-copy black-80">Two key takeaways:</p>
<blockquote class="bl bw2 pl2 b--orange ml0 italic i">
<p class="measure-wide f6 f5-l lh-copy black-80">social interactions are important for invention because they facilitate the exposure to new ideas, in addition to simply making it easier for individuals to find collaborators.</p>
</blockquote>
<p class="measure-wide f6 f5-l lh-copy black-80">Serendipitous exposure to ideas! The ability to find collaborators!</p>
<p class="measure-wide f6 f5-l lh-copy black-80">Also: you need saloons <strong>in addition to</strong> collaboration at work. There is evidence that <q>informal interactions in bars and formal interactions in the workplace are complements in the invention production function.</q></p>
<p class="measure-wide f6 f5-l lh-copy black-80">All was not lost when the saloons were shut: <q>while disrupting these existing networks can have negative effects, people will form alternative networks</q> – but it takes time.</p>
<p class="measure-wide f6 f5-l lh-copy black-80">Finally – there is a question about whether alcohol itself is responsible for invention, rather than serendipitous social interactions. In a sublime bit of analysis (section 5), Andrews looks at per-county cirrhosis death rates (because actual alcohol consumption was not reported, due to the legal situation) and finds that, for patents, it’s the bars and not the booze.</p>
<hr class="h1 xh2-ns w1 xw2-ns ml4 mv4 bb bw1 b--white">
<p class="measure-wide f6 f5-l lh-copy black-80">Going remote over lockdown is like prohibition and the saloons closing, right?</p>
<p class="measure-wide f6 f5-l lh-copy black-80">So much of being in the office is about bumping into people as a meeting room turns over, and you catch the end of a conversation or see who’s there, and that reminds you of something, so you get to drop in some extra information. Or the lunches, or the geography of nearby desktops and being pulled into a fortuitous chat, and so on…</p>
<p class="measure-wide f6 f5-l lh-copy black-80">Could this kind of serendipity be achieved in software?</p>
<p class="measure-wide f6 f5-l lh-copy black-80">Last year I was speculating about <a href="/home/2021/06/15/doorways">video call software and anterooms</a> and now I want to extend this idea to anterooms where people can have chance encounters…</p>
<p class="measure-wide f6 f5-l lh-copy black-80">IMAGINE your Zoom icon on your phone is the anteroom. You leave your last call of the day, but notice the icon still pulsing with muffled sound. So you tap to peek in – and find that the people from your previous two meetings have randomly spotted each other and are still there, white-boarding on the wall, swapping notes.</p>
<p class="measure-wide f6 f5-l lh-copy black-80">Given places like Pixar and Xerox PARC shaped their physical architecture to select for serendipitous mixing and corridor conversations, to great success, why aren’t we using information architecture to do the same?</p>
<p class="measure-wide f6 f5-l lh-copy black-80"><em>(Hey this is a little of what I’m working on in the day job. We’re not building a virtual office as the primary use case but even so, we have our meetings on-platform now – and one of the incidental features is that you bump into people between calls, and can spot people hanging out and choose to swing by to say hi. It’s minor but effective and super neat. <a href="https://twitter.com/genmon/status/1501147689886564352">BTW we’re hiring.</a>)</em></p>
<p class="measure-wide f6 f5-l lh-copy black-80">The supplementary question is how you build trust and help people feel confident enough to share their half-baked ideas with people they half know. It’s not <em>just</em> about bumping into people outside meetings, but repeated encounters to build familiarity, and the environment of the bar or the liminal quality of the corridors, and having gregarious friends and colleagues to connect conversations, and so on and so on.</p>
</div>

+ 243
- 0
cache/2022/acd4b5cdd3ebf13e74a102563aa90b9a/index.html View File

@@ -0,0 +1,243 @@
<!doctype html><!-- This is a valid HTML5 document. -->
<!-- Screen readers, SEO, extensions and so on. -->
<html lang="fr">
<!-- Has to be within the first 1024 bytes, hence before the `title` element
See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
<meta charset="utf-8">
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
<!-- The viewport meta is quite crowded and we are responsible for that.
See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
<meta name="viewport" content="width=device-width,initial-scale=1">
<!-- Required to make a valid HTML5 document. -->
<title>On Paying Open Source Maintainers (archive) — David Larlet</title>
<meta name="description" content="Publication mise en cache pour en conserver une trace.">
<!-- That good ol' feed, subscribe :). -->
<link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/">
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png">
<link rel="manifest" href="/static/david/icons2/site.webmanifest">
<link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c">
<link rel="shortcut icon" href="/static/david/icons2/favicon.ico">
<meta name="msapplication-TileColor" content="#f7f7f7">
<meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml">
<meta name="theme-color" content="#f7f7f7" media="(prefers-color-scheme: light)">
<meta name="theme-color" content="#272727" media="(prefers-color-scheme: dark)">
<!-- Documented, feel free to shoot an email. -->
<link rel="stylesheet" href="/static/david/css/style_2021-01-20.css">
<!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. -->
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<script>
function toggleTheme(themeName) {
document.documentElement.classList.toggle(
'forced-dark',
themeName === 'dark'
)
document.documentElement.classList.toggle(
'forced-light',
themeName === 'light'
)
}
const selectedTheme = localStorage.getItem('theme')
if (selectedTheme !== 'undefined') {
toggleTheme(selectedTheme)
}
</script>

<meta name="robots" content="noindex, nofollow">
<meta content="origin-when-cross-origin" name="referrer">
<!-- Canonical URL for SEO purposes -->
<link rel="canonical" href="https://nadim.computer/posts/2021-12-12-maintainers.html">

<body class="remarkdown h1-underline h2-underline h3-underline em-underscore hr-center ul-star pre-tick" data-instant-intensity="viewport-all">


<article>
<header>
<h1>On Paying Open Source Maintainers</h1>
</header>
<nav>
<p class="center">
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="https://nadim.computer/posts/2021-12-12-maintainers.html" title="Lien vers le contenu original">Source originale</a>
</p>
</nav>
<hr>
<p><span class="date">2021-12-12</span></p>
<p><img src="https://nadim.computer/res/img/maintainers.jpg" alt=""></p>

<p>I’ve been almost completely ignoring the recent <a href="https://www.zdnet.com/article/security-warning-new-zero-day-in-the-log4j-java-library-is-already-being-exploited/">Log4j security vulnerability story</a> simply because there’s nothing new in it: the story itself is the same old story. The discourse is the same old discourse. The hot takes are the same old hot takes.</p>

<p>One more interesting fork of the discussion has been regarding <a href="https://blog.filippo.io/professional-maintainers/">how to render open source projects more sustainable</a>. The article opens with a pretty strong and true lead:</p>

<blockquote>
<p><em>“Open Source software runs the Internet, and by extension the economy. This is an undisputed fact about reality in 2021. And yet, the role of Open Source maintainer has failed to mature from a hobby into a proper profession.”</em> <br><br>
<em>[…]</em> <br><br>
<em>“Volunteers are doing their best in their spare time out of passion, or because they are (or were) having fun. They feel tremendous responsibility, but ultimately can’t be expected to persevere in the face of burnout, a change in life circumstances (like, having a kid or changing jobs), or even shifting priorities. They also can’t be expected to provide professional levels of performance because, again, no one is paying them and they are well within their rights to do only the fun parts of the “job”.”</em></p>
</blockquote>

<p>The post goes on to suggest that open source projects should incorporate into LLCs (or similar) and start contracting with big companies depending on their projects.</p>

<p>What puzzled me about the post is that the above was framed as some kind of novel idea, whereas if you read it once or twice you may quickly realize that it’s basically the playbook that led to the creation of Red Hat Inc. and many other companies out there. In fact, the list of <em>“examples of what [companies] might want out of open source projects”</em> provided in the article is pretty much exactly what Red Hat Inc. has done as a company towards RHEL and by extension Fedora Linux for the past decade.</p>

<p>There is however a more novel aspect to the post, one which seems to be suggesting that maintainers also consider sending largely unsolicited invoices to big companies using their software and expecting those companies to <em>“assess, approve and pay them as a matter of routine”</em>.</p>

<p>This, to me, is puzzling, and turns the post into a combination of two things: the idea that open source projects incorporate into LLCs, which is tried and true but definitely not without serious costs and downsides, and the idea that open source projects make themselves “<em>legible</em>” to the invoice-processing departments of big companies so that they can begin to aggressively invoice them for <em>“support and sponsorship”</em> on letterhead.</p>

<h4>Here are the list of issues/questions that I have with that post:</h4>

<blockquote>
<p><em>“The trick is that you can easily incorporate a pass-through US LLC and open a business account for it even if you’re not a US citizen, it’s not rocket science. I am not an accountant but I did it in an afternoon.”</em></p>
</blockquote>

<p>I run two companies: <a href="https://capsule.social">one US-based startup</a> with VC investors, 14 employees, etc., and one <a href="https://symbolic.software">EU-based software consulting outfit</a> for my personal consulting projects and software publications. Both of them indeed took mere hours to set up.</p>

<p>But that is an incredibly reductionist metric by which to measure the time, effort and commitment it takes to go from an registered LLC to a structure that’s handily dealing with invoicing big companies, processing these invoices, handling financials, delivering on contractual promises at scale, hiring, dealing with incidental costs and responsibilities, the potential need for legal, and much, much more.</p>

<p><strong>Starting a company, anytime, anywhere, for virtually anything, is an extra set of commitments <em>on top</em> of being an open source maintainer. It is more like going from being engaged to being married to your project, rather than a free solution to balance maintainer responsibilities with new compensatory income.</strong></p>

<p>If you want to, as the blog post suggests, use the above to get into a position where <em>“eventually, a whole career path with an onramp for junior maintainers, including training, like a real profession”</em>, then that’s not something for which the difficulty can be accurately represented with how long it takes to set up an LLC. That’s something based on an entirely new set of commitments and responsibilities: corporate responsibilities. Fiscal responsibilities. Taxes. Hiring. Delegating. Planning a product roadmap — you have to pretty much go all the way. It’s not a fun solution. It’s, at best, building a tiny Red Hat.</p>

<p>There are some extremely lucky exceptions, such as what WireGuard has been able to accomplish through donations, grants, and adoption by private startups such as Tailscale. But that’s largely through a level of luck, goodwill and pretty insane level of privilege on the part of the project’s founder, who nevertheless worked on the project obsessively without the promise of revenue anyway for its first many years. WireGuard was also intelligently designed to avoid unnecessary overhead on the maintainer: it brilliantly eschewed even the possibility of needing to deal with dead weight such as backwards-compatibility due to its lightweight cryptographic design, or the need for WireGuard’s maintainer to bother with the questions resulting from composing WireGuard into larger systems and protocols (see the end of this post for how this could have also applied to Log4j.)</p>

<p>So, when the blog post says that <em>“now is the perfect time for Open Source maintainers to become legible to the big companies that depend on them—and that want to get more out of them—and send them five-to-six figure invoices.”</em> it’s actually saying something far more boring and predictable: that it’s time for open source projects to become “legible” to companies by… becoming companies.</p>

<blockquote>
<p><em>“The moment a company has a contractual relationship with a maintainer for a significant sum of money (1x to 0.3x of a market salary, depending on how likely the maintainer is to invoice other companies, too) it can request what it needs as a contractual condition […] (Or not, if they turn down the contract! I’m very specifically not talking about transferring governance.)”</em></p>
</blockquote>

<p>Right, except that the transferring of governance doesn’t occur in some apolitical vacuum, and is often pressured by financial and political considerations that evolve as a result of the growth of the open source project. This point seems to be ignored and reduced to <em>“oh, but they can just turn down the contract!”</em> — which isn’t reflective, sadly, of how the world works. The blog post seems to be somewhat pushing for open source projects into the trap of becoming the clients of much more powerful corporations (and in some cases, nation-states) and I’ve personally seen the disastrous consequences this can often have on software and research communities over and over again (stories for another time).</p>

<blockquote>
<p><em>“This is what I hope to see happen more and more: Open Source maintainers graduating to sophisticated counterparties who send invoices for “support and sponsorship” on letterhead.”</em></p>
</blockquote>

<p>This point was actually (in what became the top comment on the blog post’s HN submission) <a href="https://news.ycombinator.com/item?id=29524103">already touched upon by the president of VideoLAN</a> in a much more effective manner than anything I could myself provide:</p>

<blockquote>
<p><em>“Well, this is exactly what I’ve been doing around VideoLAN (VLC, x264) and FFmpeg for the last few years. In order to do that, I’ve created 2 official companies Videolabs and FFlabs (besides the non-profit orgs) and I’ve gone through all the hoops to get paid (PO, billing, invoices, registering to large companies is a lot of paperwork, tbh, but well..) and we try and bill small to large companies that depends on those projects.</em> <br><br>
<em>And FFmpeg and x264 are the core of the online video.</em> <br><br>
<em>So I did exactly what Filippo is saying we should do.</em> <br><br>
<em>But the result is really not impressive. Seriously, asking for money for support from those companies feels like we’re pulling the nails, even if their full business depends on it. Getting 30-50k$ from those companies for support for one year can be very challenging, long or leading to nowhere at all.</em></p>
</blockquote>

<p>Exactly — a main reason why big companies are employing open source software to begin with is because it saves costs. Companies are subject to obligations on the part of shareholders to keep expenses as low as possible, while startups are under even more onerous restrictions due to runway considerations.</p>

<p>I would find myself hard-pressed to genuinely have faith in this level of corporate generosity, unless I myself ended up being an exceptionally pampered employee at a big tech company for so long that I managed to confuse what is a well-calculated socio-economic retention mechanism towards high value employees, for genuine kindness and a propensity for good will towards open source projects.</p>

<p>Finally, there are also some inconvenient truths regarding Log4j, the particular open source project that inspired this discussion:</p>

<ul>
<li>First, like many other open source projects, Log4j is small enough to easily become in-house-replaceable the moment that companies start to feel pressured to spend money on it. Tangentially, Apple doesn’t sponsor Homebrew.</li>
<li>Second, the fact that you can also solve a lot of these problems by reducing your overhead as a maintainer, and not by increasing it:</li>
</ul>

<blockquote class="twitter-tweet tw-align-center" data-dnt="true"><p lang="en" dir="ltr">Apparently the maintainers of Log4j already agreed the underlying functionality was a ridiculous feature and wanted to remove it, but were held back by backwards compatibility requirements <br><br>if your engineers are telling you something old needs to go, it needs to go</p>&mdash; badidea 🪐 (@0xabad1dea) <a href="https://twitter.com/0xabad1dea/status/1469643409799499785">December 11, 2021</a></blockquote>

<p>All of this to say that, once more, reality is ultimately both more boring and more complicated. I wish it wasn’t: I’d love for it to be so easy and consequence-free to raise money as an open source project maintainer.</p>
</article>


<hr>

<footer>
<p>
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="/david/log/" title="Accès au flux RSS"><svg class="icon icon-rss2">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-rss2"></use>
</svg> Suivre</a> •
<a href="http://larlet.com" title="Go to my English profile" data-instant><svg class="icon icon-user-tie">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-user-tie"></use>
</svg> Pro</a> •
<a href="mailto:david%40larlet.fr" title="Envoyer un courriel"><svg class="icon icon-mail">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-mail"></use>
</svg> Email</a> •
<abbr class="nowrap" title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340"><svg class="icon icon-hammer2">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-hammer2"></use>
</svg> Légal</abbr>
</p>
<template id="theme-selector">
<form>
<fieldset>
<legend><svg class="icon icon-brightness-contrast">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-brightness-contrast"></use>
</svg> Thème</legend>
<label>
<input type="radio" value="auto" name="chosen-color-scheme" checked> Auto
</label>
<label>
<input type="radio" value="dark" name="chosen-color-scheme"> Foncé
</label>
<label>
<input type="radio" value="light" name="chosen-color-scheme"> Clair
</label>
</fieldset>
</form>
</template>
</footer>
<script src="/static/david/js/instantpage-5.1.0.min.js" type="module"></script>
<script>
function loadThemeForm(templateName) {
const themeSelectorTemplate = document.querySelector(templateName)
const form = themeSelectorTemplate.content.firstElementChild
themeSelectorTemplate.replaceWith(form)

form.addEventListener('change', (e) => {
const chosenColorScheme = e.target.value
localStorage.setItem('theme', chosenColorScheme)
toggleTheme(chosenColorScheme)
})

const selectedTheme = localStorage.getItem('theme')
if (selectedTheme && selectedTheme !== 'undefined') {
form.querySelector(`[value="${selectedTheme}"]`).checked = true
}
}

const prefersColorSchemeDark = '(prefers-color-scheme: dark)'
window.addEventListener('load', () => {
let hasDarkRules = false
for (const styleSheet of Array.from(document.styleSheets)) {
let mediaRules = []
for (const cssRule of styleSheet.cssRules) {
if (cssRule.type !== CSSRule.MEDIA_RULE) {
continue
}
// WARNING: Safari does not have/supports `conditionText`.
if (cssRule.conditionText) {
if (cssRule.conditionText !== prefersColorSchemeDark) {
continue
}
} else {
if (cssRule.cssText.startsWith(prefersColorSchemeDark)) {
continue
}
}
mediaRules = mediaRules.concat(Array.from(cssRule.cssRules))
}

// WARNING: do not try to insert a Rule to a styleSheet you are
// currently iterating on, otherwise the browser will be stuck
// in a infinite loop…
for (const mediaRule of mediaRules) {
styleSheet.insertRule(mediaRule.cssText)
hasDarkRules = true
}
}
if (hasDarkRules) {
loadThemeForm('#theme-selector')
}
})
</script>
</body>
</html>

+ 77
- 0
cache/2022/acd4b5cdd3ebf13e74a102563aa90b9a/index.md View File

@@ -0,0 +1,77 @@
title: On Paying Open Source Maintainers
url: https://nadim.computer/posts/2021-12-12-maintainers.html
hash_url: acd4b5cdd3ebf13e74a102563aa90b9a


<span class="date">2021-12-12</span>
<p><img src="https://nadim.computer/res/img/maintainers.jpg" alt=""></p>

<p>I’ve been almost completely ignoring the recent <a href="https://www.zdnet.com/article/security-warning-new-zero-day-in-the-log4j-java-library-is-already-being-exploited/">Log4j security vulnerability story</a> simply because there’s nothing new in it: the story itself is the same old story. The discourse is the same old discourse. The hot takes are the same old hot takes.</p>

<p>One more interesting fork of the discussion has been regarding <a href="https://blog.filippo.io/professional-maintainers/">how to render open source projects more sustainable</a>. The article opens with a pretty strong and true lead:</p>

<blockquote>
<p><em>“Open Source software runs the Internet, and by extension the economy. This is an undisputed fact about reality in 2021. And yet, the role of Open Source maintainer has failed to mature from a hobby into a proper profession.”</em> <br><br>
<em>[…]</em> <br><br>
<em>“Volunteers are doing their best in their spare time out of passion, or because they are (or were) having fun. They feel tremendous responsibility, but ultimately can’t be expected to persevere in the face of burnout, a change in life circumstances (like, having a kid or changing jobs), or even shifting priorities. They also can’t be expected to provide professional levels of performance because, again, no one is paying them and they are well within their rights to do only the fun parts of the “job”.”</em></p>
</blockquote>

<p>The post goes on to suggest that open source projects should incorporate into LLCs (or similar) and start contracting with big companies depending on their projects.</p>

<p>What puzzled me about the post is that the above was framed as some kind of novel idea, whereas if you read it once or twice you may quickly realize that it’s basically the playbook that led to the creation of Red Hat Inc. and many other companies out there. In fact, the list of <em>“examples of what [companies] might want out of open source projects”</em> provided in the article is pretty much exactly what Red Hat Inc. has done as a company towards RHEL and by extension Fedora Linux for the past decade.</p>

<p>There is however a more novel aspect to the post, one which seems to be suggesting that maintainers also consider sending largely unsolicited invoices to big companies using their software and expecting those companies to <em>“assess, approve and pay them as a matter of routine”</em>.</p>

<p>This, to me, is puzzling, and turns the post into a combination of two things: the idea that open source projects incorporate into LLCs, which is tried and true but definitely not without serious costs and downsides, and the idea that open source projects make themselves “<em>legible</em>” to the invoice-processing departments of big companies so that they can begin to aggressively invoice them for <em>“support and sponsorship”</em> on letterhead.</p>

<h4>Here are the list of issues/questions that I have with that post:</h4>

<blockquote>
<p><em>“The trick is that you can easily incorporate a pass-through US LLC and open a business account for it even if you’re not a US citizen, it’s not rocket science. I am not an accountant but I did it in an afternoon.”</em></p>
</blockquote>

<p>I run two companies: <a href="https://capsule.social">one US-based startup</a> with VC investors, 14 employees, etc., and one <a href="https://symbolic.software">EU-based software consulting outfit</a> for my personal consulting projects and software publications. Both of them indeed took mere hours to set up.</p>

<p>But that is an incredibly reductionist metric by which to measure the time, effort and commitment it takes to go from an registered LLC to a structure that’s handily dealing with invoicing big companies, processing these invoices, handling financials, delivering on contractual promises at scale, hiring, dealing with incidental costs and responsibilities, the potential need for legal, and much, much more.</p>

<p><strong>Starting a company, anytime, anywhere, for virtually anything, is an extra set of commitments <em>on top</em> of being an open source maintainer. It is more like going from being engaged to being married to your project, rather than a free solution to balance maintainer responsibilities with new compensatory income.</strong></p>

<p>If you want to, as the blog post suggests, use the above to get into a position where <em>“eventually, a whole career path with an onramp for junior maintainers, including training, like a real profession”</em>, then that’s not something for which the difficulty can be accurately represented with how long it takes to set up an LLC. That’s something based on an entirely new set of commitments and responsibilities: corporate responsibilities. Fiscal responsibilities. Taxes. Hiring. Delegating. Planning a product roadmap — you have to pretty much go all the way. It’s not a fun solution. It’s, at best, building a tiny Red Hat.</p>

<p>There are some extremely lucky exceptions, such as what WireGuard has been able to accomplish through donations, grants, and adoption by private startups such as Tailscale. But that’s largely through a level of luck, goodwill and pretty insane level of privilege on the part of the project’s founder, who nevertheless worked on the project obsessively without the promise of revenue anyway for its first many years. WireGuard was also intelligently designed to avoid unnecessary overhead on the maintainer: it brilliantly eschewed even the possibility of needing to deal with dead weight such as backwards-compatibility due to its lightweight cryptographic design, or the need for WireGuard’s maintainer to bother with the questions resulting from composing WireGuard into larger systems and protocols (see the end of this post for how this could have also applied to Log4j.)</p>

<p>So, when the blog post says that <em>“now is the perfect time for Open Source maintainers to become legible to the big companies that depend on them—and that want to get more out of them—and send them five-to-six figure invoices.”</em> it’s actually saying something far more boring and predictable: that it’s time for open source projects to become “legible” to companies by… becoming companies.</p>

<blockquote>
<p><em>“The moment a company has a contractual relationship with a maintainer for a significant sum of money (1x to 0.3x of a market salary, depending on how likely the maintainer is to invoice other companies, too) it can request what it needs as a contractual condition […] (Or not, if they turn down the contract! I’m very specifically not talking about transferring governance.)”</em></p>
</blockquote>

<p>Right, except that the transferring of governance doesn’t occur in some apolitical vacuum, and is often pressured by financial and political considerations that evolve as a result of the growth of the open source project. This point seems to be ignored and reduced to <em>“oh, but they can just turn down the contract!”</em> — which isn’t reflective, sadly, of how the world works. The blog post seems to be somewhat pushing for open source projects into the trap of becoming the clients of much more powerful corporations (and in some cases, nation-states) and I’ve personally seen the disastrous consequences this can often have on software and research communities over and over again (stories for another time).</p>

<blockquote>
<p><em>“This is what I hope to see happen more and more: Open Source maintainers graduating to sophisticated counterparties who send invoices for “support and sponsorship” on letterhead.”</em></p>
</blockquote>

<p>This point was actually (in what became the top comment on the blog post’s HN submission) <a href="https://news.ycombinator.com/item?id=29524103">already touched upon by the president of VideoLAN</a> in a much more effective manner than anything I could myself provide:</p>

<blockquote>
<p><em>“Well, this is exactly what I’ve been doing around VideoLAN (VLC, x264) and FFmpeg for the last few years. In order to do that, I’ve created 2 official companies Videolabs and FFlabs (besides the non-profit orgs) and I’ve gone through all the hoops to get paid (PO, billing, invoices, registering to large companies is a lot of paperwork, tbh, but well..) and we try and bill small to large companies that depends on those projects.</em> <br><br>
<em>And FFmpeg and x264 are the core of the online video.</em> <br><br>
<em>So I did exactly what Filippo is saying we should do.</em> <br><br>
<em>But the result is really not impressive. Seriously, asking for money for support from those companies feels like we’re pulling the nails, even if their full business depends on it. Getting 30-50k$ from those companies for support for one year can be very challenging, long or leading to nowhere at all.</em></p>
</blockquote>

<p>Exactly — a main reason why big companies are employing open source software to begin with is because it saves costs. Companies are subject to obligations on the part of shareholders to keep expenses as low as possible, while startups are under even more onerous restrictions due to runway considerations.</p>

<p>I would find myself hard-pressed to genuinely have faith in this level of corporate generosity, unless I myself ended up being an exceptionally pampered employee at a big tech company for so long that I managed to confuse what is a well-calculated socio-economic retention mechanism towards high value employees, for genuine kindness and a propensity for good will towards open source projects.</p>

<p>Finally, there are also some inconvenient truths regarding Log4j, the particular open source project that inspired this discussion:</p>

<ul>
<li>First, like many other open source projects, Log4j is small enough to easily become in-house-replaceable the moment that companies start to feel pressured to spend money on it. Tangentially, Apple doesn’t sponsor Homebrew.</li>
<li>Second, the fact that you can also solve a lot of these problems by reducing your overhead as a maintainer, and not by increasing it:</li>
</ul>

<blockquote class="twitter-tweet tw-align-center" data-dnt="true"><p lang="en" dir="ltr">Apparently the maintainers of Log4j already agreed the underlying functionality was a ridiculous feature and wanted to remove it, but were held back by backwards compatibility requirements <br><br>if your engineers are telling you something old needs to go, it needs to go</p>&mdash; badidea 🪐 (@0xabad1dea) <a href="https://twitter.com/0xabad1dea/status/1469643409799499785">December 11, 2021</a></blockquote>

<p>All of this to say that, once more, reality is ultimately both more boring and more complicated. I wish it wasn’t: I’d love for it to be so easy and consequence-free to raise money as an open source project maintainer.</p>

+ 257
- 0
cache/2022/ad5756e74f5c976458c42eeb9e60707e/index.html View File

@@ -0,0 +1,257 @@
<!doctype html><!-- This is a valid HTML5 document. -->
<!-- Screen readers, SEO, extensions and so on. -->
<html lang="fr">
<!-- Has to be within the first 1024 bytes, hence before the `title` element
See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
<meta charset="utf-8">
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
<!-- The viewport meta is quite crowded and we are responsible for that.
See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
<meta name="viewport" content="width=device-width,initial-scale=1">
<!-- Required to make a valid HTML5 document. -->
<title>Guerre en Ukraine : 10 enseignements syriens (archive) — David Larlet</title>
<meta name="description" content="Publication mise en cache pour en conserver une trace.">
<!-- That good ol' feed, subscribe :). -->
<link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/">
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png">
<link rel="manifest" href="/static/david/icons2/site.webmanifest">
<link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c">
<link rel="shortcut icon" href="/static/david/icons2/favicon.ico">
<meta name="msapplication-TileColor" content="#f7f7f7">
<meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml">
<meta name="theme-color" content="#f7f7f7" media="(prefers-color-scheme: light)">
<meta name="theme-color" content="#272727" media="(prefers-color-scheme: dark)">
<!-- Documented, feel free to shoot an email. -->
<link rel="stylesheet" href="/static/david/css/style_2021-01-20.css">
<!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. -->
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<script>
function toggleTheme(themeName) {
document.documentElement.classList.toggle(
'forced-dark',
themeName === 'dark'
)
document.documentElement.classList.toggle(
'forced-light',
themeName === 'light'
)
}
const selectedTheme = localStorage.getItem('theme')
if (selectedTheme !== 'undefined') {
toggleTheme(selectedTheme)
}
</script>

<meta name="robots" content="noindex, nofollow">
<meta content="origin-when-cross-origin" name="referrer">
<!-- Canonical URL for SEO purposes -->
<link rel="canonical" href="https://cantinesyrienne.fr/ressources/les-peuples-veulent/guerre-en-ukraine-10-enseignements-syriens">

<body class="remarkdown h1-underline h2-underline h3-underline em-underscore hr-center ul-star pre-tick" data-instant-intensity="viewport-all">


<article>
<header>
<h1>Guerre en Ukraine : 10 enseignements syriens</h1>
</header>
<nav>
<p class="center">
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="https://cantinesyrienne.fr/ressources/les-peuples-veulent/guerre-en-ukraine-10-enseignements-syriens" title="Lien vers le contenu original">Source originale</a>
</p>
</nav>
<hr>
<p><strong>Mars 2022</strong></p>
<p>Image : Poutine ! la gloire ne se bâtit jamais sur les cadavres d'enfants, on vivra assez longtemps pour cracher sur ton histoire.</p>
<p>Cet article est publié simultanément sur <a href="https://fr.crimethinc.com/">Crimethinc.</a> et traduit en anglais <a href="https://crimethinc.com/2022/03/07/war-in-ukraine-ten-lessons-from-syria-syrian-exiles-on-how-their-experience-can-inform-resistance-to-the-invasion">ici</a>.</p>
<hr>
<p>Nous savons que cela peut sembler difficile de se positionner dans un moment comme celui-ci. Entre l’unanimité idéologique des médias dominants et les voix qui relaient sans scrupule la propagande du Kremlin, on ne sait plus qui écouter. Entre une OTAN aux mains sales et un régime Russe criminel on ne sait plus qui combattre, qui soutenir. </p>
<p><br>Nous participant.e.s et ami.e.s de la révolution syrienne souhaitons défendre une troisième voie et  proposer un point de vue basé sur les apprentissages de plus de 10 ans de soulèvement et de guerre en Syrie. </p>
<p><br>Clarifions tout de suite : nous défendons aujourd'hui encore la révolte en Syrie dans sa dimension de soulèvement populaire, démocratique et émancipateur, notamment incarnée par l’expérience des comités de coordination et des conseils locaux de la révolution. Si beaucoup l'ont oublié, nous affirmons que ni les crimes et la propagande de Bachar al-Assad ni ceux des djihadistes ne sauraient faire taire cette voix. </p>
<p><br>Dans ce qui suit, nous n’entendons pas comparer ce qui se passe dans les deux pays. Si ces deux guerres ont débuté par une révolte et si l’un des agresseurs est le même, les situations restent bien différentes. Nous comptons plutôt, à partir de nos apprentissages de la révolution et puis de la guerre en Syrie, proposer quelques pistes afin d'aider ceux et celles qui défendent sincèrement des principes émancipateurs à prendre position. </p>
<figure>
<img src="https://cantinesyrienne.fr/media/pages/ressources/les-peuples-veulent/guerre-en-ukraine-10-enseignements-syriens/1e682e36cc-1646657542/syria-russia-conflict.jpg" alt="">

<figcaption>
Les forces russes et syriennes près des affiches d'Assad et Poutine à l'est de la province d'Idlib </figcaption>
</figure>
<p><br><br><strong>1 : Écouter les voix des premier.e.s concerné.e.s par les événements.</strong> Plutôt que les experts en géopolitique, écoutons avant tout la parole de ceux et celles qui vivent la guerre et ont vécu la révolution (Maïdan 2014), écoutons ceux et celles qui souffrent du régime de Poutine, en Russie et ailleurs depuis 20 ans. Nous vous invitons à privilégier les voix des gens et des organisations défendant, sur place, des principes de démocratie directe, de féminisme et d’égalitarisme. Leurs positions en Ukraine et leurs demandes vis-à-vis de l'extérieur vous aideront à construire votre propre opinion.</p>
<p><br>Adopter cette approche vis à vis de la Syrie aurait permis de voir - et peut être de soutenir - les expériences d’auto-organisation impressionnantes et prometteuses qui ont fleuri dans tout le pays. De plus, écouter les <a href="https://fr.crimethinc.com/2022/02/15/anarchistes-et-guerre-perspectives-anti-autoritaires-en-ukraine">voix venant d’Ukraine nous rappelle</a> que toutes ces tensions ont débuté par le soulèvement de Maïdan. Ne faisons pas l’erreur de réduire la révolte populaire ukrainienne (aussi imparfaite ou “impure” soit elle) à un conflit d'intérêts entre grandes puissances comme cela a été fait à dessein pour la révolution syrienne. </p>
<p><br><strong>2 : Se méfier de la géopolitique de comptoir.</strong> S'il est certain qu’il est souhaitable de mieux comprendre les intérêts économiques, diplomatiques et militaires des grandes puissances,  se contenter d’une lecture géopolitique de la situation a tendance à déconnecter du terrain. Cela pousse les gens normaux comme vous et nous à éclipser les protagonistes ordinaires du conflit, ceux et celles qui nous ressemblent, ceux et celles à qui l’on peut s’identifier.</p>
<p>N'oublions surtout pas : ce qui va se passer avant tout, c'est que des gens vont souffrir à cause des choix de gouvernants qui prennent le monde pour un échiquier et pour un réservoir de ressources à piller.  Cette vision est celle des dominants. Elle ne devrait jamais être utilisée par les peuples qui, selon nous, devrait se concentrer sur la construction de ponts entre eux et la recherche d’intérêts communs. Cela ne signifie pas qu’il faille négliger la stratégie, mais cela implique de le faire à sa propre échelle ;  qui n'est pas, pour l'heure, de déplacer des divisions de chars ou de couper les importations de gaz. (Voir nos propositions concrètes à la fin de l’article). </p>
<p><br><strong>3 : N’accepter aucun tri entre bon et mauvais exilé.e. </strong>Disons le clairement, l'accueil des réfugié.e.s syrien.ne.s en Europe fût souvent meilleur (mais tout sauf idéal) que celui des réfugié.e.s d'Afrique subsaharienne par exemple. Les images de réfugié.e.s noir.e.s refoulé.e.s à la frontière entre l’Ukraine et la Pologne ainsi que les commentaires dans les grands médias privilégiant l'arrivée de réfugié.e.s Ukrainien.ne.s “de grande qualité” aux barbares Syriens ne sont rien d’autre que des preuves d’un racisme européen de plus en plus décomplexé. Si nous défendons un accueil inconditionnel pour les Ukrainien.ne.s qui fuient les horreurs de la guerre, nous refusons toute hiérarchisation entre les réfugié.e.s.</p>
<p><br><strong>4 : Se méfier de la position des médias mainstream</strong>. Si, comme en Syrie, ils prétendent tenir une position humaniste et progressiste, une bonne partie de ces médias risquent encore une fois de se limiter à une position victimisante et dépolitisante des Ukrainien.ne.s sur place ou en exil. On ne leur donnera la parole que pour parler de cas individuel, de fuite, de la peur des bombes, etc. C’est une position incapable de penser les Ukrainien.ne.s comme des acteurs et des actrices politiques à part entière capables d'exprimer des opinions ou des analyses politiques sur la situation dans leur propre pays. De plus, ces médias risquent de défendre une position grossièrement pro-occidentale sans nuance, profondeur historique ou explication sur les intérêts des pays occidentaux, présentés comme des défenseurs du bien, des libertés ou d’une démocratie libérale idéalisée.</p>
<p><br><strong>5 :</strong> <strong>Ne pas faire des pays occidentaux l’axe du bien</strong>. Si ce ne sont pas eux directement qui envahissent l'Ukraine, privons nous de toute naïveté concernant l’OTAN et les pays occidentaux.  Nous devons refuser à tout prix de présenter ceux-ci comme des défenseurs du “monde libre”. Rappelons, s'il le faut, que l'Occident a lui-même basé sa puissance (et continue de la faire) sur le colonialisme, l’impérialisme, l’oppression et la spoliation des richesses de centaines de peuples dans le monde entier. </p>
<p><br>Pour ne parler que du XXIe siècle, nous n'oublions bien sûr pas les désastres infligés par les invasions en Irak et en Afghanistan. Plus récemment encore, pendant les révolutions arabes de 2011, au lieu de soutenir les composantes démocratiques et progressistes, l'Occident s’est soucié essentiellement de maintenir sa domination et ses intérêts économiques. Dans le même temps, il continue à vendre des armes et à entretenir des relations privilégiées avec des dictatures arabes et des monarchies du Golfe. La France y a même ajouté, avec l’intervention en Libye le mensonge d’une guerre pour des motifs économiques sous couvert de soutien au combat pour la démocratie. </p>
<p><br>En plus de son rôle à l’international, la situation à l’intérieur même de ces pays ne cesse de se dégrader : montée de l’autoritarisme, de la surveillance, des inégalités, et surtout du racisme.</p>
<p> <br>Aujourd’hui, si nous pensons que le régime de Poutine représente une menace plus importante pour l'autodétermination des peuples, ce n’est pas que les pays occidentaux seraient devenus subitement “gentils” mais parce que les puissances occidentales n’ont actuellement plus autant de moyens pour maintenir leur domination et leur hégémonie. Nous restons bien entendu très méfiants sur cette hypothèse car si Poutine est défait par les pays occidentaux, cela pourrait contribuer à leur redonner une vraie puissance. </p>
<p><br>Nous conseillons ainsi aux Ukrainien.ne.s de ne pas compter sur la “communauté internationale” ou les “Nations Unies” qui, comme en Syrie, risquent de briller par leur hypocrisie et faire croire en des chimères. </p>
<p></p>
<figure>
<img src="https://cantinesyrienne.fr/media/pages/ressources/les-peuples-veulent/guerre-en-ukraine-10-enseignements-syriens/473be3845a-1646658087/dkju3gvx0aa-xfj.jpg" alt="">

<figcaption>
Traduction de la phrase en arabe : "Le temps de la masculinité et les hommes" </figcaption>
</figure>
<p><br><br><strong>6 :  Combattre tous les impérialismes ! </strong>Le “campisme” :  doctrine d’une autre époque qui consistait  pendant la guerre froide à soutenir coûte que coûte l’URSS face aux États capitalistes et impérialistes pousse aujourd'hui encore, une partie de la gauche radicale à soutenir la Russie de Poutine en Ukraine ou à relativiser la guerre en cours. Comme ils l’ont fait en Syrie, ils utilisent le prétexte que les régimes russe ou syrien incarneraient la lutte contre l'impérialisme occidental. Malheureusement, cet anti-impérialisme manichéen, essentiellement théorique, refuse de voir l’impérialisme chez d'autres acteurs que l’Occident. Pourtant il faudra bien qualifier ce que les régimes russes, chinois ou même iranien font depuis des années : étendre leur domination politique et économique dans certaines régions en dépossédant les populations locales de leur auto-détermination. Qu’ils choisissent le mot qu’ils veulent si “impérialisme” leur semble inadéquat, mais nous n'accepterons jamais l'euphémisation de la violence et de la domination infligées aux populations au nom d’une pseudo précision théorique. </p>
<p><br>Plus grave encore, cette position pousse cette gauche à se faire le relais de la propagande de ces régimes jusqu'à virer dans le négationnisme. En parlant de “coup d'État” pour qualifier Maïdan ou en niant les crimes de guerre perpétrés par l’armée Russes en Syrie. Cette gauche est allée jusqu’à réfuter l’utilisation de gaz sarin par le régime d’Assad, s'appuyant sur une méfiance (souvent légitime) envers les grands médias pour diffuser ces mensonges.  </p>
<p><br>C’est une attitude méprisable et irresponsable quand l’on sait que la montée du conspirationnisme ne favorise jamais le camp de l’émancipation mais bien l'extrême droite et le racisme. Sur la guerre en Ukraine, ces anti-impérialistes imbéciles, dont certains se revendiquant pourtant de l’anti-facisme, sont les alliés de circonstance d'une grande partie de l'extrême droite. </p>
<p><br>En Syrie, chauffés à blanc par des fantasmes supremacistes et des rêves de croisade contre l’islam, la droite radicale avait déjà défendu Poutine et le régime Syrien pour leurs prétendues actions face au djihadisme. Et ceci sans jamais comprendre la responsabilité du régime d’Assad dans la montée des djihadistes en Syrie.  </p>
<p></p>
<p><br><strong>7 : Ne pas renvoyer dos à dos l’Ukraine et la Russie.</strong> En Ukraine, l’identité de l’agresseur est connue de tous.tes. Si l’offensive de Poutine répond quelque part à la pression de l'OTAN, elle est avant tout la poursuite d’une offensive impériale et contre-révolutionnaire. Après avoir envahi la Crimée, après avoir aidé à écraser les soulèvements en Syrie (2015-2022), Biélorussie (2020) et au Kazakhstan (2022), Vladimir Poutine ne tolère plus ce vent de contestation - incarné par la destitution du président pro-russe pendant Maïdan - au sein de pays sous son influence. Il souhaite écraser toute velléité émancipatrice fragilisant son pouvoir.</p>
<p><br>En Syrie aussi, le responsable direct de la guerre ne fait aucun doute. Le régime Syrien de Bachar al-Assad, en ordonnant à la police de tirer, d’emprisonner et de torturer les manifestant.e.s dès les premiers jours de contestation décida lui-même de déclencher une guerre contre la population. Nous aimerions (et aurions aimé) que les personnes qui défendent la liberté et l’égalité soient unanimes dans leur prise de position contre ces dictateurs qui mènent des guerres contre les peuples. </p>
<p><br>Si nous comprenons et rejoignons l’appel qui demande la fin de la guerre, nous insistons qu’il faut le faire sans ambiguïté sur l'identité de l’agresseur. Ni en Ukraine ni en Syrie ni nulle part ailleurs, il n’est possible de reprocher aux gens ordinaires le fait de prendre les armes pour essayer de défendre leur vie et celles de leur famille.   </p>
<p><br></p>
<figure>
<img src="https://cantinesyrienne.fr/media/pages/ressources/les-peuples-veulent/guerre-en-ukraine-10-enseignements-syriens/5af870a2dc-1646657818/1276274_522233771203401_453981693_o.jpg" alt="">

<figcaption>
Aux militants anti-guerre ! SVP soutenez l'intervention, nous sommes anti-guerre, nous sommes contre Assad qui tuent nos enfants </figcaption>
</figure>
<p><br>Plus généralement, nous conseillons aux gens qui ne savent pas ce qu’est une dictature (même si les pays occidentaux deviennent de plus en plus ouvertement autoritaire) ou d'être bombardé.e, de s’abstenir de dire aux Ukrainien.ne.s - comme certains l’ont dit déjà aux Syrien.ne.s ou aux Hongkongais.es - de ne pas solliciter l’aide de l’Occident ou de ne pas souhaiter la démocratie libérale ou représentative comme système politique a minima. Beaucoup de ces gens, déjà lucides sur les imperfections de ces systèmes politiques ont comme priorité, non pas de tenir un positionnement politique irréprochable, mais plutôt de survivre aux bombardements du lendemain ou encore de ne pas finir dans un pays où un mot de travers peut valoir 20 ans de prison. Tenir ce genre de discours démontre de la volonté d’imposer son point de vue théorique à un contexte qui n'est pas le sien. Cela relève d'une vraie déconnexion avec le terrain et d’un privilège bien occidental. </p>
<p><br>Ecoutons plutôt les mots des ami.es ukirainien.ne.s qui la semaine dernière affirment “<a href="https://fr.crimethinc.com/2022/02/15/anarchistes-et-guerre-perspectives-anti-autoritaires-en-ukraine">Nous sommes fermement convaincus que la république la plus imparfaite est mille fois meilleure que la monarchie la plus éclairée</a>”. </p>
<p><br><strong>8 : Comprendre que la société Ukrainienne, comme en Syrie, comme en France, est traversée de différents courants. </strong>Nous connaissons bien le procédé qui consiste à désigner une grande menace pour effrayer les soutiens potentiels. La réthorique du “terrorisme islamiste” en Syrie utilisé par Bachar al-Assad dès les premiers jours de la révolution, aujourd’hui “le nazime” et “l’ultra-nationalisme” brandi par Poutine et ses alliés. <br></p>
<p>Si nous pensons que cette propagande est volontairement exagérée et qu’il ne faut en rien la relayer en l’état, l’expérience en Syrie pousse à ne pas sous-estimer les composantes réactionnaires des mouvements populaires. </p>
<p><br>En Ukraine, des nationalistes Ukrainiens, parfois fascistes, ont eu un rôle important dans les manifestations de Maïdan et dans la guerre contre la Russie qui s’en est suivie. De plus, comme la bataillon Azov, ils en ont tiré des bénéfices et rejoint l’armée régulière. Cela ne signifie pas pour autant que toute la société Ukrainienne (ni même la majorité) soit ultra-nationaliste ou faciste. L'extrême-droite n’a fait que 4% aux dernières élections et le président ukrainien, juif et russophone a été élu à 73%. </p>
<p><br>Dans la révolte en Syrie, les djihadistes ont commencé en étant marginaux puis ont pris une importance croissante - entre autres grâce au soutien extérieur - leur permettant de s’imposer militairement aux détriments du mouvement civil et des acteurs les plus progressistes. Partout l’extrême droite (comme en France aujourd’hui sans aucune doute) est une menace pour l’extension des démocraties et de révolutions sociales.<strong> </strong>En France, cette même extrême-droite a tenté de s’imposer pendant le soulèvement des Gilets Jaunes. Et si elle a été battue, c’est par la présence des positions égalitaristes et de militant.e.s libertaires et antifascistes, et non pas par des commentateurs de salon. </p>
<p><br>Attention, défendre la résistance populaire (en Ukraine comme en Russie) face à l’invasion Russe ne revient pas non plus à être naïf.ve concernant le régime politique issu de Maïdan. On ne peut pas dire que la chute de Ianoukovitch ait découlé sur une véritable extension d’une démocratie directe et d’une société égalitariste que nous souhaitons pour la Syrie, la Russie, la France et partout dans le monde. Utilisant une expression qui nous est bien connue, certain.e.s activistes Ukrainien.e.s qualifient l'après-maïdan de “révolution volée”. Le régime Ukrainien, en plus d’accorder une place importante aux ultra-nationaliste, a été reconstruit par des acteurs, notamment des oligarques, défendant leurs intérêts économiques et politiques propres et étendant un modèle capitaliste et néo-libéral inégalitaire. Si nos connaissances restent limitées à ce sujet, il nous est difficile de croire que le régime Ukrainien n’a aucune responsabilité dans l'exacerbation des tensions avec les régions séparatistes.  </p>
<p><br>En Syrie, les révolutionnaires impliqué.e.s sur le terrain ne sont en rien privés de critiquer violemment les choix de l’opposition politique réunie à Istanbul. Nous regrettons encore son choix de n’avoir pas pris en compte les revendications légitimes de minorités comme les Kurdes. </p>
<p><br>La présence d’un régime néolibéral et de composantes fascisantes sont des ingrédients que l’on retrouve dans toutes les démocraties occidentales. Si ces adversaires de l'émancipation ne doivent pas être sous-estimés, cela ne constitue en rien une raison de ne pas défendre la résistance populaire à l’invasion. Au contraire, comme nous aurions aimé que ce soit le cas pendant la révolution syrienne : nous vous appelons à soutenir les composantes auto-organisées les plus progressistes. <br><br><strong>9. Soutenir la résistance populaire en Ukraine et en Russie. </strong>Comme l’ont prouvé les révolutions arabes, les gilets jaunes ou Maïdan, les soulèvements du XXIe siècle ne sont et ne seront pas “purs” idéologiquement. Si nous pouvons comprendre qu’il est plus confortable et galvanisant de s’identifier à des acteurs puissants (et victorieux), nous ne pouvons pas trahir nos principes élémentaires. Nous invitons la gauche radicale à retirer ses vieilles lunettes conceptuelles pour confronter ses positions théoriques au réel. C'est toujours le réel qui doit les ajuster et non le contraire. </p>
<p><br>C’est pour ces raisons qu’en Ukraine nous appelons à soutenir en priorité les initiatives qui proviennent de la base : les initiatives d’auto-défense et d’auto-organisation qui fleurissent actuellement.  On pourrait y découvrir que souvent, des gens qui s’auto-organisent peuvent défendre dans les faits les conceptions radicales de la démocratie et de la justice sociale. Même si ils.elles ne se disent pas “de gauche” ou “progressistes”. </p>
<p><br>Aussi, c<a href="https://www.revue-ballast.fr/manifeste-socialistes-et-communistes-russes-contre-la-guerre">omme l’appellent de nombreux militant.e.s russes</a>, nous pensons qu’un soulèvement populaire en Russie pourrait contribuer à faire cesser la guerre comme en 1905 et en 1917. Quand nous découvrons l’ampleur de la répression à l'œuvre en Russie depuis le début de la guerre (dizaines de milliers de manifestant.e.s emprisonné.e.s, censure des médias, coupure des réseaux sociaux et peut-être bientôt d’internet, etc.) comment ne pas souhaiter qu’une révolution aboutisse à la chute du régime. Pour arrêter, une fois pour toutes, les crimes de Poutine en Russie, en Ukraine, en Syrie et ailleurs. </p>
<p><br>C’est le cas aussi pour la Syrie où, suite à l’internationalisation du conflit, bien loin d’en vouloir aux peuples iraniens, russes ou libanais, les soulèvements de ces peuples pourraient nous faire croire à nouveau à la chute de Bachar al-Assad. </p>
<p><br>De la même façon que nous souhaitons des bouleversements radicaux et des extensions radicales de la démocratie, de la justice et de l’égalité aux États Unis, France ou tout autre pays qui basent leur puissance sur l’oppression d’autres peuples ou d’une partie de leur population. </p>
<figure>
<img src="https://cantinesyrienne.fr/media/pages/ressources/les-peuples-veulent/guerre-en-ukraine-10-enseignements-syriens/d438c424af-1646658565/290248_379634178796695_1661913435_o.jpg" alt="">

<figcaption>
La Russie et la Chine : des peuples intelligents gouvernés par des idiots. Faire chutez vos tyrans. </figcaption>
</figure>
<p><br><strong>10. Construire un nouvel internationalisme par le bas. </strong>Si nous sommes radicalement opposé.e.s à tous les impérialismes et à toutes les formes modernes du fascisme, nous pensons que nous ne pouvons pas nous limiter à des postures anti-impérialistes ou antifascistes. Si elles s’expliquent dans de nombreux contextes, elles risquent aussi de limiter le combat révolutionnaire à une vision négative et le réduire à l’état de réaction et résistance permanente. </p>
<p><br>Nous croyons que porter une proposition positive et constructive comme l’internationalisme reste indispensable. Cela signifie lier les révoltes et les combattant.e.s pour l’égalité dans le monde entier. </p>
<p><br>Une troisième voie existe entre l’OTAN ou Poutine, c’est celle de l’internationalisme d’en bas. Un internationalisme révolutionnaire doit appeler aujourd’hui à défendre la résistance populaire en Ukraine comme il devait appeler à soutenir les conseils locaux syriens, les comités de résistance au Soudan, les assemblées territoriales du Chili, les ronds points des Gilets Jaunes ou les intifadas palestiniennes.</p>
<p><br>Certes,<strong> </strong>nous vivons dans l’ombre d’un internationalisme ouvrier - appuyé sur des États, des partis, des syndicats et de grandes organisations - qui fut capable de réellement peser dans des conflits internationaux comme en Espagne en 1936, au Vietnam ou en Palestine dans les années 60-70.  </p>
<p><br>Aujourd'hui et partout dans le monde, que ce soit en Syrie, en France ou en Ukraine, nous sommes orphelins de forces émancipatrices d’ampleur, dotées de bases matérielles conséquentes. En attendant l’émergence, comme ce qui semble se jouer au Chili, d’organisations révolutionnaires s'appuyant sur les initiatives d'auto-organisation locales, nous défendons un internationalisme qui soutient les soulèvements populaires et accueille tout type d'exil. En cela aussi nous préparons le terrain d’un véritable retour de l’internationalisme, qui, espérons le, un jour, pourra à nouveau proposer, de manière audible et articulée une voie alternative aux modèles des démocraties capitalistes occidentales et à l’autoritarisme capitaliste russe ou chinois. </p>
<p><br>Une telle conception, en Syrie, aurait sûrement permis d'aider la révolution à conserver une couleur démocratique et égalitariste. Et qui sait, peut être contribuer à la victoire. </p>
<p><br>Ce n’est donc pas uniquement par principe éthique que nous sommes internationalistes mais aussi par stratégie révolutionnaire. Nous défendons donc la nécessité de créer des liens et des alliances entre les forces auto-organisées qui œuvrent pour l’émancipation de toutes et tous sans distinction.  C’est ce que nous nommons l'internationalisme par le bas, l'internationalisme des peuples.</p>
<p><br><strong>Proposition de positions au sujet de l’invasion russe en Ukraine</strong> :  </p>
<p><br>- Soutien total à la résistance populaire ukrainienne face à l'invasion russe </p>
<p>- Soutien privilégié pour les acteurs auto-organisés défendant des positions émancipatrices en Ukraine par les dons, l’aide humanitaire et la diffusion de leurs revendications</p>
<p>- Soutien aux forces progressistes anti-guerre et anti-régime en Russie et diffusion de leurs positions  </p>
<p>- Accueil des exilé.e.s ukrainien.ne.s et organisation de rencontres pour faire entendre leur voix </p>
<p>- Combat de tous les discours pro-Poutine, encore plus à gauche (La guerre en Ukraine doit être l'occasion de définitivement en finir avec cette rhétorique campiste et viriliste) </p>
<p>- Combat des discours défendant l’OTAN par idéologie</p>
<p>- Refuser le soutien aux acteurs, en Ukraine et ailleurs, qui défendent une politique ultranationaliste, xenophobe et raciste </p>
<p>- Critiques et méfiances permanentes face aux actions de l'OTAN en Ukraine et ailleurs </p>
<p>- Pressions sur les gouvernements (manifestations, actions, banderoles, tribunes, pétitions, etc.) afin de faire appliquer les revendications des acteurs auto-organisés sur le terrain <br></p>
<p>C'est peu malheureusement, mais c’est tout ce que nous pouvons proposer tant qu'il n'y aura pas de force autonome ici ou ailleurs, luttant pour l'égalité et l'émancipation, capable d'apporter un soutien économique, politique voire militaire conséquent. </p>
<p><br><em>Nous espérons sincèrement que, cette fois-ci, ces positions seront portées par le nombre. Si cela arrive, nous serons profondément heureux.ses mais nous garderons le souvenir que ce fut loin d’être le cas pour la Syrie, et que ça lui a coûté cher.  </em></p>
<p><br>La Cantine Syrienne de Montreuil et l'équipe des Peuples Veulent </p>
</article>


<hr>

<footer>
<p>
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="/david/log/" title="Accès au flux RSS"><svg class="icon icon-rss2">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-rss2"></use>
</svg> Suivre</a> •
<a href="http://larlet.com" title="Go to my English profile" data-instant><svg class="icon icon-user-tie">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-user-tie"></use>
</svg> Pro</a> •
<a href="mailto:david%40larlet.fr" title="Envoyer un courriel"><svg class="icon icon-mail">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-mail"></use>
</svg> Email</a> •
<abbr class="nowrap" title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340"><svg class="icon icon-hammer2">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-hammer2"></use>
</svg> Légal</abbr>
</p>
<template id="theme-selector">
<form>
<fieldset>
<legend><svg class="icon icon-brightness-contrast">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-brightness-contrast"></use>
</svg> Thème</legend>
<label>
<input type="radio" value="auto" name="chosen-color-scheme" checked> Auto
</label>
<label>
<input type="radio" value="dark" name="chosen-color-scheme"> Foncé
</label>
<label>
<input type="radio" value="light" name="chosen-color-scheme"> Clair
</label>
</fieldset>
</form>
</template>
</footer>
<script src="/static/david/js/instantpage-5.1.0.min.js" type="module"></script>
<script>
function loadThemeForm(templateName) {
const themeSelectorTemplate = document.querySelector(templateName)
const form = themeSelectorTemplate.content.firstElementChild
themeSelectorTemplate.replaceWith(form)

form.addEventListener('change', (e) => {
const chosenColorScheme = e.target.value
localStorage.setItem('theme', chosenColorScheme)
toggleTheme(chosenColorScheme)
})

const selectedTheme = localStorage.getItem('theme')
if (selectedTheme && selectedTheme !== 'undefined') {
form.querySelector(`[value="${selectedTheme}"]`).checked = true
}
}

const prefersColorSchemeDark = '(prefers-color-scheme: dark)'
window.addEventListener('load', () => {
let hasDarkRules = false
for (const styleSheet of Array.from(document.styleSheets)) {
let mediaRules = []
for (const cssRule of styleSheet.cssRules) {
if (cssRule.type !== CSSRule.MEDIA_RULE) {
continue
}
// WARNING: Safari does not have/supports `conditionText`.
if (cssRule.conditionText) {
if (cssRule.conditionText !== prefersColorSchemeDark) {
continue
}
} else {
if (cssRule.cssText.startsWith(prefersColorSchemeDark)) {
continue
}
}
mediaRules = mediaRules.concat(Array.from(cssRule.cssRules))
}

// WARNING: do not try to insert a Rule to a styleSheet you are
// currently iterating on, otherwise the browser will be stuck
// in a infinite loop…
for (const mediaRule of mediaRules) {
styleSheet.insertRule(mediaRule.cssText)
hasDarkRules = true
}
}
if (hasDarkRules) {
loadThemeForm('#theme-selector')
}
})
</script>
</body>
</html>

+ 90
- 0
cache/2022/ad5756e74f5c976458c42eeb9e60707e/index.md View File

@@ -0,0 +1,90 @@
title: Guerre en Ukraine : 10 enseignements syriens
url: https://cantinesyrienne.fr/ressources/les-peuples-veulent/guerre-en-ukraine-10-enseignements-syriens
hash_url: ad5756e74f5c976458c42eeb9e60707e

<p><strong>Mars 2022</strong></p>
<p>Image : Poutine ! la gloire ne se bâtit jamais sur les cadavres d'enfants, on vivra assez longtemps pour cracher sur ton histoire.</p>
<p>Cet article est publié simultanément sur <a href="https://fr.crimethinc.com/">Crimethinc.</a> et traduit en anglais <a href="https://crimethinc.com/2022/03/07/war-in-ukraine-ten-lessons-from-syria-syrian-exiles-on-how-their-experience-can-inform-resistance-to-the-invasion">ici</a>.</p>
<hr>
<p>Nous savons que cela peut sembler difficile de se positionner dans un moment comme celui-ci. Entre l’unanimité idéologique des médias dominants et les voix qui relaient sans scrupule la propagande du Kremlin, on ne sait plus qui écouter. Entre une OTAN aux mains sales et un régime Russe criminel on ne sait plus qui combattre, qui soutenir. </p>
<p><br>Nous participant.e.s et ami.e.s de la révolution syrienne souhaitons défendre une troisième voie et  proposer un point de vue basé sur les apprentissages de plus de 10 ans de soulèvement et de guerre en Syrie. </p>
<p><br>Clarifions tout de suite : nous défendons aujourd'hui encore la révolte en Syrie dans sa dimension de soulèvement populaire, démocratique et émancipateur, notamment incarnée par l’expérience des comités de coordination et des conseils locaux de la révolution. Si beaucoup l'ont oublié, nous affirmons que ni les crimes et la propagande de Bachar al-Assad ni ceux des djihadistes ne sauraient faire taire cette voix. </p>
<p><br>Dans ce qui suit, nous n’entendons pas comparer ce qui se passe dans les deux pays. Si ces deux guerres ont débuté par une révolte et si l’un des agresseurs est le même, les situations restent bien différentes. Nous comptons plutôt, à partir de nos apprentissages de la révolution et puis de la guerre en Syrie, proposer quelques pistes afin d'aider ceux et celles qui défendent sincèrement des principes émancipateurs à prendre position. </p>
<figure>
<img src="https://cantinesyrienne.fr/media/pages/ressources/les-peuples-veulent/guerre-en-ukraine-10-enseignements-syriens/1e682e36cc-1646657542/syria-russia-conflict.jpg" alt="">

<figcaption>
Les forces russes et syriennes près des affiches d'Assad et Poutine à l'est de la province d'Idlib </figcaption>
</figure>
<p><br><br><strong>1 : Écouter les voix des premier.e.s concerné.e.s par les événements.</strong> Plutôt que les experts en géopolitique, écoutons avant tout la parole de ceux et celles qui vivent la guerre et ont vécu la révolution (Maïdan 2014), écoutons ceux et celles qui souffrent du régime de Poutine, en Russie et ailleurs depuis 20 ans. Nous vous invitons à privilégier les voix des gens et des organisations défendant, sur place, des principes de démocratie directe, de féminisme et d’égalitarisme. Leurs positions en Ukraine et leurs demandes vis-à-vis de l'extérieur vous aideront à construire votre propre opinion.</p>
<p><br>Adopter cette approche vis à vis de la Syrie aurait permis de voir - et peut être de soutenir - les expériences d’auto-organisation impressionnantes et prometteuses qui ont fleuri dans tout le pays. De plus, écouter les <a href="https://fr.crimethinc.com/2022/02/15/anarchistes-et-guerre-perspectives-anti-autoritaires-en-ukraine">voix venant d’Ukraine nous rappelle</a> que toutes ces tensions ont débuté par le soulèvement de Maïdan. Ne faisons pas l’erreur de réduire la révolte populaire ukrainienne (aussi imparfaite ou “impure” soit elle) à un conflit d'intérêts entre grandes puissances comme cela a été fait à dessein pour la révolution syrienne. </p>
<p><br><strong>2 : Se méfier de la géopolitique de comptoir.</strong> S'il est certain qu’il est souhaitable de mieux comprendre les intérêts économiques, diplomatiques et militaires des grandes puissances,  se contenter d’une lecture géopolitique de la situation a tendance à déconnecter du terrain. Cela pousse les gens normaux comme vous et nous à éclipser les protagonistes ordinaires du conflit, ceux et celles qui nous ressemblent, ceux et celles à qui l’on peut s’identifier.</p>
<p>N'oublions surtout pas : ce qui va se passer avant tout, c'est que des gens vont souffrir à cause des choix de gouvernants qui prennent le monde pour un échiquier et pour un réservoir de ressources à piller.  Cette vision est celle des dominants. Elle ne devrait jamais être utilisée par les peuples qui, selon nous, devrait se concentrer sur la construction de ponts entre eux et la recherche d’intérêts communs. Cela ne signifie pas qu’il faille négliger la stratégie, mais cela implique de le faire à sa propre échelle ;  qui n'est pas, pour l'heure, de déplacer des divisions de chars ou de couper les importations de gaz. (Voir nos propositions concrètes à la fin de l’article). </p>
<p><br><strong>3 : N’accepter aucun tri entre bon et mauvais exilé.e. </strong>Disons le clairement, l'accueil des réfugié.e.s syrien.ne.s en Europe fût souvent meilleur (mais tout sauf idéal) que celui des réfugié.e.s d'Afrique subsaharienne par exemple. Les images de réfugié.e.s noir.e.s refoulé.e.s à la frontière entre l’Ukraine et la Pologne ainsi que les commentaires dans les grands médias privilégiant l'arrivée de réfugié.e.s Ukrainien.ne.s “de grande qualité” aux barbares Syriens ne sont rien d’autre que des preuves d’un racisme européen de plus en plus décomplexé. Si nous défendons un accueil inconditionnel pour les Ukrainien.ne.s qui fuient les horreurs de la guerre, nous refusons toute hiérarchisation entre les réfugié.e.s.</p>
<p><br><strong>4 : Se méfier de la position des médias mainstream</strong>. Si, comme en Syrie, ils prétendent tenir une position humaniste et progressiste, une bonne partie de ces médias risquent encore une fois de se limiter à une position victimisante et dépolitisante des Ukrainien.ne.s sur place ou en exil. On ne leur donnera la parole que pour parler de cas individuel, de fuite, de la peur des bombes, etc. C’est une position incapable de penser les Ukrainien.ne.s comme des acteurs et des actrices politiques à part entière capables d'exprimer des opinions ou des analyses politiques sur la situation dans leur propre pays. De plus, ces médias risquent de défendre une position grossièrement pro-occidentale sans nuance, profondeur historique ou explication sur les intérêts des pays occidentaux, présentés comme des défenseurs du bien, des libertés ou d’une démocratie libérale idéalisée.</p>
<p><br><strong>5 :</strong> <strong>Ne pas faire des pays occidentaux l’axe du bien</strong>. Si ce ne sont pas eux directement qui envahissent l'Ukraine, privons nous de toute naïveté concernant l’OTAN et les pays occidentaux.  Nous devons refuser à tout prix de présenter ceux-ci comme des défenseurs du “monde libre”. Rappelons, s'il le faut, que l'Occident a lui-même basé sa puissance (et continue de la faire) sur le colonialisme, l’impérialisme, l’oppression et la spoliation des richesses de centaines de peuples dans le monde entier. </p>
<p><br>Pour ne parler que du XXIe siècle, nous n'oublions bien sûr pas les désastres infligés par les invasions en Irak et en Afghanistan. Plus récemment encore, pendant les révolutions arabes de 2011, au lieu de soutenir les composantes démocratiques et progressistes, l'Occident s’est soucié essentiellement de maintenir sa domination et ses intérêts économiques. Dans le même temps, il continue à vendre des armes et à entretenir des relations privilégiées avec des dictatures arabes et des monarchies du Golfe. La France y a même ajouté, avec l’intervention en Libye le mensonge d’une guerre pour des motifs économiques sous couvert de soutien au combat pour la démocratie. </p>
<p><br>En plus de son rôle à l’international, la situation à l’intérieur même de ces pays ne cesse de se dégrader : montée de l’autoritarisme, de la surveillance, des inégalités, et surtout du racisme.</p>
<p> <br>Aujourd’hui, si nous pensons que le régime de Poutine représente une menace plus importante pour l'autodétermination des peuples, ce n’est pas que les pays occidentaux seraient devenus subitement “gentils” mais parce que les puissances occidentales n’ont actuellement plus autant de moyens pour maintenir leur domination et leur hégémonie. Nous restons bien entendu très méfiants sur cette hypothèse car si Poutine est défait par les pays occidentaux, cela pourrait contribuer à leur redonner une vraie puissance. </p>
<p><br>Nous conseillons ainsi aux Ukrainien.ne.s de ne pas compter sur la “communauté internationale” ou les “Nations Unies” qui, comme en Syrie, risquent de briller par leur hypocrisie et faire croire en des chimères. </p>
<p></p>
<figure>
<img src="https://cantinesyrienne.fr/media/pages/ressources/les-peuples-veulent/guerre-en-ukraine-10-enseignements-syriens/473be3845a-1646658087/dkju3gvx0aa-xfj.jpg" alt="">

<figcaption>
Traduction de la phrase en arabe : "Le temps de la masculinité et les hommes" </figcaption>
</figure>
<p><br><br><strong>6 :  Combattre tous les impérialismes ! </strong>Le “campisme” :  doctrine d’une autre époque qui consistait  pendant la guerre froide à soutenir coûte que coûte l’URSS face aux États capitalistes et impérialistes pousse aujourd'hui encore, une partie de la gauche radicale à soutenir la Russie de Poutine en Ukraine ou à relativiser la guerre en cours. Comme ils l’ont fait en Syrie, ils utilisent le prétexte que les régimes russe ou syrien incarneraient la lutte contre l'impérialisme occidental. Malheureusement, cet anti-impérialisme manichéen, essentiellement théorique, refuse de voir l’impérialisme chez d'autres acteurs que l’Occident. Pourtant il faudra bien qualifier ce que les régimes russes, chinois ou même iranien font depuis des années : étendre leur domination politique et économique dans certaines régions en dépossédant les populations locales de leur auto-détermination. Qu’ils choisissent le mot qu’ils veulent si “impérialisme” leur semble inadéquat, mais nous n'accepterons jamais l'euphémisation de la violence et de la domination infligées aux populations au nom d’une pseudo précision théorique. </p>
<p><br>Plus grave encore, cette position pousse cette gauche à se faire le relais de la propagande de ces régimes jusqu'à virer dans le négationnisme. En parlant de “coup d'État” pour qualifier Maïdan ou en niant les crimes de guerre perpétrés par l’armée Russes en Syrie. Cette gauche est allée jusqu’à réfuter l’utilisation de gaz sarin par le régime d’Assad, s'appuyant sur une méfiance (souvent légitime) envers les grands médias pour diffuser ces mensonges.  </p>
<p><br>C’est une attitude méprisable et irresponsable quand l’on sait que la montée du conspirationnisme ne favorise jamais le camp de l’émancipation mais bien l'extrême droite et le racisme. Sur la guerre en Ukraine, ces anti-impérialistes imbéciles, dont certains se revendiquant pourtant de l’anti-facisme, sont les alliés de circonstance d'une grande partie de l'extrême droite. </p>
<p><br>En Syrie, chauffés à blanc par des fantasmes supremacistes et des rêves de croisade contre l’islam, la droite radicale avait déjà défendu Poutine et le régime Syrien pour leurs prétendues actions face au djihadisme. Et ceci sans jamais comprendre la responsabilité du régime d’Assad dans la montée des djihadistes en Syrie.  </p>
<p></p>
<p><br><strong>7 : Ne pas renvoyer dos à dos l’Ukraine et la Russie.</strong> En Ukraine, l’identité de l’agresseur est connue de tous.tes. Si l’offensive de Poutine répond quelque part à la pression de l'OTAN, elle est avant tout la poursuite d’une offensive impériale et contre-révolutionnaire. Après avoir envahi la Crimée, après avoir aidé à écraser les soulèvements en Syrie (2015-2022), Biélorussie (2020) et au Kazakhstan (2022), Vladimir Poutine ne tolère plus ce vent de contestation - incarné par la destitution du président pro-russe pendant Maïdan - au sein de pays sous son influence. Il souhaite écraser toute velléité émancipatrice fragilisant son pouvoir.</p>
<p><br>En Syrie aussi, le responsable direct de la guerre ne fait aucun doute. Le régime Syrien de Bachar al-Assad, en ordonnant à la police de tirer, d’emprisonner et de torturer les manifestant.e.s dès les premiers jours de contestation décida lui-même de déclencher une guerre contre la population. Nous aimerions (et aurions aimé) que les personnes qui défendent la liberté et l’égalité soient unanimes dans leur prise de position contre ces dictateurs qui mènent des guerres contre les peuples. </p>
<p><br>Si nous comprenons et rejoignons l’appel qui demande la fin de la guerre, nous insistons qu’il faut le faire sans ambiguïté sur l'identité de l’agresseur. Ni en Ukraine ni en Syrie ni nulle part ailleurs, il n’est possible de reprocher aux gens ordinaires le fait de prendre les armes pour essayer de défendre leur vie et celles de leur famille.   </p>
<p><br></p>
<figure>
<img src="https://cantinesyrienne.fr/media/pages/ressources/les-peuples-veulent/guerre-en-ukraine-10-enseignements-syriens/5af870a2dc-1646657818/1276274_522233771203401_453981693_o.jpg" alt="">

<figcaption>
Aux militants anti-guerre ! SVP soutenez l'intervention, nous sommes anti-guerre, nous sommes contre Assad qui tuent nos enfants </figcaption>
</figure>
<p><br>Plus généralement, nous conseillons aux gens qui ne savent pas ce qu’est une dictature (même si les pays occidentaux deviennent de plus en plus ouvertement autoritaire) ou d'être bombardé.e, de s’abstenir de dire aux Ukrainien.ne.s - comme certains l’ont dit déjà aux Syrien.ne.s ou aux Hongkongais.es - de ne pas solliciter l’aide de l’Occident ou de ne pas souhaiter la démocratie libérale ou représentative comme système politique a minima. Beaucoup de ces gens, déjà lucides sur les imperfections de ces systèmes politiques ont comme priorité, non pas de tenir un positionnement politique irréprochable, mais plutôt de survivre aux bombardements du lendemain ou encore de ne pas finir dans un pays où un mot de travers peut valoir 20 ans de prison. Tenir ce genre de discours démontre de la volonté d’imposer son point de vue théorique à un contexte qui n'est pas le sien. Cela relève d'une vraie déconnexion avec le terrain et d’un privilège bien occidental. </p>
<p><br>Ecoutons plutôt les mots des ami.es ukirainien.ne.s qui la semaine dernière affirment “<a href="https://fr.crimethinc.com/2022/02/15/anarchistes-et-guerre-perspectives-anti-autoritaires-en-ukraine">Nous sommes fermement convaincus que la république la plus imparfaite est mille fois meilleure que la monarchie la plus éclairée</a>”. </p>
<p><br><strong>8 : Comprendre que la société Ukrainienne, comme en Syrie, comme en France, est traversée de différents courants. </strong>Nous connaissons bien le procédé qui consiste à désigner une grande menace pour effrayer les soutiens potentiels. La réthorique du “terrorisme islamiste” en Syrie utilisé par Bachar al-Assad dès les premiers jours de la révolution, aujourd’hui “le nazime” et “l’ultra-nationalisme” brandi par Poutine et ses alliés. <br></p>
<p>Si nous pensons que cette propagande est volontairement exagérée et qu’il ne faut en rien la relayer en l’état, l’expérience en Syrie pousse à ne pas sous-estimer les composantes réactionnaires des mouvements populaires. </p>
<p><br>En Ukraine, des nationalistes Ukrainiens, parfois fascistes, ont eu un rôle important dans les manifestations de Maïdan et dans la guerre contre la Russie qui s’en est suivie. De plus, comme la bataillon Azov, ils en ont tiré des bénéfices et rejoint l’armée régulière. Cela ne signifie pas pour autant que toute la société Ukrainienne (ni même la majorité) soit ultra-nationaliste ou faciste. L'extrême-droite n’a fait que 4% aux dernières élections et le président ukrainien, juif et russophone a été élu à 73%. </p>
<p><br>Dans la révolte en Syrie, les djihadistes ont commencé en étant marginaux puis ont pris une importance croissante - entre autres grâce au soutien extérieur - leur permettant de s’imposer militairement aux détriments du mouvement civil et des acteurs les plus progressistes. Partout l’extrême droite (comme en France aujourd’hui sans aucune doute) est une menace pour l’extension des démocraties et de révolutions sociales.<strong> </strong>En France, cette même extrême-droite a tenté de s’imposer pendant le soulèvement des Gilets Jaunes. Et si elle a été battue, c’est par la présence des positions égalitaristes et de militant.e.s libertaires et antifascistes, et non pas par des commentateurs de salon. </p>
<p><br>Attention, défendre la résistance populaire (en Ukraine comme en Russie) face à l’invasion Russe ne revient pas non plus à être naïf.ve concernant le régime politique issu de Maïdan. On ne peut pas dire que la chute de Ianoukovitch ait découlé sur une véritable extension d’une démocratie directe et d’une société égalitariste que nous souhaitons pour la Syrie, la Russie, la France et partout dans le monde. Utilisant une expression qui nous est bien connue, certain.e.s activistes Ukrainien.e.s qualifient l'après-maïdan de “révolution volée”. Le régime Ukrainien, en plus d’accorder une place importante aux ultra-nationaliste, a été reconstruit par des acteurs, notamment des oligarques, défendant leurs intérêts économiques et politiques propres et étendant un modèle capitaliste et néo-libéral inégalitaire. Si nos connaissances restent limitées à ce sujet, il nous est difficile de croire que le régime Ukrainien n’a aucune responsabilité dans l'exacerbation des tensions avec les régions séparatistes.  </p>
<p><br>En Syrie, les révolutionnaires impliqué.e.s sur le terrain ne sont en rien privés de critiquer violemment les choix de l’opposition politique réunie à Istanbul. Nous regrettons encore son choix de n’avoir pas pris en compte les revendications légitimes de minorités comme les Kurdes. </p>
<p><br>La présence d’un régime néolibéral et de composantes fascisantes sont des ingrédients que l’on retrouve dans toutes les démocraties occidentales. Si ces adversaires de l'émancipation ne doivent pas être sous-estimés, cela ne constitue en rien une raison de ne pas défendre la résistance populaire à l’invasion. Au contraire, comme nous aurions aimé que ce soit le cas pendant la révolution syrienne : nous vous appelons à soutenir les composantes auto-organisées les plus progressistes. <br><br><strong>9. Soutenir la résistance populaire en Ukraine et en Russie. </strong>Comme l’ont prouvé les révolutions arabes, les gilets jaunes ou Maïdan, les soulèvements du XXIe siècle ne sont et ne seront pas “purs” idéologiquement. Si nous pouvons comprendre qu’il est plus confortable et galvanisant de s’identifier à des acteurs puissants (et victorieux), nous ne pouvons pas trahir nos principes élémentaires. Nous invitons la gauche radicale à retirer ses vieilles lunettes conceptuelles pour confronter ses positions théoriques au réel. C'est toujours le réel qui doit les ajuster et non le contraire. </p>
<p><br>C’est pour ces raisons qu’en Ukraine nous appelons à soutenir en priorité les initiatives qui proviennent de la base : les initiatives d’auto-défense et d’auto-organisation qui fleurissent actuellement.  On pourrait y découvrir que souvent, des gens qui s’auto-organisent peuvent défendre dans les faits les conceptions radicales de la démocratie et de la justice sociale. Même si ils.elles ne se disent pas “de gauche” ou “progressistes”. </p>
<p><br>Aussi, c<a href="https://www.revue-ballast.fr/manifeste-socialistes-et-communistes-russes-contre-la-guerre">omme l’appellent de nombreux militant.e.s russes</a>, nous pensons qu’un soulèvement populaire en Russie pourrait contribuer à faire cesser la guerre comme en 1905 et en 1917. Quand nous découvrons l’ampleur de la répression à l'œuvre en Russie depuis le début de la guerre (dizaines de milliers de manifestant.e.s emprisonné.e.s, censure des médias, coupure des réseaux sociaux et peut-être bientôt d’internet, etc.) comment ne pas souhaiter qu’une révolution aboutisse à la chute du régime. Pour arrêter, une fois pour toutes, les crimes de Poutine en Russie, en Ukraine, en Syrie et ailleurs. </p>
<p><br>C’est le cas aussi pour la Syrie où, suite à l’internationalisation du conflit, bien loin d’en vouloir aux peuples iraniens, russes ou libanais, les soulèvements de ces peuples pourraient nous faire croire à nouveau à la chute de Bachar al-Assad. </p>
<p><br>De la même façon que nous souhaitons des bouleversements radicaux et des extensions radicales de la démocratie, de la justice et de l’égalité aux États Unis, France ou tout autre pays qui basent leur puissance sur l’oppression d’autres peuples ou d’une partie de leur population. </p>
<figure>
<img src="https://cantinesyrienne.fr/media/pages/ressources/les-peuples-veulent/guerre-en-ukraine-10-enseignements-syriens/d438c424af-1646658565/290248_379634178796695_1661913435_o.jpg" alt="">

<figcaption>
La Russie et la Chine : des peuples intelligents gouvernés par des idiots. Faire chutez vos tyrans. </figcaption>
</figure>
<p><br><strong>10. Construire un nouvel internationalisme par le bas. </strong>Si nous sommes radicalement opposé.e.s à tous les impérialismes et à toutes les formes modernes du fascisme, nous pensons que nous ne pouvons pas nous limiter à des postures anti-impérialistes ou antifascistes. Si elles s’expliquent dans de nombreux contextes, elles risquent aussi de limiter le combat révolutionnaire à une vision négative et le réduire à l’état de réaction et résistance permanente. </p>
<p><br>Nous croyons que porter une proposition positive et constructive comme l’internationalisme reste indispensable. Cela signifie lier les révoltes et les combattant.e.s pour l’égalité dans le monde entier. </p>
<p><br>Une troisième voie existe entre l’OTAN ou Poutine, c’est celle de l’internationalisme d’en bas. Un internationalisme révolutionnaire doit appeler aujourd’hui à défendre la résistance populaire en Ukraine comme il devait appeler à soutenir les conseils locaux syriens, les comités de résistance au Soudan, les assemblées territoriales du Chili, les ronds points des Gilets Jaunes ou les intifadas palestiniennes.</p>
<p><br>Certes,<strong> </strong>nous vivons dans l’ombre d’un internationalisme ouvrier - appuyé sur des États, des partis, des syndicats et de grandes organisations - qui fut capable de réellement peser dans des conflits internationaux comme en Espagne en 1936, au Vietnam ou en Palestine dans les années 60-70.  </p>
<p><br>Aujourd'hui et partout dans le monde, que ce soit en Syrie, en France ou en Ukraine, nous sommes orphelins de forces émancipatrices d’ampleur, dotées de bases matérielles conséquentes. En attendant l’émergence, comme ce qui semble se jouer au Chili, d’organisations révolutionnaires s'appuyant sur les initiatives d'auto-organisation locales, nous défendons un internationalisme qui soutient les soulèvements populaires et accueille tout type d'exil. En cela aussi nous préparons le terrain d’un véritable retour de l’internationalisme, qui, espérons le, un jour, pourra à nouveau proposer, de manière audible et articulée une voie alternative aux modèles des démocraties capitalistes occidentales et à l’autoritarisme capitaliste russe ou chinois. </p>
<p><br>Une telle conception, en Syrie, aurait sûrement permis d'aider la révolution à conserver une couleur démocratique et égalitariste. Et qui sait, peut être contribuer à la victoire. </p>
<p><br>Ce n’est donc pas uniquement par principe éthique que nous sommes internationalistes mais aussi par stratégie révolutionnaire. Nous défendons donc la nécessité de créer des liens et des alliances entre les forces auto-organisées qui œuvrent pour l’émancipation de toutes et tous sans distinction.  C’est ce que nous nommons l'internationalisme par le bas, l'internationalisme des peuples.</p>
<p><br><strong>Proposition de positions au sujet de l’invasion russe en Ukraine</strong> :  </p>
<p><br>- Soutien total à la résistance populaire ukrainienne face à l'invasion russe </p>
<p>- Soutien privilégié pour les acteurs auto-organisés défendant des positions émancipatrices en Ukraine par les dons, l’aide humanitaire et la diffusion de leurs revendications</p>
<p>- Soutien aux forces progressistes anti-guerre et anti-régime en Russie et diffusion de leurs positions  </p>
<p>- Accueil des exilé.e.s ukrainien.ne.s et organisation de rencontres pour faire entendre leur voix </p>
<p>- Combat de tous les discours pro-Poutine, encore plus à gauche (La guerre en Ukraine doit être l'occasion de définitivement en finir avec cette rhétorique campiste et viriliste) </p>
<p>- Combat des discours défendant l’OTAN par idéologie</p>
<p>- Refuser le soutien aux acteurs, en Ukraine et ailleurs, qui défendent une politique ultranationaliste, xenophobe et raciste </p>
<p>- Critiques et méfiances permanentes face aux actions de l'OTAN en Ukraine et ailleurs </p>
<p>- Pressions sur les gouvernements (manifestations, actions, banderoles, tribunes, pétitions, etc.) afin de faire appliquer les revendications des acteurs auto-organisés sur le terrain <br></p>
<p>C'est peu malheureusement, mais c’est tout ce que nous pouvons proposer tant qu'il n'y aura pas de force autonome ici ou ailleurs, luttant pour l'égalité et l'émancipation, capable d'apporter un soutien économique, politique voire militaire conséquent. </p>
<p><br><em>Nous espérons sincèrement que, cette fois-ci, ces positions seront portées par le nombre. Si cela arrive, nous serons profondément heureux.ses mais nous garderons le souvenir que ce fut loin d’être le cas pour la Syrie, et que ça lui a coûté cher.  </em></p>
<p><br>La Cantine Syrienne de Montreuil et l'équipe des Peuples Veulent </p>

+ 175
- 0
cache/2022/ae3792ebced6f8b2b12b04723d982462/index.html View File

@@ -0,0 +1,175 @@
<!doctype html><!-- This is a valid HTML5 document. -->
<!-- Screen readers, SEO, extensions and so on. -->
<html lang="fr">
<!-- Has to be within the first 1024 bytes, hence before the `title` element
See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
<meta charset="utf-8">
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
<!-- The viewport meta is quite crowded and we are responsible for that.
See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
<meta name="viewport" content="width=device-width,initial-scale=1">
<!-- Required to make a valid HTML5 document. -->
<title>☕️ Journal : Pluriversité (archive) — David Larlet</title>
<meta name="description" content="Publication mise en cache pour en conserver une trace.">
<!-- That good ol' feed, subscribe :). -->
<link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/">
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png">
<link rel="manifest" href="/static/david/icons2/site.webmanifest">
<link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c">
<link rel="shortcut icon" href="/static/david/icons2/favicon.ico">
<meta name="msapplication-TileColor" content="#f7f7f7">
<meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml">
<meta name="theme-color" content="#f7f7f7" media="(prefers-color-scheme: light)">
<meta name="theme-color" content="#272727" media="(prefers-color-scheme: dark)">
<!-- Documented, feel free to shoot an email. -->
<link rel="stylesheet" href="/static/david/css/style_2021-01-20.css">
<!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. -->
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<script>
function toggleTheme(themeName) {
document.documentElement.classList.toggle(
'forced-dark',
themeName === 'dark'
)
document.documentElement.classList.toggle(
'forced-light',
themeName === 'light'
)
}
const selectedTheme = localStorage.getItem('theme')
if (selectedTheme !== 'undefined') {
toggleTheme(selectedTheme)
}
</script>

<meta name="robots" content="noindex, nofollow">
<meta content="origin-when-cross-origin" name="referrer">
<!-- Canonical URL for SEO purposes -->
<link rel="canonical" href="https://thom4.net/2022/03/06/pluriversite/">

<body class="remarkdown h1-underline h2-underline h3-underline em-underscore hr-center ul-star pre-tick" data-instant-intensity="viewport-all">


<article>
<header>
<h1>☕️ Journal : Pluriversité</h1>
</header>
<nav>
<p class="center">
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="https://thom4.net/2022/03/06/pluriversite/" title="Lien vers le contenu original">Source originale</a>
</p>
</nav>
<hr>
<p>En lisant <a target="_blank" rel="noopener" href="https://editionsdaronnes.fr/product/decolonialite-privilege/">Décolonialité &amp; Privilège</a>, je suis tombé sur le terme de <mark>pluriversité</mark>.</p>
<p>Je l’interprète en contre-pied de l’universalité — ce qui est normal d’un point de vue “neutre”, pour tous‧tes. Donc les personnes qui ont le pouvoir de l’énoncer pour les autres.</p>
<p>J’aime cette notion d’<strong>universalités plurielles</strong>, composées de multiples réalités, comme autant de facettes d’un même objet.</p>
<p>C’est un paradigme utilisé en <strong>entrainement mental</strong> — complexifier une situation et représenter les points de vue (viser la 3D° plutôt que de simplifier les choses (écraser en 2D).</p>
</article>


<hr>

<footer>
<p>
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="/david/log/" title="Accès au flux RSS"><svg class="icon icon-rss2">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-rss2"></use>
</svg> Suivre</a> •
<a href="http://larlet.com" title="Go to my English profile" data-instant><svg class="icon icon-user-tie">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-user-tie"></use>
</svg> Pro</a> •
<a href="mailto:david%40larlet.fr" title="Envoyer un courriel"><svg class="icon icon-mail">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-mail"></use>
</svg> Email</a> •
<abbr class="nowrap" title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340"><svg class="icon icon-hammer2">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-hammer2"></use>
</svg> Légal</abbr>
</p>
<template id="theme-selector">
<form>
<fieldset>
<legend><svg class="icon icon-brightness-contrast">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-brightness-contrast"></use>
</svg> Thème</legend>
<label>
<input type="radio" value="auto" name="chosen-color-scheme" checked> Auto
</label>
<label>
<input type="radio" value="dark" name="chosen-color-scheme"> Foncé
</label>
<label>
<input type="radio" value="light" name="chosen-color-scheme"> Clair
</label>
</fieldset>
</form>
</template>
</footer>
<script src="/static/david/js/instantpage-5.1.0.min.js" type="module"></script>
<script>
function loadThemeForm(templateName) {
const themeSelectorTemplate = document.querySelector(templateName)
const form = themeSelectorTemplate.content.firstElementChild
themeSelectorTemplate.replaceWith(form)

form.addEventListener('change', (e) => {
const chosenColorScheme = e.target.value
localStorage.setItem('theme', chosenColorScheme)
toggleTheme(chosenColorScheme)
})

const selectedTheme = localStorage.getItem('theme')
if (selectedTheme && selectedTheme !== 'undefined') {
form.querySelector(`[value="${selectedTheme}"]`).checked = true
}
}

const prefersColorSchemeDark = '(prefers-color-scheme: dark)'
window.addEventListener('load', () => {
let hasDarkRules = false
for (const styleSheet of Array.from(document.styleSheets)) {
let mediaRules = []
for (const cssRule of styleSheet.cssRules) {
if (cssRule.type !== CSSRule.MEDIA_RULE) {
continue
}
// WARNING: Safari does not have/supports `conditionText`.
if (cssRule.conditionText) {
if (cssRule.conditionText !== prefersColorSchemeDark) {
continue
}
} else {
if (cssRule.cssText.startsWith(prefersColorSchemeDark)) {
continue
}
}
mediaRules = mediaRules.concat(Array.from(cssRule.cssRules))
}

// WARNING: do not try to insert a Rule to a styleSheet you are
// currently iterating on, otherwise the browser will be stuck
// in a infinite loop…
for (const mediaRule of mediaRules) {
styleSheet.insertRule(mediaRule.cssText)
hasDarkRules = true
}
}
if (hasDarkRules) {
loadThemeForm('#theme-selector')
}
})
</script>
</body>
</html>

+ 8
- 0
cache/2022/ae3792ebced6f8b2b12b04723d982462/index.md View File

@@ -0,0 +1,8 @@
title: ☕️ Journal : Pluriversité
url: https://thom4.net/2022/03/06/pluriversite/
hash_url: ae3792ebced6f8b2b12b04723d982462

<p>En lisant <a target="_blank" rel="noopener" href="https://editionsdaronnes.fr/product/decolonialite-privilege/">Décolonialité &amp; Privilège</a>, je suis tombé sur le terme de <mark>pluriversité</mark>.</p>
<p>Je l’interprète en contre-pied de l’universalité — ce qui est normal d’un point de vue “neutre”, pour tous‧tes. Donc les personnes qui ont le pouvoir de l’énoncer pour les autres.</p>
<p>J’aime cette notion d’<strong>universalités plurielles</strong>, composées de multiples réalités, comme autant de facettes d’un même objet.</p>
<p>C’est un paradigme utilisé en <strong>entrainement mental</strong> — complexifier une situation et représenter les points de vue (viser la 3D° plutôt que de simplifier les choses (écraser en 2D).</p>

+ 656
- 0
cache/2022/b17f8ac80615c86cade89dd81c8aa50b/index.html
File diff suppressed because it is too large
View File


+ 492
- 0
cache/2022/b17f8ac80615c86cade89dd81c8aa50b/index.md
File diff suppressed because it is too large
View File


+ 342
- 0
cache/2022/e8d6bd5b11ae399009cf9258869be09c/index.html View File

@@ -0,0 +1,342 @@
<!doctype html><!-- This is a valid HTML5 document. -->
<!-- Screen readers, SEO, extensions and so on. -->
<html lang="fr">
<!-- Has to be within the first 1024 bytes, hence before the `title` element
See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
<meta charset="utf-8">
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
<!-- The viewport meta is quite crowded and we are responsible for that.
See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
<meta name="viewport" content="width=device-width,initial-scale=1">
<!-- Required to make a valid HTML5 document. -->
<title>The Asymmetry of Open Source (archive) — David Larlet</title>
<meta name="description" content="Publication mise en cache pour en conserver une trace.">
<!-- That good ol' feed, subscribe :). -->
<link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/">
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png">
<link rel="manifest" href="/static/david/icons2/site.webmanifest">
<link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c">
<link rel="shortcut icon" href="/static/david/icons2/favicon.ico">
<meta name="msapplication-TileColor" content="#f7f7f7">
<meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml">
<meta name="theme-color" content="#f7f7f7" media="(prefers-color-scheme: light)">
<meta name="theme-color" content="#272727" media="(prefers-color-scheme: dark)">
<!-- Documented, feel free to shoot an email. -->
<link rel="stylesheet" href="/static/david/css/style_2021-01-20.css">
<!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. -->
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<script>
function toggleTheme(themeName) {
document.documentElement.classList.toggle(
'forced-dark',
themeName === 'dark'
)
document.documentElement.classList.toggle(
'forced-light',
themeName === 'light'
)
}
const selectedTheme = localStorage.getItem('theme')
if (selectedTheme !== 'undefined') {
toggleTheme(selectedTheme)
}
</script>

<meta name="robots" content="noindex, nofollow">
<meta content="origin-when-cross-origin" name="referrer">
<!-- Canonical URL for SEO purposes -->
<link rel="canonical" href="https://matt.life/writing/the-asymmetry-of-open-source">

<body class="remarkdown h1-underline h2-underline h3-underline em-underscore hr-center ul-star pre-tick" data-instant-intensity="viewport-all">


<article>
<header>
<h1>The Asymmetry of Open Source</h1>
</header>
<nav>
<p class="center">
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="https://matt.life/writing/the-asymmetry-of-open-source" title="Lien vers le contenu original">Source originale</a>
</p>
</nav>
<hr>
<p><em><strong>Users need open source projects, but open source projects do not need users.</strong></em></p>
<p>That asymmetry is, I believe, at the crux of the open source sustainability problem. We all use open source projects either directly or indirectly. But projects do not need us. Of course, projects need users to create rich and active communities, collaborate on code, and contribute in other ways; but those are optional components, and projects can absolutely do what they want in a vacuum, ignore their users, or even abandon them altogether. Ultimately, project developers do not need users in order to write code and put it on the Internet.</p>
<p>With the recent revival of the discussion about sustaining open source spurred on by multiple severe CVEs in a popular logging library, and with so many hot takes clamoring for more funding—some calling on companies, others on maintainers—I wanted to write about the problem and its solutions more wholistically, as I have spent many years thinking about this from my own experience with both failing and succeeding… a perspective that I hope some of you will find helpful.</p>
<p><strong>I develop the <a href="https://caddyserver.com">Caddy web server</a>, and I rely on open source sponsorships for my living. To be part of a more secure and reliable Internet, have your employer <a href="https://github.com/sponsors/mholt">sponsor me (mholt) on GitHub</a>!</strong></p>

<hr>
<p>Open source work comes in different flavors. On one spectrum, it's either your hobby or your job. As a hobby, open source is less about funding and more about personal interest. Donations or sponsorships are nice encouragement to keep going, but the money isn't for the nights and weekends, it's for the warm fuzzies. It's a nice feeling to have your lunch paid for, or to receive a thank-you note with a donation. (I might add, too, that "warm fuzzies" <em>do</em> matter and are valid rewards in volunteer open source efforts. There's nothing wrong with inviting donations to stay motivated.) But your livelihood is sustained through a separate day job. Volunteer open source has given us the majority of all open source projects, including some fairly popular ones like restic and gogs.</p>
<p>As a job, open source can generally be sustained by two models:</p>
<ul>
<li>
<p><strong>Serendipitous:</strong> Open source is your job, but not your income. Your livelihood is sustained by other means. For example, your salary comes from a company that sells other products or services to make payroll, but your job description happens to consist of doing open source.</p>
</li>
<li>
<p><strong>Reliance:</strong> Open source is your job and your income. As the primary source of revenue, it's how you pay the bills. Whether you work for a company or for yourself, the project(s) must be sustainable to the degree you rely upon it for income. If you lost the income from open source, you'd need to find other work.</p>
</li>
</ul>
<p>Serendipitous open source is great; it's how we got nice things like Zstandard, VS Code, Android, and Go, but also makes up only a minority of financed projects. Reliant open source is the majority of financed projects by far, and has yielded projects like Homebrew, curl, OpenSSL, Vue.js, rclone, Caddy, and countless others.</p>
<p>Reliant developers pay their bills from free software. And therein lies the problem that is primarily what this article is about. If you're only serendipitously working on open source, you don't have the same pressures to survive as reliant developers, but we have another special role for you.</p>
<p>Serendipitous open sourcers are the proof: proof that companies will pay for open source development (even if being open source is just a coincidence or side-effect). You seldom hear complaints about quality of life with serendipitous open source projects. That's because that model works. Being paid to work on open source is the obvious solution to funding open source, and is often the crucial missing piece of the reliance model as well. The hard question is, if you're not paid by your company to work on open source, where does the money come from when the software is free? This seems futile, but there is hope.</p>
<h1 id="boundaries">Boundaries</h1>
<p>When you hear rallying cries to fund open source, or complaints that open source maintainers are overburdened and under-thanked, it's usually due to the misapplication of healthy open source principles. With liberal licenses, open source projects grant a lot of freedom, and that means it's easy for the relationship between maintainers and users to form a toxic imbalance if they aren't both careful and vigilant. Just like healthy personal relationships, healthy open source relationships establish clear boundaries and exhibit mutual respect to succeed.</p>
<p>With proper boundaries, a healthier, more helpful community can be fostered; developers and maintainers won't be over-burdened, companies and other users still get what they need, and expectations and requirements are satisfied on both sides. Establishing boundaries does not have to conflict with the freedoms granted from liberal licenses. And crucially, boundaries can be established without switching licenses.</p>
<p>Too often, we often talk about what open source licenses grant the users. Instead, we should place equal emphasis on what open source licenses grant the developers.</p>
<p>The first thing to consider is that the developers count as users. That means you can use your own project commercially! Think about that. You also have rights to distribute and modify your software, and you don't have to do that for free. And if you're the owner of the project, you are exempt from any restrictive license terms such as stating changes, disclosing source, retaining copyright, or not using the trademark. (Why? Because you used your ownership rights to endow the project with a license in the first place. You own it, so you set the terms.)</p>
<p>However, there is a delicate accord here. Open source is not entitled to funding. Just because you produced something useful does not mean anyone owes you money, especially with a license that says "Permission is hereby granted, free of charge." Of course, money has its place—and it <strong>does</strong> have a place in open source—but there is no implied contract that the code you wrote has to be paid for.</p>
<p>The converse is true as well: companies are not entitled to open source projects. Let me explain this one as it can be misinterpreted. Yes, open source licenses literally give companies a "title" to use the project for their capitalist purposes for free. However, they are not entitled to expect the same things from open source software that they'd get from commercial products. Almost all OSS licenses come with significant caveats that companies should be aware of; for example in the Apache 2.0 license:</p>
<blockquote>
<p>Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.</p>
</blockquote>
<p>And similarly in the MIT license:</p>
<blockquote>
<p>THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.</p>
</blockquote>
<p>These sections should make companies nervous, because it means they need to assume full responsibility when relying on software in their multi-million-dollar business that was probably developed by a tired young parent or college student who didn't get enough sleep.</p>
<p>In fact, proprietary software licenses often come with terms like these too. But companies are willing to pay a premium for them anyway because they know that even though the vendor is legally protected, they have access to expertise and services that effectively act like a warranty.</p>
<p>When using open source software, companies must bring their own expertise to know that the software is right for their needs. And if they're not sure? They can pay for a consultation. A company must be prepared to not only file bugs, but fix them too. They must have the means and know-how to implement a feature. Why? Because open source software is "provided as-is." They are on their own unless they pay someone for what they need. The risks of faulting here may be catastrophic to otherwise-successful businesses.</p>
<p>Healthy boundaries for a company might be:</p>
<ul>
<li>We do not allow open source software to inhibit our business by investing in:
<ul>
<li>a proper assessment of a project to ensure it meets our needs.</li>
<li>expert consultation or relevant hiring to integrate the software.</li>
<li>adequate support services.</li>
<li>ongoing development and maintenance of the software.</li>
</ul>
</li>
<li>We own our requirements, standards, or practices and do not impose them onto open source maintainers or developers—even implicitly.</li>
<li>We examine our dependency tree for subtly crucial components that may be underfunded or unmaintained, and either invest in them or change our stack.</li>
<li>If open source software is crucial to our business or is used in a critical environment, we strive to establish a relationship with the developers so they can be aware of the important use case. We do not assume they will cater to our use case simply because it is an important one. We offer to support them so they can support us.</li>
<li>We either don't use projects that don't meet our requirements, or we invest in it to meet specification.</li>
</ul>
<p>As you can see, boundaries are about asserting who owns and controls the business, and what companies will allow to happen to their business. A healthy boundary doesn't allow the blights of volunteer projects to negatively impact their business, nor does it take without giving. Standing by these boundaries may require virtuous and stubborn employees at multiple levels within the company. I urge you to be one of them.</p>
<p>Healthy boundaries for maintainers and project owners might be:</p>
<ul>
<li>I'm doing this project for me.</li>
<li>I don't implement features or incorporate changes I don't want.</li>
<li>I reject changes that I think are not a good fit for the project.</li>
<li>Donations are not contractual.</li>
<li>I only help when I can or want to.</li>
<li>There's no hurry for me to get around to issues or PRs.</li>
<li>Users can help each other; I don't have to do it all.</li>
<li>I only give help privately if I'm being paid or sponsored.</li>
<li>I don't accept donations or sponsorships.
<ul>
<li>To avoid feeling pressure (it's normal to feel pressure even if it's not warranted)</li>
<li>Or any other reason! (or no reason at all; it's okay)</li>
</ul>
</li>
</ul>
<p>As I learned from unpopular decisions with the Caddy project, hundreds of voices in a single day can feel very heavy. These kinds of boundaries can help prevent being steamrolled by user demands. Stick by them.</p>
<p>Here's an example of a boundary I set as the Caddy project grew: I decided that I could not afford to provide support in private channels for free. We have <a href="https://caddy.community">a forum</a> where people can request help, but I am not obligated to respond to help requests there; because it's a public forum, I leave that mainly up to the community and chime in when I am able. If someone emails me with questions, my general rule is to send them my sponsorship plans and consulting rates along with a link to the forum if they prefer to have volunteers to help them instead. In my experience, people have respected this boundary and I've formed some good relationships this way.</p>
<p>Without boundaries, companies may use an open source project extensively with requirements that the project is not suited for, demand a and have expectations that the maintainers will not or cannot meet; their technical stack suffers, morale takes a toll as employees overwork in frustration, and costs increase as deployments break. Meanwhile, maintainers might as well just ignore these companies or abandon the project completely; after all, they don't owe them anything or have anything to lose. (<a href="https://caddy.community/t/the-realities-of-being-a-foss-maintainer/2728?u=matt">I almost did this with Caddy back in 2017.</a>) The relationship between developers and users becomes toxic, and the result can be virtually catastrophic (think widespread CVEs).</p>
<p>But with proper boundaries around the use of open source, companies can avoid frustrated employees, dissatisfied customers, financial and competitive losses, and technical debt. Reliant maintainers can provide quality software, cover their living expenses or make a profit, and avoid burnout.</p>
<p>This kind of healthy relationship solves the asymmetry of open source: users support the maintainers, and maintainers support the users.</p>
<h1 id="money">Money</h1>
<p>Many people view funding open source as a moral or ethical problem at its core: essentially, companies should pay for what they use (if a project accepts payment) because not doing so is exploitation. I sympathize with this perspective, but I believe a more helpful one is of economics and incentives, because we can reason about money more objectively and constructively this way.</p>
<p>When reliant open source developers want to make money, it must come from somewhere: an audience or market. Broadly speaking, the audience or market for open source products falls into two categories: consumers and businesses. (Sometimes investors, but… very rarely.)</p>
<p>On the consumer side, open source is inherently for enthusiasts; average consumers don't know or care what open source is, and they won't know how to use open source projects. Few open source projects are so nicely packaged and distributed that they are accessible to average consumers. You'd need to invest an exhausting amount of time packaging and polishing your project to make it accessible to less-technical consumers, and don't expect to get compensated for it. Open source also implies self-hosted, which consumers have no interest in: by far, only enthusiasts set up their own systems. If open source is your job, then you'll need to reach thousands, even tens of thousands of consumers to keep it sustainable, due to what consumers are used to paying. Think of streaming services, software licenses, or Patreons; they're often a few dollars a month. (I encourage you to be bold with your pricing, but also be mindful of your audience's expectations, especially when the software is fundamentally free. I once ran a <a href="https://relicabackup.com">personal backup service for $5/mo.</a> and many customers cancelled because they said it was too expensive.)</p>
<p>Marketing open source projects to consumers can be done, but you will have to expend a lot of time and diligence to make it appealing for them, and expand your user base to make it worthwhile to you—so much so that you may need as much experience in business and marketing as in coding. Think email and social media campaigns, sneak peeks, exclusive beta invites, and anything else you can do to generate hype and spread like wildfire among our less-technical friends.</p>
<p>So in practice, targeting enthusiasts narrows your market and may be more profitable to you.</p>
<p>On the business side, I think there is much less diversity in what you need to plan for. First, in stark contrast to the average consumer, companies expect to pay money for anything they need. Oh yes, they will definitely be happy to use your free software free of charge. But this is your opportunity, because companies do have money and are in the business of spending it to support their enterprise.</p>
<p>When a business commits to integrate / invest in / use a particular technology, that decision does not come lightly, and they're usually in it for the long haul. Most businesses will not sign up one month and cancel the next, whereas I have seen consumers do this frequently.</p>
<p>Company size matters more than how heavily the company is utilizing your project. Large companies tend to not care about the significance of your project, as long as they get what they need. Once a team decides to use your software, their product manager or similar team lead should be looking for ways to enforce the boundaries we talked about earlier: how can we ensure this software is reliable, who can we talk to if there's a problem, what guarantees do we have, etc? The list goes on, and because they have deadlines they will expect to talk to somebody to answer these questions within a few days. Do all you can to answer their questions completely and helpfully, for this may be the final gate before they lock your project in. Once they do, they will be ready to pay you… after it clears legal.</p>
<p>Ah yes, legal departments can slow down the process, and even impose requirements that may seem unattainable to you (for example, having liability insurance). Remember: whatever requirements they impose, you can either negotiate them or simply charge sufficient to cover your cost of their requirements. I always charge extra for custom agreements including NDAs or proprietary licenses (I typically offer a significant discount if the code I write for them can be open source).</p>
<p>The art of negotiating with companies, having liability insurance, and dealing with other legal/paperwork concerns that enterprises especially care about, was overwhelming to me at first. It's one of the primary reasons I agreed to partner with Ardan Labs for Caddy work for enterprise clients. They have a well-oiled machine for handling enterprise paperwork, and I focus on the technical aspect. It's useful, and I recommend this approach if you want to support enterprise clients without dealing with the legal hassles directly. Of course, they take a cut, but at enterprise price points it should be worth it. Remember: the customer pays for their costs, not you.</p>
<p>Smaller companies are usually much easier to work with in the legal sense but may also have smaller budgets. Don't lowball your prices, though. If they are bootstrapped, then yes, you won't be able to exact much, but it's OK to adjust your offering to match what they can afford. If they have outside investors, they likely have a fair amount of funding, so simply undercutting your own rates does both you and them a disservice. Underpricing yourself sends a confusing and unsettling messages to companies who are looking to invest. Companies have compelling legal and tax incentives to spend money, so give them a chance to do that! If it turns out your prices are too high for a company, you can negotiate them into a price point they can manage if you want to; you might have to adjust your offering accordingly to avoid overselling, burnout, and other problems that can arise from lowering your prices. Simply offer less.</p>
<p>Now you may be wondering, <em>but what do they pay for?</em> Fair question, and we will answer that in the next section. Before we get to that, though, we need to address hobby projects, or projects that neither seek nor accept payments. This is because, as we have discussed above, the imbalance in open source is caused when one side does not maintain proper boundaries. For companies, those boundaries often involve paying money. For hobby projects, their boundaries often involve not accepting money. These are not compatible. And that's the hard truth: if a company is not able to pay money for something they need from an open source project, they must take care of it themselves and accept full responsibility for its selection, use, deployment, and any security and privacy bugs, financial losses, etc. Or maybe they pay someone else who has expertise with the project yet is independent of it to get what they need. But the point is, aimlessly using volunteer-only projects in commercial applications is precisely what causes asymmetry in open source. And when something goes wrong (think Heartbleed and log4shell), people clamor to "fix open source funding" when really, money isn't the solution at all. It's boundaries.</p>
<p>This is a good time to mention that there are a lot of problems money cannot fix. Money is a tool or resource we can utilize like water and electricity. Yes, we could repurpose the trillions of dollars spent on war for eliminating poverty… assuming money alone could solve poverty, which is such a diabolically complex issue (as it is closely tied to the conditions of our hearts, families, and societies) that simply distributing wealth will not likely result in lasting change. Similarly, pouring money into open source will not fix the asymmetry unless the money is properly utilized as part of a more integrated solution. The fundamental premise of OSS is, "Here, I made this, and you can use it and contribute to it if you want to; good luck." And so we need companies to be responsible for their software choices. In open source, companies are the entities with financial means, so it's on them -- not the hobbyist authors -- to invest in the quality and maintenance of the code.</p>
<p>The reverse is true, too: maintainers seeking to finance their open source projects must go beyond money by making themselves payable to their users. <a href="https://blog.filippo.io/professional-maintainers/">Filippo Valsorda calls</a> this quality legibility:</p>
<blockquote>
<p>Maintainers need to be legible to the big company department that approves and processes those invoices. Think about it: no company pays their law firm on Patreon.</p>
</blockquote>
<p>To be legible, you will need to get formally established. Make it easy for your market to pay you. Maybe that is a Patreon, or GitHub Sponsors, but it might also be sending invoices and dealing with a legal department. Or a little of everything.</p>
<p>Now let's talk about some ways to go about doing all of this.</p>
<h1 id="implementation">Implementation</h1>
<p>What can you charge money for in open source? Here are a few ideas:</p>
<ul>
<li>Sponsorships</li>
<li>Merchandise</li>
<li>Private support</li>
<li>Consultations, onboarding, and training</li>
<li>Presenting at events</li>
<li>Custom development work</li>
<li>Prioritized bug reports / feature requests</li>
<li>Guaranteed response times</li>
<li>Publicity (tweets, case study page, link on website, etc.)</li>
<li>Hosted version</li>
<li>To simply keep doing what you're doing: maintenance and development!</li>
</ul>
<p><a href="https://blog.filippo.io/professional-maintainers/">Filippo suggests yet other possibilities</a>, and I'll copy a few here:</p>
<ul>
<li>Best security practices</li>
<li>Guarantees related to new releases, response times, and contribution activity</li>
<li>Quality standards</li>
<li>Maintainership succession plans</li>
<li>Careful "supply chain" handling (dependencies, etc.)</li>
</ul>
<p>I'd like to expound on a few of these ideas.</p>
<h2 id="merchandise">Merchandise</h2>
<p>This can take a lot of time, up front investment, and extra work on top of your usual coding job. But it's fun, and people like swag. It can help add legitimacy to your project from the consumers' point of view. Businesses don't care as much about shirts and stickers.</p>
<h2 id="private-support">Private support</h2>
<p>If you want to finance your project, never ever give help in private for free. Even if it's in a public forum, you could set a boundary that you'll only help individuals in a public venue and require that companies pay for support. I have thought about doing this but don't personally find it necessary in my case.</p>
<p>To clarify, you should answer a company's questions that will help them commit to your project in the first place. You want that barrier to be low, and you want to earn their trust and build their confidence. But you don't have to troubleshoot their installation free of charge, either.</p>
<h2 id="presentations">Presentations</h2>
<p>Speaking at events can be a fun and scary experience if you're new to it. Some people find value in conferences, others don't. It's totally up to you. It definitely adds credibility to your project, especially if you are invited. If you are invited to speak, always ask for the conference to cover your travel and lodging expenses at least. Some conferences pay their speakers, others don't. If you're giving a keynote, charge for that. People are paying them to come hear you speak: you are the world expert on your project, after all.</p>
<h2 id="hosted-version">Hosted version</h2>
<p>We talked about how open source is inherently self-hosted by default. Some individuals, professionals, and companies will pay a pretty penny if you take care of hosting a private or custom installation for them. This may only apply to more "application" type projects rather than libraries, but consider this for your repertoire.</p>
<h2 id="custom-development-work">Custom development work</h2>
<p>You might have to be careful with this one, because writing code for a company can detract from the health of your open source project. You have to decide how important the community aspect of the project is to you. Sometimes communities can carry on while you're busy with client work. Or, projects start to take the shape of your client's requirements, rather than what you envisioned. But in my experience, client requests tend to improve the project rather than hurt it, so I welcome that. You could always maintain a fork for them instead.</p>
<p>Companies will pay handsomely for expert development work, but I've also had clients who want the work to be open sourced, even live-streamed. (I offer a significant discount if the results can be open sourced.) That way it contributes to the project rather than detracts from it. Proprietary code is more valuable to companies than you think. Make sure your price acknowledges that.</p>
<p>Don't charge a simple hourly rate, as tracking hours is probably the last thing you want to be doing. The company that's hiring you probably doesn't care either. Besides, what if the code you write over ~12 hours on a weekend enables $100,000s of revenue annually for your customer? This has happened to me, and it's miserable to earn only a month's rent for that kind of value, especially considering the pressure to get it right and help them maintain it. After learning what companies pay for custom features they need, I should have charged more.</p>
<p>Do your best to give a general timeframe if they require one, but anticipate setbacks. I always try to overestimate how long it will take and then surprise them by delivering early. Thus, I give the project an overall cost, or if I have to break it down by time, I use weeks, not hours.</p>
<p>Things to watch out for where you can charge a premium:</p>
<ul>
<li>NDAs</li>
<li>Non-compete (if even legal)</li>
<li>Copyright assignment</li>
<li>Automated tests</li>
<li>Requirement changes</li>
<li>Rushed delivery</li>
<li>Proprietary licenses</li>
<li>Insurance</li>
<li>Custom terms</li>
<li>Ongoing maintenance</li>
<li>Dependency / supply chain management</li>
<li>Code audits</li>
<li>On-call (do not sell this cheaply)</li>
<li>Guaranteed response times</li>
<li>Integration/installation assistance</li>
<li>Hosted version</li>
<li>… to name a few.</li>
</ul>

<p>Let's spend some time on this one. I think sponsorships are the best product your open source project can offer. They generalize well and stand on their own as tangible products. Sponsorships are great because you can keep doing what you need to do to keep the project maintained and growing. Companies and individuals alike will pay for the assurance that the project will continue being maintained. That alone has immense value.</p>
<p>Despite the GitHub nomenclature, I do not consider one-time payments to be sponsorships; those are donations (unless the one-time payment happens to extend through the lifetime of the project or event, as is the case with conference sponsors -- but that is almost never the case with open source). For long-term full-time sustainability, I do not recommend one-time payments. You will either need to accept only large investments or continually attract thousands of one-time donors to achieve sustainability. Focus on subscriptions.</p>
<p>You'll need a service that can process payments or manage the subscriptions for you. I find <a href="https://github.com/sponsors">GitHub Sponsors</a> useful because GitHub is already on a lot of companies' approved vendors lists, or even already in their accounting system. In other words, expensing something to GitHub is a no-brainer for most tech companies. Whereas expensing something to a generic collective like Patreon or Bountysource <a href="https://twitter.com/SwiftOnSecurity/status/1067697147196379137">is hell</a>. Before GitHub Sponsors, I've had customers ask me if I can bill them through AWS precisely so they could avoid the rigamarole of adding a new vendor. (Spoiler alert: I couldn't figure it out and lost the sale.) Stick with big name services and try to avoid ones that add fees. GitHub Sponsors is a great option with zero fees (except Stripe's credit card fees, which are unavoidable.)</p>
<p>Some companies will need to be sent an invoice to be billed. That might be every month, every quarter, or every year. You should make it clear whether you support this option. To do this you may need to establish a business entity (it's easy to form an LLC in the US) with a bank account, and accept wire transfers and/or ACH deposits. I offer this option, but not for low-end sponsorships.</p>
<p>You have a lot of flexibility with sponsorships. I recommend setting tiers because this demonstrates that you own your product line. Businesses will take that seriously. They don't want to have to decide how much to pay you, just tell them. You may choose to offer perks with each tier. That's optional, but it definitely makes higher tiers more compelling.</p>
<p>Oh, right -- let's talk about price points. This is huge, and it's one of the biggest disappointments I see with nearly every open source project because too many are too low. It's fine to set lower prices if you accept sponsorships merely for motivation to continue your hobby, but if you are actually trying to sustain the project, you cannot go low. I see too many monthly $1, $5, and $10 tiers, with maximums of $20, $50, or maybe $100. This will not do. Companies will not take you seriously.</p>
<p>Although both individuals and companies can buy sponsorships from you, what companies are willing and able to pay should blow individuals' budgets out of the water, to the point that the consumer tiers are really not necessary. Individuals may pay a few dollars a month to support a project they like, but companies forgot how to count that low. You'll probably want tiers that appeal to small, bootstrapped startups which are excited to use your technology, as well as tiers that can cover enterprise requirements. You don't need to sell hundreds of them if your tiers are priced boldly enough to cover your costs. Just a few will do, and it's easier to maintain relationships with them then, too.</p>
<p>While sponsorship tiers stand on their own as tangible products, you might make them more compelling by offering perks. Perks should align with their price. Let's examine a couple ways for reasoning about this.</p>
<p>For sponsorship tiers that offer private support including answering emails or taking calls, compare those prices to consultancy fees. Consulting an expert should easily cost from $150-500 per hour. (This varies by many factors, including where you are in the world.) Consulting or contracting jobs are usually less secure forms of income: they have variable frequency and duration, and often carry extra risk or liability; hence the higher rates versus being a salaried employee. These rates cause sticker shock for smaller companies (startups) and I have had to turn down a number of requests because I am too expensive. Larger companies can afford these rates, but their legal processes can be slow and expensive, making consulting or contracting a tedious business.</p>
<p>Open source sponsorships have a unique opportunity here. Sponsorships are usually invoiced monthly, quarterly, or yearly; so what does your $10/mo. tier provide? If it's more than 4 minutes of your dedicated time for the whole month, you're not charging enough; not even close. What about a $25/mo. tier? Ok, maybe 10 minutes. That might be enough to answer an email with your expertise once in a while. If companies will pay a consultant $1000 for a day of work, can the developer of an open source project charge $1000 per month for about one day of their time every month? Few companies would justify it when framed that way, and you can see how a regularly-recurring fee doesn't translate perfectly well to an occasional service. So try to avoid giving time promises.</p>
<p>Even if we discard the time element, a lot of large companies won't even look at price points with just 2 or even 3 digits; don't expect them to take you seriously, especially if they'd be billed by an "open collective" like we talked about earlier. However, companies will readily pay a $1k/mo sponsorship with a support offering instead of paying an in-house developer $180k/year, especially as the sponsorship has other benefits.</p>
<p>If we think of open source sponsorships more like insurance, sponsorships become a very appealing option. Pay a small monthly premium, and occasional preventative care is covered. Have a basic question about how to best use the program in your infrastructure? No problem, for $25/mo. the occasional email like that is covered.</p>
<p>The exact price point and how much that covers is up to you. For comparison, US dental insurance premiums may be around $40/mo. and cover only two cleanings as preventative work every year. Without insurance those visits might cost about $500 total, which is nearly the same as premiums for the year. While dental and software are different markets, we can learn that even consumers are willing to pay a nontrivial monthly premium for basic care that is given only twice per year without significant discount. But they do this because dental insurance also provides discounts or benefits when more extensive work is needed, so there is often incentive to pay the premium over just paying out-of-pocket for preventative services.</p>
<p>Open source sponsorships can do something similar. Higher tiers can cover or discount more time-intensive requests. Want your feature prioritized? That's covered at a higher tier. Need a new feature added or an urgent bug fixed? A high-tier sponsorship can give you a discount on major development work, and since you're already on their Accounts Payable for the sponsorship, getting started on that can be very quick and easy. Sponsorships reduce the friction needed to get started on more urgent and extensive work, which is attractive to companies.</p>
<p>When seeking sponsorships, do your best to help your project spread and make sure people know when it's popular. Get it into as many systems as possible. Earn "street cred." Minimize the number of reasons why potential users or companies may turn away. Hint: an obscure or contentious license can be an instant dealbreaker.</p>
<p>Choose a standard open source license whenever possible. The legal structures and processes within large companies are set up to allow them more easily. You can use this to your advantage by getting your project into as many systems as possible. The more embedded, utilized, and depended upon your project is, the more potential you have for leveraging the project to sustain itself. Use "copyleft" (GPL/AGPL) only if you want to sell proprietary licenses to companies; otherwise they will not use your software, period. That's a valid strategy, but I have found more success in having my software spread "everywhere" first, then leveraging that to sell sponsorships. Sponsorships don't sell well in a vacuum: they need a network, a community. That also implies fostering a community around the project, which also takes time.</p>
<p>Some sponsors will want to develop an active relationship, but you'll find that the vast majority just want you to keep doing what you're doing and won't ask anything special. I've found that most sponsors don't even take advantage of the perks available to them. That's OK, as it makes me more productive, which is what they want.</p>
<p>It may take years of tuning for you to settle on sponsorship offerings that work for you and your market. That's OK! Remember, the main idea here is to own your sponsorship plans (rather than just accepting donations), and to make what you do offer compelling to your market (whether that be consumers, professionals, or businesses).</p>
</article>


<hr>

<footer>
<p>
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="/david/log/" title="Accès au flux RSS"><svg class="icon icon-rss2">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-rss2"></use>
</svg> Suivre</a> •
<a href="http://larlet.com" title="Go to my English profile" data-instant><svg class="icon icon-user-tie">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-user-tie"></use>
</svg> Pro</a> •
<a href="mailto:david%40larlet.fr" title="Envoyer un courriel"><svg class="icon icon-mail">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-mail"></use>
</svg> Email</a> •
<abbr class="nowrap" title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340"><svg class="icon icon-hammer2">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-hammer2"></use>
</svg> Légal</abbr>
</p>
<template id="theme-selector">
<form>
<fieldset>
<legend><svg class="icon icon-brightness-contrast">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-brightness-contrast"></use>
</svg> Thème</legend>
<label>
<input type="radio" value="auto" name="chosen-color-scheme" checked> Auto
</label>
<label>
<input type="radio" value="dark" name="chosen-color-scheme"> Foncé
</label>
<label>
<input type="radio" value="light" name="chosen-color-scheme"> Clair
</label>
</fieldset>
</form>
</template>
</footer>
<script src="/static/david/js/instantpage-5.1.0.min.js" type="module"></script>
<script>
function loadThemeForm(templateName) {
const themeSelectorTemplate = document.querySelector(templateName)
const form = themeSelectorTemplate.content.firstElementChild
themeSelectorTemplate.replaceWith(form)

form.addEventListener('change', (e) => {
const chosenColorScheme = e.target.value
localStorage.setItem('theme', chosenColorScheme)
toggleTheme(chosenColorScheme)
})

const selectedTheme = localStorage.getItem('theme')
if (selectedTheme && selectedTheme !== 'undefined') {
form.querySelector(`[value="${selectedTheme}"]`).checked = true
}
}

const prefersColorSchemeDark = '(prefers-color-scheme: dark)'
window.addEventListener('load', () => {
let hasDarkRules = false
for (const styleSheet of Array.from(document.styleSheets)) {
let mediaRules = []
for (const cssRule of styleSheet.cssRules) {
if (cssRule.type !== CSSRule.MEDIA_RULE) {
continue
}
// WARNING: Safari does not have/supports `conditionText`.
if (cssRule.conditionText) {
if (cssRule.conditionText !== prefersColorSchemeDark) {
continue
}
} else {
if (cssRule.cssText.startsWith(prefersColorSchemeDark)) {
continue
}
}
mediaRules = mediaRules.concat(Array.from(cssRule.cssRules))
}

// WARNING: do not try to insert a Rule to a styleSheet you are
// currently iterating on, otherwise the browser will be stuck
// in a infinite loop…
for (const mediaRule of mediaRules) {
styleSheet.insertRule(mediaRule.cssText)
hasDarkRules = true
}
}
if (hasDarkRules) {
loadThemeForm('#theme-selector')
}
})
</script>
</body>
</html>

+ 175
- 0
cache/2022/e8d6bd5b11ae399009cf9258869be09c/index.md View File

@@ -0,0 +1,175 @@
title: The Asymmetry of Open Source
url: https://matt.life/writing/the-asymmetry-of-open-source
hash_url: e8d6bd5b11ae399009cf9258869be09c

<p><em><strong>Users need open source projects, but open source projects do not need users.</strong></em></p>
<p>That asymmetry is, I believe, at the crux of the open source sustainability problem. We all use open source projects either directly or indirectly. But projects do not need us. Of course, projects need users to create rich and active communities, collaborate on code, and contribute in other ways; but those are optional components, and projects can absolutely do what they want in a vacuum, ignore their users, or even abandon them altogether. Ultimately, project developers do not need users in order to write code and put it on the Internet.</p>
<p>With the recent revival of the discussion about sustaining open source spurred on by multiple severe CVEs in a popular logging library, and with so many hot takes clamoring for more funding—some calling on companies, others on maintainers—I wanted to write about the problem and its solutions more wholistically, as I have spent many years thinking about this from my own experience with both failing and succeeding… a perspective that I hope some of you will find helpful.</p>
<p><strong>I develop the <a href="https://caddyserver.com">Caddy web server</a>, and I rely on open source sponsorships for my living. To be part of a more secure and reliable Internet, have your employer <a href="https://github.com/sponsors/mholt">sponsor me (mholt) on GitHub</a>!</strong></p>

<hr>
<p>Open source work comes in different flavors. On one spectrum, it's either your hobby or your job. As a hobby, open source is less about funding and more about personal interest. Donations or sponsorships are nice encouragement to keep going, but the money isn't for the nights and weekends, it's for the warm fuzzies. It's a nice feeling to have your lunch paid for, or to receive a thank-you note with a donation. (I might add, too, that "warm fuzzies" <em>do</em> matter and are valid rewards in volunteer open source efforts. There's nothing wrong with inviting donations to stay motivated.) But your livelihood is sustained through a separate day job. Volunteer open source has given us the majority of all open source projects, including some fairly popular ones like restic and gogs.</p>
<p>As a job, open source can generally be sustained by two models:</p>
<ul>
<li>
<p><strong>Serendipitous:</strong> Open source is your job, but not your income. Your livelihood is sustained by other means. For example, your salary comes from a company that sells other products or services to make payroll, but your job description happens to consist of doing open source.</p>
</li>
<li>
<p><strong>Reliance:</strong> Open source is your job and your income. As the primary source of revenue, it's how you pay the bills. Whether you work for a company or for yourself, the project(s) must be sustainable to the degree you rely upon it for income. If you lost the income from open source, you'd need to find other work.</p>
</li>
</ul>
<p>Serendipitous open source is great; it's how we got nice things like Zstandard, VS Code, Android, and Go, but also makes up only a minority of financed projects. Reliant open source is the majority of financed projects by far, and has yielded projects like Homebrew, curl, OpenSSL, Vue.js, rclone, Caddy, and countless others.</p>
<p>Reliant developers pay their bills from free software. And therein lies the problem that is primarily what this article is about. If you're only serendipitously working on open source, you don't have the same pressures to survive as reliant developers, but we have another special role for you.</p>
<p>Serendipitous open sourcers are the proof: proof that companies will pay for open source development (even if being open source is just a coincidence or side-effect). You seldom hear complaints about quality of life with serendipitous open source projects. That's because that model works. Being paid to work on open source is the obvious solution to funding open source, and is often the crucial missing piece of the reliance model as well. The hard question is, if you're not paid by your company to work on open source, where does the money come from when the software is free? This seems futile, but there is hope.</p>
<h1 id="boundaries">Boundaries</h1>
<p>When you hear rallying cries to fund open source, or complaints that open source maintainers are overburdened and under-thanked, it's usually due to the misapplication of healthy open source principles. With liberal licenses, open source projects grant a lot of freedom, and that means it's easy for the relationship between maintainers and users to form a toxic imbalance if they aren't both careful and vigilant. Just like healthy personal relationships, healthy open source relationships establish clear boundaries and exhibit mutual respect to succeed.</p>
<p>With proper boundaries, a healthier, more helpful community can be fostered; developers and maintainers won't be over-burdened, companies and other users still get what they need, and expectations and requirements are satisfied on both sides. Establishing boundaries does not have to conflict with the freedoms granted from liberal licenses. And crucially, boundaries can be established without switching licenses.</p>
<p>Too often, we often talk about what open source licenses grant the users. Instead, we should place equal emphasis on what open source licenses grant the developers.</p>
<p>The first thing to consider is that the developers count as users. That means you can use your own project commercially! Think about that. You also have rights to distribute and modify your software, and you don't have to do that for free. And if you're the owner of the project, you are exempt from any restrictive license terms such as stating changes, disclosing source, retaining copyright, or not using the trademark. (Why? Because you used your ownership rights to endow the project with a license in the first place. You own it, so you set the terms.)</p>
<p>However, there is a delicate accord here. Open source is not entitled to funding. Just because you produced something useful does not mean anyone owes you money, especially with a license that says "Permission is hereby granted, free of charge." Of course, money has its place—and it <strong>does</strong> have a place in open source—but there is no implied contract that the code you wrote has to be paid for.</p>
<p>The converse is true as well: companies are not entitled to open source projects. Let me explain this one as it can be misinterpreted. Yes, open source licenses literally give companies a "title" to use the project for their capitalist purposes for free. However, they are not entitled to expect the same things from open source software that they'd get from commercial products. Almost all OSS licenses come with significant caveats that companies should be aware of; for example in the Apache 2.0 license:</p>
<blockquote>
<p>Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.</p>
</blockquote>
<p>And similarly in the MIT license:</p>
<blockquote>
<p>THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.</p>
</blockquote>
<p>These sections should make companies nervous, because it means they need to assume full responsibility when relying on software in their multi-million-dollar business that was probably developed by a tired young parent or college student who didn't get enough sleep.</p>
<p>In fact, proprietary software licenses often come with terms like these too. But companies are willing to pay a premium for them anyway because they know that even though the vendor is legally protected, they have access to expertise and services that effectively act like a warranty.</p>
<p>When using open source software, companies must bring their own expertise to know that the software is right for their needs. And if they're not sure? They can pay for a consultation. A company must be prepared to not only file bugs, but fix them too. They must have the means and know-how to implement a feature. Why? Because open source software is "provided as-is." They are on their own unless they pay someone for what they need. The risks of faulting here may be catastrophic to otherwise-successful businesses.</p>
<p>Healthy boundaries for a company might be:</p>
<ul>
<li>We do not allow open source software to inhibit our business by investing in:
<ul>
<li>a proper assessment of a project to ensure it meets our needs.</li>
<li>expert consultation or relevant hiring to integrate the software.</li>
<li>adequate support services.</li>
<li>ongoing development and maintenance of the software.</li>
</ul>
</li>
<li>We own our requirements, standards, or practices and do not impose them onto open source maintainers or developers—even implicitly.</li>
<li>We examine our dependency tree for subtly crucial components that may be underfunded or unmaintained, and either invest in them or change our stack.</li>
<li>If open source software is crucial to our business or is used in a critical environment, we strive to establish a relationship with the developers so they can be aware of the important use case. We do not assume they will cater to our use case simply because it is an important one. We offer to support them so they can support us.</li>
<li>We either don't use projects that don't meet our requirements, or we invest in it to meet specification.</li>
</ul>
<p>As you can see, boundaries are about asserting who owns and controls the business, and what companies will allow to happen to their business. A healthy boundary doesn't allow the blights of volunteer projects to negatively impact their business, nor does it take without giving. Standing by these boundaries may require virtuous and stubborn employees at multiple levels within the company. I urge you to be one of them.</p>
<p>Healthy boundaries for maintainers and project owners might be:</p>
<ul>
<li>I'm doing this project for me.</li>
<li>I don't implement features or incorporate changes I don't want.</li>
<li>I reject changes that I think are not a good fit for the project.</li>
<li>Donations are not contractual.</li>
<li>I only help when I can or want to.</li>
<li>There's no hurry for me to get around to issues or PRs.</li>
<li>Users can help each other; I don't have to do it all.</li>
<li>I only give help privately if I'm being paid or sponsored.</li>
<li>I don't accept donations or sponsorships.
<ul>
<li>To avoid feeling pressure (it's normal to feel pressure even if it's not warranted)</li>
<li>Or any other reason! (or no reason at all; it's okay)</li>
</ul>
</li>
</ul>
<p>As I learned from unpopular decisions with the Caddy project, hundreds of voices in a single day can feel very heavy. These kinds of boundaries can help prevent being steamrolled by user demands. Stick by them.</p>
<p>Here's an example of a boundary I set as the Caddy project grew: I decided that I could not afford to provide support in private channels for free. We have <a href="https://caddy.community">a forum</a> where people can request help, but I am not obligated to respond to help requests there; because it's a public forum, I leave that mainly up to the community and chime in when I am able. If someone emails me with questions, my general rule is to send them my sponsorship plans and consulting rates along with a link to the forum if they prefer to have volunteers to help them instead. In my experience, people have respected this boundary and I've formed some good relationships this way.</p>
<p>Without boundaries, companies may use an open source project extensively with requirements that the project is not suited for, demand a and have expectations that the maintainers will not or cannot meet; their technical stack suffers, morale takes a toll as employees overwork in frustration, and costs increase as deployments break. Meanwhile, maintainers might as well just ignore these companies or abandon the project completely; after all, they don't owe them anything or have anything to lose. (<a href="https://caddy.community/t/the-realities-of-being-a-foss-maintainer/2728?u=matt">I almost did this with Caddy back in 2017.</a>) The relationship between developers and users becomes toxic, and the result can be virtually catastrophic (think widespread CVEs).</p>
<p>But with proper boundaries around the use of open source, companies can avoid frustrated employees, dissatisfied customers, financial and competitive losses, and technical debt. Reliant maintainers can provide quality software, cover their living expenses or make a profit, and avoid burnout.</p>
<p>This kind of healthy relationship solves the asymmetry of open source: users support the maintainers, and maintainers support the users.</p>
<h1 id="money">Money</h1>
<p>Many people view funding open source as a moral or ethical problem at its core: essentially, companies should pay for what they use (if a project accepts payment) because not doing so is exploitation. I sympathize with this perspective, but I believe a more helpful one is of economics and incentives, because we can reason about money more objectively and constructively this way.</p>
<p>When reliant open source developers want to make money, it must come from somewhere: an audience or market. Broadly speaking, the audience or market for open source products falls into two categories: consumers and businesses. (Sometimes investors, but… very rarely.)</p>
<p>On the consumer side, open source is inherently for enthusiasts; average consumers don't know or care what open source is, and they won't know how to use open source projects. Few open source projects are so nicely packaged and distributed that they are accessible to average consumers. You'd need to invest an exhausting amount of time packaging and polishing your project to make it accessible to less-technical consumers, and don't expect to get compensated for it. Open source also implies self-hosted, which consumers have no interest in: by far, only enthusiasts set up their own systems. If open source is your job, then you'll need to reach thousands, even tens of thousands of consumers to keep it sustainable, due to what consumers are used to paying. Think of streaming services, software licenses, or Patreons; they're often a few dollars a month. (I encourage you to be bold with your pricing, but also be mindful of your audience's expectations, especially when the software is fundamentally free. I once ran a <a href="https://relicabackup.com">personal backup service for $5/mo.</a> and many customers cancelled because they said it was too expensive.)</p>
<p>Marketing open source projects to consumers can be done, but you will have to expend a lot of time and diligence to make it appealing for them, and expand your user base to make it worthwhile to you—so much so that you may need as much experience in business and marketing as in coding. Think email and social media campaigns, sneak peeks, exclusive beta invites, and anything else you can do to generate hype and spread like wildfire among our less-technical friends.</p>
<p>So in practice, targeting enthusiasts narrows your market and may be more profitable to you.</p>
<p>On the business side, I think there is much less diversity in what you need to plan for. First, in stark contrast to the average consumer, companies expect to pay money for anything they need. Oh yes, they will definitely be happy to use your free software free of charge. But this is your opportunity, because companies do have money and are in the business of spending it to support their enterprise.</p>
<p>When a business commits to integrate / invest in / use a particular technology, that decision does not come lightly, and they're usually in it for the long haul. Most businesses will not sign up one month and cancel the next, whereas I have seen consumers do this frequently.</p>
<p>Company size matters more than how heavily the company is utilizing your project. Large companies tend to not care about the significance of your project, as long as they get what they need. Once a team decides to use your software, their product manager or similar team lead should be looking for ways to enforce the boundaries we talked about earlier: how can we ensure this software is reliable, who can we talk to if there's a problem, what guarantees do we have, etc? The list goes on, and because they have deadlines they will expect to talk to somebody to answer these questions within a few days. Do all you can to answer their questions completely and helpfully, for this may be the final gate before they lock your project in. Once they do, they will be ready to pay you… after it clears legal.</p>
<p>Ah yes, legal departments can slow down the process, and even impose requirements that may seem unattainable to you (for example, having liability insurance). Remember: whatever requirements they impose, you can either negotiate them or simply charge sufficient to cover your cost of their requirements. I always charge extra for custom agreements including NDAs or proprietary licenses (I typically offer a significant discount if the code I write for them can be open source).</p>
<p>The art of negotiating with companies, having liability insurance, and dealing with other legal/paperwork concerns that enterprises especially care about, was overwhelming to me at first. It's one of the primary reasons I agreed to partner with Ardan Labs for Caddy work for enterprise clients. They have a well-oiled machine for handling enterprise paperwork, and I focus on the technical aspect. It's useful, and I recommend this approach if you want to support enterprise clients without dealing with the legal hassles directly. Of course, they take a cut, but at enterprise price points it should be worth it. Remember: the customer pays for their costs, not you.</p>
<p>Smaller companies are usually much easier to work with in the legal sense but may also have smaller budgets. Don't lowball your prices, though. If they are bootstrapped, then yes, you won't be able to exact much, but it's OK to adjust your offering to match what they can afford. If they have outside investors, they likely have a fair amount of funding, so simply undercutting your own rates does both you and them a disservice. Underpricing yourself sends a confusing and unsettling messages to companies who are looking to invest. Companies have compelling legal and tax incentives to spend money, so give them a chance to do that! If it turns out your prices are too high for a company, you can negotiate them into a price point they can manage if you want to; you might have to adjust your offering accordingly to avoid overselling, burnout, and other problems that can arise from lowering your prices. Simply offer less.</p>
<p>Now you may be wondering, <em>but what do they pay for?</em> Fair question, and we will answer that in the next section. Before we get to that, though, we need to address hobby projects, or projects that neither seek nor accept payments. This is because, as we have discussed above, the imbalance in open source is caused when one side does not maintain proper boundaries. For companies, those boundaries often involve paying money. For hobby projects, their boundaries often involve not accepting money. These are not compatible. And that's the hard truth: if a company is not able to pay money for something they need from an open source project, they must take care of it themselves and accept full responsibility for its selection, use, deployment, and any security and privacy bugs, financial losses, etc. Or maybe they pay someone else who has expertise with the project yet is independent of it to get what they need. But the point is, aimlessly using volunteer-only projects in commercial applications is precisely what causes asymmetry in open source. And when something goes wrong (think Heartbleed and log4shell), people clamor to "fix open source funding" when really, money isn't the solution at all. It's boundaries.</p>
<p>This is a good time to mention that there are a lot of problems money cannot fix. Money is a tool or resource we can utilize like water and electricity. Yes, we could repurpose the trillions of dollars spent on war for eliminating poverty… assuming money alone could solve poverty, which is such a diabolically complex issue (as it is closely tied to the conditions of our hearts, families, and societies) that simply distributing wealth will not likely result in lasting change. Similarly, pouring money into open source will not fix the asymmetry unless the money is properly utilized as part of a more integrated solution. The fundamental premise of OSS is, "Here, I made this, and you can use it and contribute to it if you want to; good luck." And so we need companies to be responsible for their software choices. In open source, companies are the entities with financial means, so it's on them -- not the hobbyist authors -- to invest in the quality and maintenance of the code.</p>
<p>The reverse is true, too: maintainers seeking to finance their open source projects must go beyond money by making themselves payable to their users. <a href="https://blog.filippo.io/professional-maintainers/">Filippo Valsorda calls</a> this quality legibility:</p>
<blockquote>
<p>Maintainers need to be legible to the big company department that approves and processes those invoices. Think about it: no company pays their law firm on Patreon.</p>
</blockquote>
<p>To be legible, you will need to get formally established. Make it easy for your market to pay you. Maybe that is a Patreon, or GitHub Sponsors, but it might also be sending invoices and dealing with a legal department. Or a little of everything.</p>
<p>Now let's talk about some ways to go about doing all of this.</p>
<h1 id="implementation">Implementation</h1>
<p>What can you charge money for in open source? Here are a few ideas:</p>
<ul>
<li>Sponsorships</li>
<li>Merchandise</li>
<li>Private support</li>
<li>Consultations, onboarding, and training</li>
<li>Presenting at events</li>
<li>Custom development work</li>
<li>Prioritized bug reports / feature requests</li>
<li>Guaranteed response times</li>
<li>Publicity (tweets, case study page, link on website, etc.)</li>
<li>Hosted version</li>
<li>To simply keep doing what you're doing: maintenance and development!</li>
</ul>
<p><a href="https://blog.filippo.io/professional-maintainers/">Filippo suggests yet other possibilities</a>, and I'll copy a few here:</p>
<ul>
<li>Best security practices</li>
<li>Guarantees related to new releases, response times, and contribution activity</li>
<li>Quality standards</li>
<li>Maintainership succession plans</li>
<li>Careful "supply chain" handling (dependencies, etc.)</li>
</ul>
<p>I'd like to expound on a few of these ideas.</p>
<h2 id="merchandise">Merchandise</h2>
<p>This can take a lot of time, up front investment, and extra work on top of your usual coding job. But it's fun, and people like swag. It can help add legitimacy to your project from the consumers' point of view. Businesses don't care as much about shirts and stickers.</p>
<h2 id="private-support">Private support</h2>
<p>If you want to finance your project, never ever give help in private for free. Even if it's in a public forum, you could set a boundary that you'll only help individuals in a public venue and require that companies pay for support. I have thought about doing this but don't personally find it necessary in my case.</p>
<p>To clarify, you should answer a company's questions that will help them commit to your project in the first place. You want that barrier to be low, and you want to earn their trust and build their confidence. But you don't have to troubleshoot their installation free of charge, either.</p>
<h2 id="presentations">Presentations</h2>
<p>Speaking at events can be a fun and scary experience if you're new to it. Some people find value in conferences, others don't. It's totally up to you. It definitely adds credibility to your project, especially if you are invited. If you are invited to speak, always ask for the conference to cover your travel and lodging expenses at least. Some conferences pay their speakers, others don't. If you're giving a keynote, charge for that. People are paying them to come hear you speak: you are the world expert on your project, after all.</p>
<h2 id="hosted-version">Hosted version</h2>
<p>We talked about how open source is inherently self-hosted by default. Some individuals, professionals, and companies will pay a pretty penny if you take care of hosting a private or custom installation for them. This may only apply to more "application" type projects rather than libraries, but consider this for your repertoire.</p>
<h2 id="custom-development-work">Custom development work</h2>
<p>You might have to be careful with this one, because writing code for a company can detract from the health of your open source project. You have to decide how important the community aspect of the project is to you. Sometimes communities can carry on while you're busy with client work. Or, projects start to take the shape of your client's requirements, rather than what you envisioned. But in my experience, client requests tend to improve the project rather than hurt it, so I welcome that. You could always maintain a fork for them instead.</p>
<p>Companies will pay handsomely for expert development work, but I've also had clients who want the work to be open sourced, even live-streamed. (I offer a significant discount if the results can be open sourced.) That way it contributes to the project rather than detracts from it. Proprietary code is more valuable to companies than you think. Make sure your price acknowledges that.</p>
<p>Don't charge a simple hourly rate, as tracking hours is probably the last thing you want to be doing. The company that's hiring you probably doesn't care either. Besides, what if the code you write over ~12 hours on a weekend enables $100,000s of revenue annually for your customer? This has happened to me, and it's miserable to earn only a month's rent for that kind of value, especially considering the pressure to get it right and help them maintain it. After learning what companies pay for custom features they need, I should have charged more.</p>
<p>Do your best to give a general timeframe if they require one, but anticipate setbacks. I always try to overestimate how long it will take and then surprise them by delivering early. Thus, I give the project an overall cost, or if I have to break it down by time, I use weeks, not hours.</p>
<p>Things to watch out for where you can charge a premium:</p>
<ul>
<li>NDAs</li>
<li>Non-compete (if even legal)</li>
<li>Copyright assignment</li>
<li>Automated tests</li>
<li>Requirement changes</li>
<li>Rushed delivery</li>
<li>Proprietary licenses</li>
<li>Insurance</li>
<li>Custom terms</li>
<li>Ongoing maintenance</li>
<li>Dependency / supply chain management</li>
<li>Code audits</li>
<li>On-call (do not sell this cheaply)</li>
<li>Guaranteed response times</li>
<li>Integration/installation assistance</li>
<li>Hosted version</li>
<li>… to name a few.</li>
</ul>

<p>Let's spend some time on this one. I think sponsorships are the best product your open source project can offer. They generalize well and stand on their own as tangible products. Sponsorships are great because you can keep doing what you need to do to keep the project maintained and growing. Companies and individuals alike will pay for the assurance that the project will continue being maintained. That alone has immense value.</p>
<p>Despite the GitHub nomenclature, I do not consider one-time payments to be sponsorships; those are donations (unless the one-time payment happens to extend through the lifetime of the project or event, as is the case with conference sponsors -- but that is almost never the case with open source). For long-term full-time sustainability, I do not recommend one-time payments. You will either need to accept only large investments or continually attract thousands of one-time donors to achieve sustainability. Focus on subscriptions.</p>
<p>You'll need a service that can process payments or manage the subscriptions for you. I find <a href="https://github.com/sponsors">GitHub Sponsors</a> useful because GitHub is already on a lot of companies' approved vendors lists, or even already in their accounting system. In other words, expensing something to GitHub is a no-brainer for most tech companies. Whereas expensing something to a generic collective like Patreon or Bountysource <a href="https://twitter.com/SwiftOnSecurity/status/1067697147196379137">is hell</a>. Before GitHub Sponsors, I've had customers ask me if I can bill them through AWS precisely so they could avoid the rigamarole of adding a new vendor. (Spoiler alert: I couldn't figure it out and lost the sale.) Stick with big name services and try to avoid ones that add fees. GitHub Sponsors is a great option with zero fees (except Stripe's credit card fees, which are unavoidable.)</p>
<p>Some companies will need to be sent an invoice to be billed. That might be every month, every quarter, or every year. You should make it clear whether you support this option. To do this you may need to establish a business entity (it's easy to form an LLC in the US) with a bank account, and accept wire transfers and/or ACH deposits. I offer this option, but not for low-end sponsorships.</p>
<p>You have a lot of flexibility with sponsorships. I recommend setting tiers because this demonstrates that you own your product line. Businesses will take that seriously. They don't want to have to decide how much to pay you, just tell them. You may choose to offer perks with each tier. That's optional, but it definitely makes higher tiers more compelling.</p>
<p>Oh, right -- let's talk about price points. This is huge, and it's one of the biggest disappointments I see with nearly every open source project because too many are too low. It's fine to set lower prices if you accept sponsorships merely for motivation to continue your hobby, but if you are actually trying to sustain the project, you cannot go low. I see too many monthly $1, $5, and $10 tiers, with maximums of $20, $50, or maybe $100. This will not do. Companies will not take you seriously.</p>
<p>Although both individuals and companies can buy sponsorships from you, what companies are willing and able to pay should blow individuals' budgets out of the water, to the point that the consumer tiers are really not necessary. Individuals may pay a few dollars a month to support a project they like, but companies forgot how to count that low. You'll probably want tiers that appeal to small, bootstrapped startups which are excited to use your technology, as well as tiers that can cover enterprise requirements. You don't need to sell hundreds of them if your tiers are priced boldly enough to cover your costs. Just a few will do, and it's easier to maintain relationships with them then, too.</p>
<p>While sponsorship tiers stand on their own as tangible products, you might make them more compelling by offering perks. Perks should align with their price. Let's examine a couple ways for reasoning about this.</p>
<p>For sponsorship tiers that offer private support including answering emails or taking calls, compare those prices to consultancy fees. Consulting an expert should easily cost from $150-500 per hour. (This varies by many factors, including where you are in the world.) Consulting or contracting jobs are usually less secure forms of income: they have variable frequency and duration, and often carry extra risk or liability; hence the higher rates versus being a salaried employee. These rates cause sticker shock for smaller companies (startups) and I have had to turn down a number of requests because I am too expensive. Larger companies can afford these rates, but their legal processes can be slow and expensive, making consulting or contracting a tedious business.</p>
<p>Open source sponsorships have a unique opportunity here. Sponsorships are usually invoiced monthly, quarterly, or yearly; so what does your $10/mo. tier provide? If it's more than 4 minutes of your dedicated time for the whole month, you're not charging enough; not even close. What about a $25/mo. tier? Ok, maybe 10 minutes. That might be enough to answer an email with your expertise once in a while. If companies will pay a consultant $1000 for a day of work, can the developer of an open source project charge $1000 per month for about one day of their time every month? Few companies would justify it when framed that way, and you can see how a regularly-recurring fee doesn't translate perfectly well to an occasional service. So try to avoid giving time promises.</p>
<p>Even if we discard the time element, a lot of large companies won't even look at price points with just 2 or even 3 digits; don't expect them to take you seriously, especially if they'd be billed by an "open collective" like we talked about earlier. However, companies will readily pay a $1k/mo sponsorship with a support offering instead of paying an in-house developer $180k/year, especially as the sponsorship has other benefits.</p>
<p>If we think of open source sponsorships more like insurance, sponsorships become a very appealing option. Pay a small monthly premium, and occasional preventative care is covered. Have a basic question about how to best use the program in your infrastructure? No problem, for $25/mo. the occasional email like that is covered.</p>
<p>The exact price point and how much that covers is up to you. For comparison, US dental insurance premiums may be around $40/mo. and cover only two cleanings as preventative work every year. Without insurance those visits might cost about $500 total, which is nearly the same as premiums for the year. While dental and software are different markets, we can learn that even consumers are willing to pay a nontrivial monthly premium for basic care that is given only twice per year without significant discount. But they do this because dental insurance also provides discounts or benefits when more extensive work is needed, so there is often incentive to pay the premium over just paying out-of-pocket for preventative services.</p>
<p>Open source sponsorships can do something similar. Higher tiers can cover or discount more time-intensive requests. Want your feature prioritized? That's covered at a higher tier. Need a new feature added or an urgent bug fixed? A high-tier sponsorship can give you a discount on major development work, and since you're already on their Accounts Payable for the sponsorship, getting started on that can be very quick and easy. Sponsorships reduce the friction needed to get started on more urgent and extensive work, which is attractive to companies.</p>
<p>When seeking sponsorships, do your best to help your project spread and make sure people know when it's popular. Get it into as many systems as possible. Earn "street cred." Minimize the number of reasons why potential users or companies may turn away. Hint: an obscure or contentious license can be an instant dealbreaker.</p>
<p>Choose a standard open source license whenever possible. The legal structures and processes within large companies are set up to allow them more easily. You can use this to your advantage by getting your project into as many systems as possible. The more embedded, utilized, and depended upon your project is, the more potential you have for leveraging the project to sustain itself. Use "copyleft" (GPL/AGPL) only if you want to sell proprietary licenses to companies; otherwise they will not use your software, period. That's a valid strategy, but I have found more success in having my software spread "everywhere" first, then leveraging that to sell sponsorships. Sponsorships don't sell well in a vacuum: they need a network, a community. That also implies fostering a community around the project, which also takes time.</p>
<p>Some sponsors will want to develop an active relationship, but you'll find that the vast majority just want you to keep doing what you're doing and won't ask anything special. I've found that most sponsors don't even take advantage of the perks available to them. That's OK, as it makes me more productive, which is what they want.</p>
<p>It may take years of tuning for you to settle on sponsorship offerings that work for you and your market. That's OK! Remember, the main idea here is to own your sponsorship plans (rather than just accepting donations), and to make what you do offer compelling to your market (whether that be consumers, professionals, or businesses).</p>

+ 204
- 0
cache/2022/ed0eff49e75f35733437d71da03b0af3/index.html View File

@@ -0,0 +1,204 @@
<!doctype html><!-- This is a valid HTML5 document. -->
<!-- Screen readers, SEO, extensions and so on. -->
<html lang="fr">
<!-- Has to be within the first 1024 bytes, hence before the `title` element
See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
<meta charset="utf-8">
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
<!-- The viewport meta is quite crowded and we are responsible for that.
See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
<meta name="viewport" content="width=device-width,initial-scale=1">
<!-- Required to make a valid HTML5 document. -->
<title>Sustaining Maintaining (archive) — David Larlet</title>
<meta name="description" content="Publication mise en cache pour en conserver une trace.">
<!-- That good ol' feed, subscribe :). -->
<link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/">
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png">
<link rel="manifest" href="/static/david/icons2/site.webmanifest">
<link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c">
<link rel="shortcut icon" href="/static/david/icons2/favicon.ico">
<meta name="msapplication-TileColor" content="#f7f7f7">
<meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml">
<meta name="theme-color" content="#f7f7f7" media="(prefers-color-scheme: light)">
<meta name="theme-color" content="#272727" media="(prefers-color-scheme: dark)">
<!-- Documented, feel free to shoot an email. -->
<link rel="stylesheet" href="/static/david/css/style_2021-01-20.css">
<!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. -->
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<script>
function toggleTheme(themeName) {
document.documentElement.classList.toggle(
'forced-dark',
themeName === 'dark'
)
document.documentElement.classList.toggle(
'forced-light',
themeName === 'light'
)
}
const selectedTheme = localStorage.getItem('theme')
if (selectedTheme !== 'undefined') {
toggleTheme(selectedTheme)
}
</script>

<meta name="robots" content="noindex, nofollow">
<meta content="origin-when-cross-origin" name="referrer">
<!-- Canonical URL for SEO purposes -->
<link rel="canonical" href="https://daverupert.com/2021/12/sustaining-maintaining/">

<body class="remarkdown h1-underline h2-underline h3-underline em-underscore hr-center ul-star pre-tick" data-instant-intensity="viewport-all">


<article>
<header>
<h1>Sustaining Maintaining</h1>
</header>
<nav>
<p class="center">
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="https://daverupert.com/2021/12/sustaining-maintaining/" title="Lien vers le contenu original">Source originale</a>
</p>
</nav>
<hr>
<p>You see it all the time; a repo with a thousand issues, a hundred open PRs, a thousand forks. <code>v2.0</code> is on the way but there’s no clear roadmap or communication. Those of us who have worked on open source can spot it, burnout is afoot. The project got bigger than what the person or organization could realistically maintain. The maintainers are too busy or too burnt out to get the project back on track.</p>
<p>My open source burnout saga is pretty standard. My coworkers and I made a jQuery plugin that solved a hole in the web platform. It got pretty popular, and we made another one, and another one. Then the issues started pouring in; the surprise refactors, the undiscussed feature drops, the commit stat beefers, the good ideas I don’t have time for, the bad ideas I don’t know how to say “no” to, and the endless “this doesn’t work and you’re a bad human” support requests.</p>
<p>The critical issue for me was that open source was counter-cyclical to my life. I’d open source in slow times, but couldn’t manage client work and open source work in busy times. Out of principle we don’t work on weekends at Paravel… but people on GitHub sure do! Every Monday morning my inbox would be full of crushing guilt and neglected responsibility as issues piled up on my projects.</p>
<p>For every issue closed, three new issues showed up. I love open source, but it felt endless and unmanageable. As burnout encroached, I went into self-preservation mode. I did a bit here and there, but sought refuge for my mental health in video games and comic books instead of working nights and weekends. Years went by and having children deleted any concept of spare time.</p>
<p>It would be great if I had more time! But time requires money. Sentry and GitHub hosted a panel this week called “<a href="https://www.youtube.com/watch?v=dodos1n1-As">The Future of Open Source: Is It Sustainable?</a>” which was a candid discussion about funding. There’s different shapes funding can take, but most open source funding happens through either a dedicated employer, support contracts, a crowdfunding tip jar, or a foundation; the unifying factor seems to be maintainers get paid. Money helps make open source sustainable.</p>
<p>But financials are one part of the sustainable open source equation. There’s an emotional cost to having a publicly available project that hundreds or thousands of people and companies depend on as well. One of the best talks I’ve heard on open source maintenance and one I reference often is Jacob Thornton’s 2012 dotJS talk “<a href="https://www.youtube.com/watch?v=UIDb6VBO9os">What Is Open Source &amp; Why Do I Feel So Guilty?</a>”</p>

<p>From the old Xerox PARC days to the open sourcing of Netscape in 1998 (which was the first use of the term “open source”) to the modern day <code>npm install whatever-i-want</code>; open source has come a long way. In ye olde times, we downloaded shareware from Sourceforge which was an effective way to install malware on your computer. GitHub’s launch in 2008 fundamentally changed how we build, share, and distribute software. It has even turned a proprietary titan like Microsoft into an open source advocate. <a href="https://onezero.medium.com/the-internet-relies-on-people-working-for-free-a79104a68bcc">The internet relies on people working for free</a>.</p>
<p>Towards the end of the talk, Thornton gets to the heart of the issue:</p>
<blockquote>
<p>With the acceleration of GitHub making everything more efficient, making everything easier and easier, the time to burnout is accelerating at a break neck pace.</p>
</blockquote>
<p>“Burnout”. There’s the word.</p>
<p>I sometimes wonder why a company like GitHub doesn’t offer educational, financial, or organizational support to maintainers. <a href="https://lab.github.com/">There’s plenty of write-ups on GitHub</a> about <em>how to start</em> a new open source project, or <em>how to add tooling</em>, but almost no information or best practices on <em>how to maintain</em> a project over years. I think there’s a big education gap and opportunity here. GitHub has an obvious incentive to increase <code>num_developers</code> and <code>num_repos</code>, but I think it’s worthwhile to ease the burden of existing developers and increase the quality and security of existing repos. Open source maintenance needs a manual.</p>
<p>If I were to spitball some chapter titles or sections for a manual, it’d look like this:</p>
<ul>
<li>Differentiating between support requests and Issues</li>
<li>Issue management (issue templates, labels, sticky issues, closing strategies)</li>
<li>How to handle volume without losing your soul</li>
<li>Landing pull requests from strangers (security concerns, etc)</li>
<li>Setting up testing and continuous integration</li>
<li>How to get Sponsors</li>
<li>How and why to use Discussions</li>
<li>How and why to use Projects and Milestones</li>
<li>How to write good documentation</li>
<li>Setting boundaries and office hours</li>
<li>Effective and clear communication</li>
<li>Choosing an open source business model</li>
</ul>
<p>Or what about offering in-person support? Developer Advocates could offer this list of services to project maintainers in exchange for livestream or video content. I’d love to see more content where existing projects get help on tooling or process instead of always starting from a blank repo. Call it “Pimp My Repo”, get Xzibit to host, sell it to MTV. I’d watch it. I’d also watch interviews with successful maintainers to learn about their maintenance routines. It’d be beneficial to the open source community as a whole to replace the starving artist —slash— burnt out maintainer trope with chilled out maintainers who have a good work/life balance.</p>
<p>I think there’s also a lot of opportunity for lessons in Open Source Citizenship education as well. Instead of endless “Fuck you, fix my project” requests, there’s some hoops to jump through, some education, some reminder that there’s <strong>humans working for free</strong> on the other side of that comment box. <code>CONTRIBUTING.md</code> is a good step but contrast that with something like Discord’s welcome screen feature where you have to read and agree with a code of conduct before you can contribute. Anything to curb the entitlement and abuse is welcome. Onboarding people to the proper etiquette for filing a good bug report with proper repro steps or a reduced test case would go miles.</p>
<p>There’s also another idea out there: a “Pay to Engage” model. You can read all the code, all the commits, all the issues, all the discussions, fork it, clone it, but if you want to engage and ask for help, you need to pay. Pay to Engage isn’t for every project and could hinder some projects, but it could unlock some sustainability.</p>
<p>These are ideas, I probably have a million more. And you probably have a million as well. I’d love to read your blog posts about it. If you maintain an open source project, what’s been successful for you on the marathon? What’s worked? What hasn’t? My weary soul wants to know.</p>
</article>


<hr>

<footer>
<p>
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="/david/log/" title="Accès au flux RSS"><svg class="icon icon-rss2">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-rss2"></use>
</svg> Suivre</a> •
<a href="http://larlet.com" title="Go to my English profile" data-instant><svg class="icon icon-user-tie">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-user-tie"></use>
</svg> Pro</a> •
<a href="mailto:david%40larlet.fr" title="Envoyer un courriel"><svg class="icon icon-mail">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-mail"></use>
</svg> Email</a> •
<abbr class="nowrap" title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340"><svg class="icon icon-hammer2">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-hammer2"></use>
</svg> Légal</abbr>
</p>
<template id="theme-selector">
<form>
<fieldset>
<legend><svg class="icon icon-brightness-contrast">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-brightness-contrast"></use>
</svg> Thème</legend>
<label>
<input type="radio" value="auto" name="chosen-color-scheme" checked> Auto
</label>
<label>
<input type="radio" value="dark" name="chosen-color-scheme"> Foncé
</label>
<label>
<input type="radio" value="light" name="chosen-color-scheme"> Clair
</label>
</fieldset>
</form>
</template>
</footer>
<script src="/static/david/js/instantpage-5.1.0.min.js" type="module"></script>
<script>
function loadThemeForm(templateName) {
const themeSelectorTemplate = document.querySelector(templateName)
const form = themeSelectorTemplate.content.firstElementChild
themeSelectorTemplate.replaceWith(form)

form.addEventListener('change', (e) => {
const chosenColorScheme = e.target.value
localStorage.setItem('theme', chosenColorScheme)
toggleTheme(chosenColorScheme)
})

const selectedTheme = localStorage.getItem('theme')
if (selectedTheme && selectedTheme !== 'undefined') {
form.querySelector(`[value="${selectedTheme}"]`).checked = true
}
}

const prefersColorSchemeDark = '(prefers-color-scheme: dark)'
window.addEventListener('load', () => {
let hasDarkRules = false
for (const styleSheet of Array.from(document.styleSheets)) {
let mediaRules = []
for (const cssRule of styleSheet.cssRules) {
if (cssRule.type !== CSSRule.MEDIA_RULE) {
continue
}
// WARNING: Safari does not have/supports `conditionText`.
if (cssRule.conditionText) {
if (cssRule.conditionText !== prefersColorSchemeDark) {
continue
}
} else {
if (cssRule.cssText.startsWith(prefersColorSchemeDark)) {
continue
}
}
mediaRules = mediaRules.concat(Array.from(cssRule.cssRules))
}

// WARNING: do not try to insert a Rule to a styleSheet you are
// currently iterating on, otherwise the browser will be stuck
// in a infinite loop…
for (const mediaRule of mediaRules) {
styleSheet.insertRule(mediaRule.cssText)
hasDarkRules = true
}
}
if (hasDarkRules) {
loadThemeForm('#theme-selector')
}
})
</script>
</body>
</html>

+ 37
- 0
cache/2022/ed0eff49e75f35733437d71da03b0af3/index.md View File

@@ -0,0 +1,37 @@
title: Sustaining Maintaining
url: https://daverupert.com/2021/12/sustaining-maintaining/
hash_url: ed0eff49e75f35733437d71da03b0af3

<p>You see it all the time; a repo with a thousand issues, a hundred open PRs, a thousand forks. <code>v2.0</code> is on the way but there’s no clear roadmap or communication. Those of us who have worked on open source can spot it, burnout is afoot. The project got bigger than what the person or organization could realistically maintain. The maintainers are too busy or too burnt out to get the project back on track.</p>
<p>My open source burnout saga is pretty standard. My coworkers and I made a jQuery plugin that solved a hole in the web platform. It got pretty popular, and we made another one, and another one. Then the issues started pouring in; the surprise refactors, the undiscussed feature drops, the commit stat beefers, the good ideas I don’t have time for, the bad ideas I don’t know how to say “no” to, and the endless “this doesn’t work and you’re a bad human” support requests.</p>
<p>The critical issue for me was that open source was counter-cyclical to my life. I’d open source in slow times, but couldn’t manage client work and open source work in busy times. Out of principle we don’t work on weekends at Paravel… but people on GitHub sure do! Every Monday morning my inbox would be full of crushing guilt and neglected responsibility as issues piled up on my projects.</p>
<p>For every issue closed, three new issues showed up. I love open source, but it felt endless and unmanageable. As burnout encroached, I went into self-preservation mode. I did a bit here and there, but sought refuge for my mental health in video games and comic books instead of working nights and weekends. Years went by and having children deleted any concept of spare time.</p>
<p>It would be great if I had more time! But time requires money. Sentry and GitHub hosted a panel this week called “<a href="https://www.youtube.com/watch?v=dodos1n1-As">The Future of Open Source: Is It Sustainable?</a>” which was a candid discussion about funding. There’s different shapes funding can take, but most open source funding happens through either a dedicated employer, support contracts, a crowdfunding tip jar, or a foundation; the unifying factor seems to be maintainers get paid. Money helps make open source sustainable.</p>
<p>But financials are one part of the sustainable open source equation. There’s an emotional cost to having a publicly available project that hundreds or thousands of people and companies depend on as well. One of the best talks I’ve heard on open source maintenance and one I reference often is Jacob Thornton’s 2012 dotJS talk “<a href="https://www.youtube.com/watch?v=UIDb6VBO9os">What Is Open Source &amp; Why Do I Feel So Guilty?</a>”</p>

<p>From the old Xerox PARC days to the open sourcing of Netscape in 1998 (which was the first use of the term “open source”) to the modern day <code>npm install whatever-i-want</code>; open source has come a long way. In ye olde times, we downloaded shareware from Sourceforge which was an effective way to install malware on your computer. GitHub’s launch in 2008 fundamentally changed how we build, share, and distribute software. It has even turned a proprietary titan like Microsoft into an open source advocate. <a href="https://onezero.medium.com/the-internet-relies-on-people-working-for-free-a79104a68bcc">The internet relies on people working for free</a>.</p>
<p>Towards the end of the talk, Thornton gets to the heart of the issue:</p>
<blockquote>
<p>With the acceleration of GitHub making everything more efficient, making everything easier and easier, the time to burnout is accelerating at a break neck pace.</p>
</blockquote>
<p>“Burnout”. There’s the word.</p>
<p>I sometimes wonder why a company like GitHub doesn’t offer educational, financial, or organizational support to maintainers. <a href="https://lab.github.com/">There’s plenty of write-ups on GitHub</a> about <em>how to start</em> a new open source project, or <em>how to add tooling</em>, but almost no information or best practices on <em>how to maintain</em> a project over years. I think there’s a big education gap and opportunity here. GitHub has an obvious incentive to increase <code>num_developers</code> and <code>num_repos</code>, but I think it’s worthwhile to ease the burden of existing developers and increase the quality and security of existing repos. Open source maintenance needs a manual.</p>
<p>If I were to spitball some chapter titles or sections for a manual, it’d look like this:</p>
<ul>
<li>Differentiating between support requests and Issues</li>
<li>Issue management (issue templates, labels, sticky issues, closing strategies)</li>
<li>How to handle volume without losing your soul</li>
<li>Landing pull requests from strangers (security concerns, etc)</li>
<li>Setting up testing and continuous integration</li>
<li>How to get Sponsors</li>
<li>How and why to use Discussions</li>
<li>How and why to use Projects and Milestones</li>
<li>How to write good documentation</li>
<li>Setting boundaries and office hours</li>
<li>Effective and clear communication</li>
<li>Choosing an open source business model</li>
</ul>
<p>Or what about offering in-person support? Developer Advocates could offer this list of services to project maintainers in exchange for livestream or video content. I’d love to see more content where existing projects get help on tooling or process instead of always starting from a blank repo. Call it “Pimp My Repo”, get Xzibit to host, sell it to MTV. I’d watch it. I’d also watch interviews with successful maintainers to learn about their maintenance routines. It’d be beneficial to the open source community as a whole to replace the starving artist —slash— burnt out maintainer trope with chilled out maintainers who have a good work/life balance.</p>
<p>I think there’s also a lot of opportunity for lessons in Open Source Citizenship education as well. Instead of endless “Fuck you, fix my project” requests, there’s some hoops to jump through, some education, some reminder that there’s <strong>humans working for free</strong> on the other side of that comment box. <code>CONTRIBUTING.md</code> is a good step but contrast that with something like Discord’s welcome screen feature where you have to read and agree with a code of conduct before you can contribute. Anything to curb the entitlement and abuse is welcome. Onboarding people to the proper etiquette for filing a good bug report with proper repro steps or a reduced test case would go miles.</p>
<p>There’s also another idea out there: a “Pay to Engage” model. You can read all the code, all the commits, all the issues, all the discussions, fork it, clone it, but if you want to engage and ask for help, you need to pay. Pay to Engage isn’t for every project and could hinder some projects, but it could unlock some sustainability.</p>
<p>These are ideas, I probably have a million more. And you probably have a million as well. I’d love to read your blog posts about it. If you maintain an open source project, what’s been successful for you on the marathon? What’s worked? What hasn’t? My weary soul wants to know.</p>

+ 300
- 0
cache/2022/f57abf8bb9e96e5cb5cfe845d76729f5/index.html View File

@@ -0,0 +1,300 @@
<!doctype html><!-- This is a valid HTML5 document. -->
<!-- Screen readers, SEO, extensions and so on. -->
<html lang="fr">
<!-- Has to be within the first 1024 bytes, hence before the `title` element
See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
<meta charset="utf-8">
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
<!-- The viewport meta is quite crowded and we are responsible for that.
See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
<meta name="viewport" content="width=device-width,initial-scale=1">
<!-- Required to make a valid HTML5 document. -->
<title>“Open Source” is Broken (archive) — David Larlet</title>
<meta name="description" content="Publication mise en cache pour en conserver une trace.">
<!-- That good ol' feed, subscribe :). -->
<link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/">
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png">
<link rel="manifest" href="/static/david/icons2/site.webmanifest">
<link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c">
<link rel="shortcut icon" href="/static/david/icons2/favicon.ico">
<meta name="msapplication-TileColor" content="#f7f7f7">
<meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml">
<meta name="theme-color" content="#f7f7f7" media="(prefers-color-scheme: light)">
<meta name="theme-color" content="#272727" media="(prefers-color-scheme: dark)">
<!-- Documented, feel free to shoot an email. -->
<link rel="stylesheet" href="/static/david/css/style_2021-01-20.css">
<!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. -->
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<script>
function toggleTheme(themeName) {
document.documentElement.classList.toggle(
'forced-dark',
themeName === 'dark'
)
document.documentElement.classList.toggle(
'forced-light',
themeName === 'light'
)
}
const selectedTheme = localStorage.getItem('theme')
if (selectedTheme !== 'undefined') {
toggleTheme(selectedTheme)
}
</script>

<meta name="robots" content="noindex, nofollow">
<meta content="origin-when-cross-origin" name="referrer">
<!-- Canonical URL for SEO purposes -->
<link rel="canonical" href="https://christine.website/blog/open-source-broken-2021-12-11">

<body class="remarkdown h1-underline h2-underline h3-underline em-underscore hr-center ul-star pre-tick" data-instant-intensity="viewport-all">


<article>
<header>
<h1>“Open Source” is Broken</h1>
</header>
<nav>
<p class="center">
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="https://christine.website/blog/open-source-broken-2021-12-11" title="Lien vers le contenu original">Source originale</a>
</p>
</nav>
<hr>
<p>or: Why I Don't Write Useful Software Unless You Pay Me</p>
<p>Recently there was a <a href="https://www.lunasec.io/docs/blog/log4j-zero-day/">massive
vulnerability</a> found in a
critical Java ecosystem package. When fully weaponized, this allows attackers to
coerce Java servers into executing arbitrary code that was fetched from an LDAP
server.</p>
<p></p>
<div class="conversation">

<p class="conversation-chat">&lt;<b>Mara</b>&gt; If this is news to you and you work at a Java shop, I'm sorry but you have a
long couple days ahead.</p>
</div>

<p>I believe this is a perfect microcosm of all of the major ecosystem problems
with "Open Source" software. I have some thoughts about all this, as I think
log4j2 is a <em>perfect</em> example of one of the worst case scenarios for this. It is
perfectly reasonable for everyone involved in this issue to have done all this
for perfectly valid solutions to real-world problems and this also to have
created a massive hole on accident in the process.</p>
<p><center></p>
<p><img src="https://imgs.xkcd.com/comics/dependency.png" alt='the XKCD comic "Dependency", depicting all modern digital infrastructure being held up by some random project made by a thankless anonymous person in Nebraska.'></p>
<p><a href="https://xkcd.com/2347/">XKCD #2347: Dependency</a></p>
<p></center></p>
<p>All software is made on top of the shoulders of giants. Consider something as
basic as running an SSH server on the Linux kernel. In the mix you would have at
least 10 vendors (assuming a minimal Alpine Linux system in its default
configuration), which means that there are at least 10 separate organizations
that still have bills to pay with actual money dollars regardless of the number
of users of the software they are giving away for free. Alpine Linux is also a
great example of this because it is used frequently in Docker contexts to power
many, many companies in production. How many of those companies do you think
fund the Alpine Linux project? How many of those companies do you think even
would even THINK about funding the Alpine Linux project?</p>
<p>I've had this kind of conversation with people before and I've gotten a
surprising amount of resistance to the prospect of actually making sure that the
random smattering of volunteers that LITERALLY MAKE THEIR COMPANY RUN are able
to make rent. There is this culture of taking from open source without giving
anything back. It is like the problems of the people who make the dependencies
are irrelevant.</p>
<p><center></p>
<p><img src="https://christine.website/static/blog/5xi3x7.jpg" alt="A meme based on the Tim and Eric &quot;It's free real estate&quot; template contrasting the idea of open source software maintained by passionate developers with a heartless taking without giving attitude"></p>
<p></center></p>
<p>GitHub stars famously cannot be used to pay rent. An example of this is the
<a href="https://github.com/zloirock/core-js/issues/767"><code>core-js</code> debacle</a>. <code>core-js</code>
is a JavaScript library that gives JavaScript's standard library a lot of core
primitives that can make you not need to reach out to other libraries. This
library is also infamous for letting you know that the author is looking for a
job every time you install it in CI. You probably have seen this message in your
CI a thousand times:</p>
<pre><code>
<span>Thank you for using core-js ( https://github.com/zloirock/core-js ) for
</span><span>polyfilling JavaScript standard library!
</span><span>
</span><span>The project needs your help! Please consider supporting of core-js on Open
</span><span>Collective or Patreon:
</span><span>&gt; https://opencollective.com/core-js
</span><span>&gt; https://www.patreon.com/zloirock
</span><span>
</span><span>Also, the author of core-js ( https://github.com/zloirock ) is looking for a
</span><span>good job :-)
</span>
</code></pre>
<p>The author of the project is either still in prison for vehicular manslaughter
or has just been released. <code>core-js</code> is a dependency of React. How many of you
have actually donated to this project? Especially if you use React?</p>
<p>Now let's turn our eyes to <code>log4j2</code>. This project is effectively in the standard
library for Java users. This library is so ingrained into modern Java that
you'd expect the developers of it would be well-funded and not need to focus on
anything else but that library, right?</p>
<p>No.</p>
<p><center> </center></p>
<p>As of yesterday, there were a grand total of three sponsors for this person's
work. THREE. As of today, this number is now 14; however this is no excuse. This
person should be funded in a level that is appropriate for how critical <code>log4j2</code>
is used in the ecosystem. There is no excuse for this. This person's <em>spare time
passion project</em> is responsible for half of the internet working the way it
should. Vulnerable companies to this issue included Apple, Google, my cell phone
carrier and basically everyone that uses JavaEE in its default configuration.</p>
<p></p>
<div class="conversation">

<p class="conversation-chat">&lt;<b>Cadey</b>&gt; Seriously, I could trigger some part of my cell carrier's infra reaching
out to a DNS server with a specially crafted SMS
message.</p>
</div>

<p>If <code>log4j2</code> is responsible for your company's success, you have a moral
obligation to <a href="https://github.com/sponsors/rgoers">donate to the person who creates this library
thanklessly</a>.</p>
<p></p>
<div class="conversation">

<p class="conversation-chat">&lt;<b>Numa</b>&gt; As for the problem that created this vulnerability in the first place: what
where they THINKING when they allowed user-submitted untrusted strings to
contain JDNI references that would then cause the JVM to load arbitrary bytecode
into ram and then run it without having to specify that in the format string to
begin with? Like why would you even need to do that in the <em>user-supplied</em> part
of the format string? What would this even accomplish other than being a great
way to get a shell whenever you wanted?</p>
</div>

<p>There is a friend of mine who has been thanklessly maintaining an online radio
station stack for a long time. He has been abused by his users. Users will throw
5 bucks in the tip jar and then get very angry when he doesn't drop everything
and fix their incredibly specific problems on a moment's notice. He has tried to
get jobs at places, but every time they keep trying to screw him out of
ownership of his own projects and he has to turn them down. Meanwhile the cash
bleed continues.</p>
<p>This is why I am very careful about how I make "useful" software and release it
to the world without any solid way for me to get paid for my efforts. I simply
do not want to be in a situation where my software that I develop as a passion
project on the side is holding people's companies together. That's why I make
software how and where I do. Like, no offense, but I really do not want to go
unpaid for my efforts. The existing leech culture of "Open Source" being a pool
of free labor makes it hard for me to want to have my side projects be actually
useful like that unless you pay me.</p>
<p></p>
<div class="conversation">

<p class="conversation-chat">&lt;<b>Cadey</b>&gt; Okay, part of this may also be an ADHD thing and not really being able to stick
to projects longer term.</p>
</div>

<p>TL;DR: If you want me to make you useful software, pay me. If you use software
made by others in their spare time and find it useful, pay them. This should not
be a controversial opinion. This should not be a new thing. This should already
be the state of the world and it is amazingly horrible for us to have the people
that make the things that make our software work at all starve and beg for
donations.</p>
</article>


<hr>

<footer>
<p>
<a href="/david/" title="Aller à l’accueil"><svg class="icon icon-home">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-home"></use>
</svg> Accueil</a> •
<a href="/david/log/" title="Accès au flux RSS"><svg class="icon icon-rss2">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-rss2"></use>
</svg> Suivre</a> •
<a href="http://larlet.com" title="Go to my English profile" data-instant><svg class="icon icon-user-tie">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-user-tie"></use>
</svg> Pro</a> •
<a href="mailto:david%40larlet.fr" title="Envoyer un courriel"><svg class="icon icon-mail">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-mail"></use>
</svg> Email</a> •
<abbr class="nowrap" title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340"><svg class="icon icon-hammer2">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-hammer2"></use>
</svg> Légal</abbr>
</p>
<template id="theme-selector">
<form>
<fieldset>
<legend><svg class="icon icon-brightness-contrast">
<use xlink:href="/static/david/icons2/symbol-defs-2021-12.svg#icon-brightness-contrast"></use>
</svg> Thème</legend>
<label>
<input type="radio" value="auto" name="chosen-color-scheme" checked> Auto
</label>
<label>
<input type="radio" value="dark" name="chosen-color-scheme"> Foncé
</label>
<label>
<input type="radio" value="light" name="chosen-color-scheme"> Clair
</label>
</fieldset>
</form>
</template>
</footer>
<script src="/static/david/js/instantpage-5.1.0.min.js" type="module"></script>
<script>
function loadThemeForm(templateName) {
const themeSelectorTemplate = document.querySelector(templateName)
const form = themeSelectorTemplate.content.firstElementChild
themeSelectorTemplate.replaceWith(form)

form.addEventListener('change', (e) => {
const chosenColorScheme = e.target.value
localStorage.setItem('theme', chosenColorScheme)
toggleTheme(chosenColorScheme)
})

const selectedTheme = localStorage.getItem('theme')
if (selectedTheme && selectedTheme !== 'undefined') {
form.querySelector(`[value="${selectedTheme}"]`).checked = true
}
}

const prefersColorSchemeDark = '(prefers-color-scheme: dark)'
window.addEventListener('load', () => {
let hasDarkRules = false
for (const styleSheet of Array.from(document.styleSheets)) {
let mediaRules = []
for (const cssRule of styleSheet.cssRules) {
if (cssRule.type !== CSSRule.MEDIA_RULE) {
continue
}
// WARNING: Safari does not have/supports `conditionText`.
if (cssRule.conditionText) {
if (cssRule.conditionText !== prefersColorSchemeDark) {
continue
}
} else {
if (cssRule.cssText.startsWith(prefersColorSchemeDark)) {
continue
}
}
mediaRules = mediaRules.concat(Array.from(cssRule.cssRules))
}

// WARNING: do not try to insert a Rule to a styleSheet you are
// currently iterating on, otherwise the browser will be stuck
// in a infinite loop…
for (const mediaRule of mediaRules) {
styleSheet.insertRule(mediaRule.cssText)
hasDarkRules = true
}
}
if (hasDarkRules) {
loadThemeForm('#theme-selector')
}
})
</script>
</body>
</html>

+ 129
- 0
cache/2022/f57abf8bb9e96e5cb5cfe845d76729f5/index.md View File

@@ -0,0 +1,129 @@
title: “Open Source” is Broken
url: https://christine.website/blog/open-source-broken-2021-12-11
hash_url: f57abf8bb9e96e5cb5cfe845d76729f5

<p>or: Why I Don't Write Useful Software Unless You Pay Me</p>
<p>Recently there was a <a href="https://www.lunasec.io/docs/blog/log4j-zero-day/">massive
vulnerability</a> found in a
critical Java ecosystem package. When fully weaponized, this allows attackers to
coerce Java servers into executing arbitrary code that was fetched from an LDAP
server.</p>
<p></p><div class="conversation">

<p class="conversation-chat">&lt;<b>Mara</b>&gt; If this is news to you and you work at a Java shop, I'm sorry but you have a
long couple days ahead.</p>
</div>

<p>I believe this is a perfect microcosm of all of the major ecosystem problems
with "Open Source" software. I have some thoughts about all this, as I think
log4j2 is a <em>perfect</em> example of one of the worst case scenarios for this. It is
perfectly reasonable for everyone involved in this issue to have done all this
for perfectly valid solutions to real-world problems and this also to have
created a massive hole on accident in the process.</p>
<center>
<p><img src="https://imgs.xkcd.com/comics/dependency.png" alt='the XKCD comic "Dependency", depicting all modern digital infrastructure being held up by some random project made by a thankless anonymous person in Nebraska.'></p>
<p><a href="https://xkcd.com/2347/">XKCD #2347: Dependency</a></p>
</center>
<p>All software is made on top of the shoulders of giants. Consider something as
basic as running an SSH server on the Linux kernel. In the mix you would have at
least 10 vendors (assuming a minimal Alpine Linux system in its default
configuration), which means that there are at least 10 separate organizations
that still have bills to pay with actual money dollars regardless of the number
of users of the software they are giving away for free. Alpine Linux is also a
great example of this because it is used frequently in Docker contexts to power
many, many companies in production. How many of those companies do you think
fund the Alpine Linux project? How many of those companies do you think even
would even THINK about funding the Alpine Linux project?</p>
<p>I've had this kind of conversation with people before and I've gotten a
surprising amount of resistance to the prospect of actually making sure that the
random smattering of volunteers that LITERALLY MAKE THEIR COMPANY RUN are able
to make rent. There is this culture of taking from open source without giving
anything back. It is like the problems of the people who make the dependencies
are irrelevant.</p>
<center>
<p><img src="https://christine.website/static/blog/5xi3x7.jpg" alt="A meme based on the Tim and Eric &quot;It's free real estate&quot; template contrasting the idea of open source software maintained by passionate developers with a heartless taking without giving attitude"></p>
</center>
<p>GitHub stars famously cannot be used to pay rent. An example of this is the
<a href="https://github.com/zloirock/core-js/issues/767"><code>core-js</code> debacle</a>. <code>core-js</code>
is a JavaScript library that gives JavaScript's standard library a lot of core
primitives that can make you not need to reach out to other libraries. This
library is also infamous for letting you know that the author is looking for a
job every time you install it in CI. You probably have seen this message in your
CI a thousand times:</p>
<pre><code>
<span>Thank you for using core-js ( https://github.com/zloirock/core-js ) for
</span><span>polyfilling JavaScript standard library!
</span><span>
</span><span>The project needs your help! Please consider supporting of core-js on Open
</span><span>Collective or Patreon:
</span><span>&gt; https://opencollective.com/core-js
</span><span>&gt; https://www.patreon.com/zloirock
</span><span>
</span><span>Also, the author of core-js ( https://github.com/zloirock ) is looking for a
</span><span>good job :-)
</span>
</code></pre>
<p>The author of the project is either still in prison for vehicular manslaughter
or has just been released. <code>core-js</code> is a dependency of React. How many of you
have actually donated to this project? Especially if you use React?</p>
<p>Now let's turn our eyes to <code>log4j2</code>. This project is effectively in the standard
library for Java users. This library is so ingrained into modern Java that
you'd expect the developers of it would be well-funded and not need to focus on
anything else but that library, right?</p>
<p>No.</p>
<center> </center>
<p>As of yesterday, there were a grand total of three sponsors for this person's
work. THREE. As of today, this number is now 14; however this is no excuse. This
person should be funded in a level that is appropriate for how critical <code>log4j2</code>
is used in the ecosystem. There is no excuse for this. This person's <em>spare time
passion project</em> is responsible for half of the internet working the way it
should. Vulnerable companies to this issue included Apple, Google, my cell phone
carrier and basically everyone that uses JavaEE in its default configuration.</p>
<p></p><div class="conversation">

<p class="conversation-chat">&lt;<b>Cadey</b>&gt; Seriously, I could trigger some part of my cell carrier's infra reaching
out to a DNS server with a specially crafted SMS
message.</p>
</div>

<p>If <code>log4j2</code> is responsible for your company's success, you have a moral
obligation to <a href="https://github.com/sponsors/rgoers">donate to the person who creates this library
thanklessly</a>.</p>
<p></p><div class="conversation">

<p class="conversation-chat">&lt;<b>Numa</b>&gt; As for the problem that created this vulnerability in the first place: what
where they THINKING when they allowed user-submitted untrusted strings to
contain JDNI references that would then cause the JVM to load arbitrary bytecode
into ram and then run it without having to specify that in the format string to
begin with? Like why would you even need to do that in the <em>user-supplied</em> part
of the format string? What would this even accomplish other than being a great
way to get a shell whenever you wanted?</p>
</div>

<p>There is a friend of mine who has been thanklessly maintaining an online radio
station stack for a long time. He has been abused by his users. Users will throw
5 bucks in the tip jar and then get very angry when he doesn't drop everything
and fix their incredibly specific problems on a moment's notice. He has tried to
get jobs at places, but every time they keep trying to screw him out of
ownership of his own projects and he has to turn them down. Meanwhile the cash
bleed continues.</p>
<p>This is why I am very careful about how I make "useful" software and release it
to the world without any solid way for me to get paid for my efforts. I simply
do not want to be in a situation where my software that I develop as a passion
project on the side is holding people's companies together. That's why I make
software how and where I do. Like, no offense, but I really do not want to go
unpaid for my efforts. The existing leech culture of "Open Source" being a pool
of free labor makes it hard for me to want to have my side projects be actually
useful like that unless you pay me.</p>
<p></p><div class="conversation">

<p class="conversation-chat">&lt;<b>Cadey</b>&gt; Okay, part of this may also be an ADHD thing and not really being able to stick
to projects longer term.</p>
</div>

<p>TL;DR: If you want me to make you useful software, pay me. If you use software
made by others in their spare time and find it useful, pay them. This should not
be a controversial opinion. This should not be a new thing. This should already
be the state of the world and it is amazingly horrible for us to have the people
that make the things that make our software work at all starve and beg for
donations.</p>

+ 36
- 0
cache/2022/index.html View File

@@ -77,10 +77,14 @@
<li><a href="/david/cache/2022/539f9f951e0d3ba9024f3b837941372f/" title="Accès à l’article dans le cache local : Ce qui compte">Ce qui compte</a> (<a href="https://olivier.thereaux.net/2021/Ce-qui-compte/" title="Accès à l’article original distant : Ce qui compte">original</a>)</li>
<li><a href="/david/cache/2022/0dc625e86fb8e680308250b1245f1086/" title="Accès à l’article dans le cache local : What makes writing more readable?">What makes writing more readable?</a> (<a href="https://pudding.cool/2022/02/plain/" title="Accès à l’article original distant : What makes writing more readable?">original</a>)</li>
<li><a href="/david/cache/2022/0a53d8dedc371884d16f45bcb349b418/" title="Accès à l’article dans le cache local : BALLAST • QUE FAIRE ?">BALLAST • QUE FAIRE ?</a> (<a href="https://www.revue-ballast.fr/que-faire/" title="Accès à l’article original distant : BALLAST • QUE FAIRE ?">original</a>)</li>
<li><a href="/david/cache/2022/65e0c481f692260299c53e9713339f53/" title="Accès à l’article dans le cache local : Ce dont nous avons (vraiment) besoin">Ce dont nous avons (vraiment) besoin</a> (<a href="https://www.monde-diplomatique.fr/2017/02/KEUCHEYAN/57134" title="Accès à l’article original distant : Ce dont nous avons (vraiment) besoin">original</a>)</li>
<li><a href="/david/cache/2022/b17f8ac80615c86cade89dd81c8aa50b/" title="Accès à l’article dans le cache local : Server-Sent Events: the alternative to WebSockets you should be using">Server-Sent Events: the alternative to WebSockets you should be using</a> (<a href="https://germano.dev/sse-websockets/#comments" title="Accès à l’article original distant : Server-Sent Events: the alternative to WebSockets you should be using">original</a>)</li>
<li><a href="/david/cache/2022/622620656409b4f687cab890288a0a01/" title="Accès à l’article dans le cache local : Who can be the Netflix of ghost kitchens?">Who can be the Netflix of ghost kitchens?</a> (<a href="https://interconnected.org/home/2022/01/24/meme_meals" title="Accès à l’article original distant : Who can be the Netflix of ghost kitchens?">original</a>)</li>
<li><a href="/david/cache/2022/987e2e450e3e88d0d6d18ec6e6a44b95/" title="Accès à l’article dans le cache local : Habiter sans posséder, tel est l’antidote">Habiter sans posséder, tel est l’antidote</a> (<a href="https://revoirleslucioles.org/habiter-sans-posseder-tel-est-lantidote/" title="Accès à l’article original distant : Habiter sans posséder, tel est l’antidote">original</a>)</li>
@@ -89,6 +93,8 @@
<li><a href="/david/cache/2022/8a9c9c7aa6a17b8203e2ee289a5e2ffa/" title="Accès à l’article dans le cache local : Coremuneration - Movilab.org">Coremuneration - Movilab.org</a> (<a href="https://movilab.org/wiki/Coremuneration" title="Accès à l’article original distant : Coremuneration - Movilab.org">original</a>)</li>
<li><a href="/david/cache/2022/9ad9f5ea367dbd74e4aeeb8471747247/" title="Accès à l’article dans le cache local : Make it boring - jlwagner.net">Make it boring - jlwagner.net</a> (<a href="https://jlwagner.net/blog/make-it-boring/" title="Accès à l’article original distant : Make it boring - jlwagner.net">original</a>)</li>
<li><a href="/david/cache/2022/c4af28e3e148b7fd23ccb06e3a3f0358/" title="Accès à l’article dans le cache local : Nos morts ne vous sont pas dues">Nos morts ne vous sont pas dues</a> (<a href="https://www.jefklak.org/nos-morts-ne-vous-sont-pas-dues/" title="Accès à l’article original distant : Nos morts ne vous sont pas dues">original</a>)</li>
<li><a href="/david/cache/2022/77e068f6681c5054ef9871e8102f3236/" title="Accès à l’article dans le cache local : Winnie Lim » out of control">Winnie Lim » out of control</a> (<a href="https://winnielim.org/journal/out-of-control/" title="Accès à l’article original distant : Winnie Lim » out of control">original</a>)</li>
@@ -101,26 +107,40 @@
<li><a href="/david/cache/2022/099887889751a8432b4ab9ce7edc3bfa/" title="Accès à l’article dans le cache local : Éduquer au numérique d’accord. Mais pas n’importe lequel et pas n’importe comment">Éduquer au numérique d’accord. Mais pas n’importe lequel et pas n’importe comment</a> (<a href="https://louisderrac.com/2021/11/03/eduquer-au-numerique-daccord-mais-pas-nimporte-lequel-et-pas-nimporte-comment/" title="Accès à l’article original distant : Éduquer au numérique d’accord. Mais pas n’importe lequel et pas n’importe comment">original</a>)</li>
<li><a href="/david/cache/2022/8d9cffcd9bdc116b8934310706def4bc/" title="Accès à l’article dans le cache local : Le pillage de la communauté des logiciels libres">Le pillage de la communauté des logiciels libres</a> (<a href="https://www.monde-diplomatique.fr/2022/01/O_NEIL/64221" title="Accès à l’article original distant : Le pillage de la communauté des logiciels libres">original</a>)</li>
<li><a href="/david/cache/2022/393a69cbefc7e1642bae86080e6fc8c4/" title="Accès à l’article dans le cache local : Is the madness ever going to end?">Is the madness ever going to end?</a> (<a href="https://unixsheikh.com/articles/is-the-madness-ever-going-to-end.html" title="Accès à l’article original distant : Is the madness ever going to end?">original</a>)</li>
<li><a href="/david/cache/2022/891705d1555d09a941fd1f7685de9370/" title="Accès à l’article dans le cache local : dataklasses: A different spin on dataclasses.">dataklasses: A different spin on dataclasses.</a> (<a href="https://github.com/dabeaz/dataklasses#questions-and-answers" title="Accès à l’article original distant : dataklasses: A different spin on dataclasses.">original</a>)</li>
<li><a href="/david/cache/2022/0d024905896d89f8bd499e2a6170b59e/" title="Accès à l’article dans le cache local : What’s Really Going On Inside Your node_modules Folder?">What’s Really Going On Inside Your node_modules Folder?</a> (<a href="https://socket.dev/blog/inside-node-modules" title="Accès à l’article original distant : What’s Really Going On Inside Your node_modules Folder?">original</a>)</li>
<li><a href="/david/cache/2022/f3a292e38cc775f66adcd3e876baf082/" title="Accès à l’article dans le cache local : 2021.58 fiction until">2021.58 fiction until</a> (<a href="http://futurefire.net/2021.58/fiction/until.html" title="Accès à l’article original distant : 2021.58 fiction until">original</a>)</li>
<li><a href="/david/cache/2022/acd4b5cdd3ebf13e74a102563aa90b9a/" title="Accès à l’article dans le cache local : On Paying Open Source Maintainers">On Paying Open Source Maintainers</a> (<a href="https://nadim.computer/posts/2021-12-12-maintainers.html" title="Accès à l’article original distant : On Paying Open Source Maintainers">original</a>)</li>
<li><a href="/david/cache/2022/0c0894907925eae954987d98c9e8136b/" title="Accès à l’article dans le cache local : Why I Quit Tech and Became a Therapist">Why I Quit Tech and Became a Therapist</a> (<a href="http://glench.com/WhyIQuitTechAndBecameATherapist/" title="Accès à l’article original distant : Why I Quit Tech and Became a Therapist">original</a>)</li>
<li><a href="/david/cache/2022/053b5d423df20fa4e7978174d91d41bb/" title="Accès à l’article dans le cache local : Making Gemini Easy">Making Gemini Easy</a> (<a href="https://proxy.vulpes.one/gemini/tilde.team/~tomasino/journal/20211103-making-gemini-easy.gmi" title="Accès à l’article original distant : Making Gemini Easy">original</a>)</li>
<li><a href="/david/cache/2022/7591561f82b6ec5b32ead9df89a11c15/" title="Accès à l’article dans le cache local : Pourquoi Poutine a déjà perdu la guerre">Pourquoi Poutine a déjà perdu la guerre</a> (<a href="https://legrandcontinent.eu/fr/2022/02/27/pourquoi-poutine-a-deja-perdu-la-guerre/" title="Accès à l’article original distant : Pourquoi Poutine a déjà perdu la guerre">original</a>)</li>
<li><a href="/david/cache/2022/ad5756e74f5c976458c42eeb9e60707e/" title="Accès à l’article dans le cache local : Guerre en Ukraine : 10 enseignements syriens">Guerre en Ukraine : 10 enseignements syriens</a> (<a href="https://cantinesyrienne.fr/ressources/les-peuples-veulent/guerre-en-ukraine-10-enseignements-syriens" title="Accès à l’article original distant : Guerre en Ukraine : 10 enseignements syriens">original</a>)</li>
<li><a href="/david/cache/2022/850c5e99f499d9703c9b9bc116914429/" title="Accès à l’article dans le cache local : « Logiciel libre » et « Open Source », c'est pareil ou pas ?">« Logiciel libre » et « Open Source », c'est pareil ou pas ?</a> (<a href="https://www.bortzmeyer.org/free-software-open-source.html" title="Accès à l’article original distant : « Logiciel libre » et « Open Source », c'est pareil ou pas ?">original</a>)</li>
<li><a href="/david/cache/2022/3a929cba1a057771e1778ee9dc3e300a/" title="Accès à l’article dans le cache local : Wolf packs don’t actually have alpha males and alpha females, the idea is based on a misunderstanding">Wolf packs don’t actually have alpha males and alpha females, the idea is based on a misunderstanding</a> (<a href="https://phys.org/news/2021-04-wolf-dont-alpha-males-females.html" title="Accès à l’article original distant : Wolf packs don’t actually have alpha males and alpha females, the idea is based on a misunderstanding">original</a>)</li>
<li><a href="/david/cache/2022/86a502931562f5a88120be5ae903b67a/" title="Accès à l’article dans le cache local : An African view of what’s happening in Europe">An African view of what’s happening in Europe</a> (<a href="https://www.opendemocracy.net/en/5050/an-african-view-of-whats-happening-in-europe/" title="Accès à l’article original distant : An African view of what’s happening in Europe">original</a>)</li>
<li><a href="/david/cache/2022/21c1a3b62ce222105d72ada4802bdd4e/" title="Accès à l’article dans le cache local : Wrap Up and Q&amp;A - Jacob Kaplan-Moss">Wrap Up and Q&amp;A - Jacob Kaplan-Moss</a> (<a href="https://jacobian.org/2022/jan/6/wst-wrap-up/" title="Accès à l’article original distant : Wrap Up and Q&amp;A - Jacob Kaplan-Moss">original</a>)</li>
<li><a href="/david/cache/2022/a400ea6d0c196bbcaefbe1cc9af84fbb/" title="Accès à l’article dans le cache local : Workplace serendipity, invention, and lessons from Prohibition 1920-1933">Workplace serendipity, invention, and lessons from Prohibition 1920-1933</a> (<a href="https://interconnected.org/home/2022/03/14/saloons" title="Accès à l’article original distant : Workplace serendipity, invention, and lessons from Prohibition 1920-1933">original</a>)</li>
<li><a href="/david/cache/2022/20648a9bc173f75256ae9d5f196fd913/" title="Accès à l’article dans le cache local : The happiest number I've heard in ages">The happiest number I've heard in ages</a> (<a href="https://billmckibben.substack.com/p/the-happiest-number-ive-heard-in" title="Accès à l’article original distant : The happiest number I've heard in ages">original</a>)</li>
<li><a href="/david/cache/2022/f57abf8bb9e96e5cb5cfe845d76729f5/" title="Accès à l’article dans le cache local : “Open Source” is Broken">“Open Source” is Broken</a> (<a href="https://christine.website/blog/open-source-broken-2021-12-11" title="Accès à l’article original distant : “Open Source” is Broken">original</a>)</li>
<li><a href="/david/cache/2022/69acddf6a1f953e130ab2b36960568b7/" title="Accès à l’article dans le cache local : Le disque vinyle : débunkage">Le disque vinyle : débunkage</a> (<a href="https://blog.cybergrunge.dev/le-disque-vinyle-debunkage" title="Accès à l’article original distant : Le disque vinyle : débunkage">original</a>)</li>
<li><a href="/david/cache/2022/1ed0450ac39a1bbfebf1a6bbbe6f3532/" title="Accès à l’article dans le cache local : Top 9 UX Trends to Watch out in 2022">Top 9 UX Trends to Watch out in 2022</a> (<a href="https://uxplanet.org/top-9-ux-trends-to-watch-ut-in-2022-9dfc1eeb25a8" title="Accès à l’article original distant : Top 9 UX Trends to Watch out in 2022">original</a>)</li>
@@ -129,30 +149,46 @@
<li><a href="/david/cache/2022/d9ff2d3ee678b7de12c1a4e6d521ca35/" title="Accès à l’article dans le cache local : That Wild Ask A Manager Story">That Wild Ask A Manager Story</a> (<a href="https://jacobian.org/2022/feb/14/that-wild-aam-story/" title="Accès à l’article original distant : That Wild Ask A Manager Story">original</a>)</li>
<li><a href="/david/cache/2022/ed0eff49e75f35733437d71da03b0af3/" title="Accès à l’article dans le cache local : Sustaining Maintaining">Sustaining Maintaining</a> (<a href="https://daverupert.com/2021/12/sustaining-maintaining/" title="Accès à l’article original distant : Sustaining Maintaining">original</a>)</li>
<li><a href="/david/cache/2022/af26cb6361904f154ea71e2c5b2271cc/" title="Accès à l’article dans le cache local : nostr - Notes and Other Stuff Transmitted by Relays">nostr - Notes and Other Stuff Transmitted by Relays</a> (<a href="https://github.com/fiatjaf/nostr" title="Accès à l’article original distant : nostr - Notes and Other Stuff Transmitted by Relays">original</a>)</li>
<li><a href="/david/cache/2022/4525ebd31ecd7bc978fbe0ad464824a3/" title="Accès à l’article dans le cache local : Tools for Communicating Offline and in Difficult Circumstances">Tools for Communicating Offline and in Difficult Circumstances</a> (<a href="https://www.complete.org/tools-for-communicating-offline-and-in-difficult-circumstances/" title="Accès à l’article original distant : Tools for Communicating Offline and in Difficult Circumstances">original</a>)</li>
<li><a href="/david/cache/2022/9eac0872e78f3de333ff5df423060de2/" title="Accès à l’article dans le cache local : Support open source that you use by paying the maintainers to talk to your team">Support open source that you use by paying the maintainers to talk to your team</a> (<a href="https://simonwillison.net/2022/Feb/23/support-open-source/" title="Accès à l’article original distant : Support open source that you use by paying the maintainers to talk to your team">original</a>)</li>
<li><a href="/david/cache/2022/47b228aca2d77bc5e7eee35437655a8e/" title="Accès à l’article dans le cache local : On ne fera pas l’économie de parler distance des logements">On ne fera pas l’économie de parler distance des logements</a> (<a href="https://n.survol.fr/n/on-ne-fera-pas-leconomie-de-parler-distance-des-logements" title="Accès à l’article original distant : On ne fera pas l’économie de parler distance des logements">original</a>)</li>
<li><a href="/david/cache/2022/6e3580538a14b52ac9cb5fd54dfa1384/" title="Accès à l’article dans le cache local : writing as a practice">writing as a practice</a> (<a href="https://winnielim.org/journal/writing-as-a-practice/" title="Accès à l’article original distant : writing as a practice">original</a>)</li>
<li><a href="/david/cache/2022/31293aa75259e6e704ec714b5a4712cf/" title="Accès à l’article dans le cache local : Ukraine. Para Bellum Numericum. Chronique du versant numérique d'une guerre au 21ème siècle.">Ukraine. Para Bellum Numericum. Chronique du versant numérique d'une guerre au 21ème siècle.</a> (<a href="https://www.affordance.info/mon_weblog/2022/02/guerre-ukraine-numerique.html" title="Accès à l’article original distant : Ukraine. Para Bellum Numericum. Chronique du versant numérique d'une guerre au 21ème siècle.">original</a>)</li>
<li><a href="/david/cache/2022/62f9f5083de61124ed4d9fe1b458d505/" title="Accès à l’article dans le cache local : Programming for kids">Programming for kids</a> (<a href="https://github.com/jackdoe/programming-for-kids" title="Accès à l’article original distant : Programming for kids">original</a>)</li>
<li><a href="/david/cache/2022/94210cf35e7b73fcf5d3ab3c20acc1c6/" title="Accès à l’article dans le cache local : cailloux n°96 : rêver sincèrement">cailloux n°96 : rêver sincèrement</a> (<a href="https://cailloux.substack.com/p/96-rever-sincerement" title="Accès à l’article original distant : cailloux n°96 : rêver sincèrement">original</a>)</li>
<li><a href="/david/cache/2022/985e33814839a9c113720a5142caec0e/" title="Accès à l’article dans le cache local : Long Distance Thinking">Long Distance Thinking</a> (<a href="https://simonsarris.substack.com/p/long-distance-thinking" title="Accès à l’article original distant : Long Distance Thinking">original</a>)</li>
<li><a href="/david/cache/2022/a4f881156c5d4841f7362f94b51d10b7/" title="Accès à l’article dans le cache local : $7 Tent Heater Provides Comfort On A Budget">$7 Tent Heater Provides Comfort On A Budget</a> (<a href="https://hackaday.com/2022/01/06/7-tent-heater-provides-comfort-on-a-budget/" title="Accès à l’article original distant : $7 Tent Heater Provides Comfort On A Budget">original</a>)</li>
<li><a href="/david/cache/2022/0d734a1e83d3188bb008a057aadd4a74/" title="Accès à l’article dans le cache local : ☕️ Journal : Faire équipe">☕️ Journal : Faire équipe</a> (<a href="https://oncletom.io/2022/01/30/faire-equipe/" title="Accès à l’article original distant : ☕️ Journal : Faire équipe">original</a>)</li>
<li><a href="/david/cache/2022/571d5d3f9d63d9ec4a8107e5abd15941/" title="Accès à l’article dans le cache local : Why not everything I do is “Open” or “Free”">Why not everything I do is “Open” or “Free”</a> (<a href="https://overengineer.dev/blog/2021/12/12/why-not-everything-i-do-is-open-or-free.html" title="Accès à l’article original distant : Why not everything I do is “Open” or “Free”">original</a>)</li>
<li><a href="/david/cache/2022/87b3d4be1d7a1e72be8d411a0eb59249/" title="Accès à l’article dans le cache local : Les Jazzettes #20">Les Jazzettes #20</a> (<a href="https://jazzettes.substack.com/p/les-jazzettes-20" title="Accès à l’article original distant : Les Jazzettes #20">original</a>)</li>
<li><a href="/david/cache/2022/c0e7ed5590b520f176aacfd76ae03188/" title="Accès à l’article dans le cache local : Mechanical Ragger: Print typesetting for the web">Mechanical Ragger: Print typesetting for the web</a> (<a href="https://oak.is/thinking/mechanical-ragger/" title="Accès à l’article original distant : Mechanical Ragger: Print typesetting for the web">original</a>)</li>
<li><a href="/david/cache/2022/eafb714078643eddfcc2d7de9982bd3b/" title="Accès à l’article dans le cache local : Understanding UUIDs, ULIDs and String Representations">Understanding UUIDs, ULIDs and String Representations</a> (<a href="https://sudhir.io/uuids-ulids" title="Accès à l’article original distant : Understanding UUIDs, ULIDs and String Representations">original</a>)</li>
<li><a href="/david/cache/2022/ae3792ebced6f8b2b12b04723d982462/" title="Accès à l’article dans le cache local : ☕️ Journal : Pluriversité">☕️ Journal : Pluriversité</a> (<a href="https://thom4.net/2022/03/06/pluriversite/" title="Accès à l’article original distant : ☕️ Journal : Pluriversité">original</a>)</li>
<li><a href="/david/cache/2022/7377c68e2b48f5c923542cefec391549/" title="Accès à l’article dans le cache local : Compte-rendu de voyage : Le samedi 5 février à Ottawa">Compte-rendu de voyage : Le samedi 5 février à Ottawa</a> (<a href="https://mtlcontreinfo.org/compte-rendu-de-voyage-le-samedi-5-fevrier-a-ottawa/" title="Accès à l’article original distant : Compte-rendu de voyage : Le samedi 5 février à Ottawa">original</a>)</li>
<li><a href="/david/cache/2022/63c624eb03143c963380f527b7b5ca0f/" title="Accès à l’article dans le cache local : Brasserie du Vieux Singe — Transformation en SCOP">Brasserie du Vieux Singe — Transformation en SCOP</a> (<a href="https://www.vieuxsinge.com/transformation-en-scop.html" title="Accès à l’article original distant : Brasserie du Vieux Singe — Transformation en SCOP">original</a>)</li>
<li><a href="/david/cache/2022/e8d6bd5b11ae399009cf9258869be09c/" title="Accès à l’article dans le cache local : The Asymmetry of Open Source">The Asymmetry of Open Source</a> (<a href="https://matt.life/writing/the-asymmetry-of-open-source" title="Accès à l’article original distant : The Asymmetry of Open Source">original</a>)</li>
</ul>
</main>


Loading…
Cancel
Save