davidbgk
/
larlet-fr-david
Watch 1
Star 0
Fork 0
Code Releases 0 Activity
Browse Source

Publishing

master
David Larlet 2 years ago
parent
d406f1e401
commit
5d7b0e7481
7 changed files with 455 additions and 4 deletions
Split View Show Diff Stats
  1. 2
    2
      david/2022/03/18/index.html
  2. 295
    0
      david/2022/03/23/index.html
  3. 72
    0
      david/2022/_sources/2022-03-23 - Open-source.md
  4. 2
    1
      david/2022/index.html
  5. 1
    0
      david/index.html
  6. 77
    1
      david/log/index.xml
  7. 6
    0
      david/recherche/index.html

+ 2
- 2
david/2022/03/18/index.html View File

@@ -81,7 +81,7 @@
Recherche</a
>
</nobr>
• <a rel="next" href="/david/2022/03/23/" title="Publication suivante : Open-source">Suivant →</a>
</p>
</nav>
<hr>
@@ -153,7 +153,7 @@
<p class="center">
<a rel="prev" href="/david/2022/03/04/" title="Publication précédente : Régime">← Précédent</a> •
<a href="/david/2022/" title="Liste des publications récentes">↑ En 2022</a>
• <a rel="next" href="/david/2022/03/23/" title="Publication suivante : Open-source">Suivant →</a>
</p>
</nav>
</article>

+ 295
- 0
david/2022/03/23/index.html View File

@@ -0,0 +1,295 @@
<!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 — David Larlet</title>
<meta name="description" content="[En commentaires de l’article] — But really open-source (as in free) is the misnomer here, it should be called free open-source, or FOSS as some correctly name it. — That battle has been fought already, and the accepted term is “source available”, not “open source”.">
<!-- 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>

<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</h1>
</header>
<nav>
<p class="center">
<a rel="prev" href="/david/2022/03/18/" title="Publication précédente : Temps">← Précédent</a> •
<nobr>
<a href="/david/" title="Aller à l’accueil"
><svg class="icon icon-home">
<use
xlink:href="/static/david/icons2/symbol-defs-2022-03.svg#icon-home"
></use>
</svg>
Accueil</a
>
</nobr>
•
<nobr>
<a href="/david/recherche/" title="Aller à la page de recherche"
><svg class="icon icon-search">
<use
xlink:href="/static/david/icons2/symbol-defs-2022-03.svg#icon-search"
></use>
</svg>
Recherche</a
>
</nobr>
</p>
</nav>
<hr>


<blockquote lang="en">
<p><em>[En commentaires de l’article]</em><br />
— But really open-source (as in free) is the misnomer here, it should be called free open-source, or FOSS as some correctly name it.<br />
— That battle has been fought already, and the accepted term is <mark>“source available”</mark>, not “open&nbsp;source”.</p>
<p><cite><em><a href="https://germano.dev/sse-websockets/#comments">Server-Sent Events: the alternative to WebSockets you should be using</a></em>&nbsp;(<a href="/david/cache/2022/b17f8ac80615c86cade89dd81c8aa50b/">cache</a>)</cite></p>
</blockquote>
<p>Cela fait longtemps que je souhaite aborder ce sujet. Il y a la traditionnelle ambigüité entre «&nbsp;libre&nbsp;» et «&nbsp;gratuit&nbsp;» qui vient d’un quiproquo de traduction-trahison de <em>free</em> en anglais. Mais il y a quelque chose de plus profond entre <strong>rendre du code disponible</strong> —&nbsp;librement utilisable au sens de sa licence&nbsp;— et le <strong>maintenir en vie</strong>. Si <q>l’Open-Source c’est de la solidarité entre développeurs</q> (<a href="/david/blog/2013/open-source-solidarite/">ce qui est déjà pas mal</a>) et que la <a href="https://www.bortzmeyer.org/free-software-open-source.html">distinction avec le logiciel libre</a>&nbsp;(<a href="/david/cache/2022/850c5e99f499d9703c9b9bc116914429/">cache</a>) est si floue, toute la différence se situe au niveau des échanges et de leur&nbsp;gouvernance.</p>
<p>Le code en tant que tel, lorsqu’il est publié, est déjà mort. (Comme une pensée écrite mais je digresse.) C’est l’effort qui est mis pour continuer à l’alimenter, à le guider, ensemble, qui est intéressant. Il faut peut-être un nouveau terme pour désigner cela d’ailleurs, je proposerais bien <strong>«&nbsp;inclusive-source&nbsp;»</strong> avec une définition qu’il faudrait co-définir (pour rester cohérent) mais dont les grandes lignes à titre d’exemple pourraient&nbsp;être&nbsp;:</p>
<ul>
<li>le ou la contributeur·ice principal·e participe a moins de 80&#8239;% du&nbsp;code&#8239;;</li>
<li>il y a plusieurs administrateur·ices du dépôt&nbsp;principal&#8239;;</li>
<li>les discussions et la gouvernance s’effectuent de manière&nbsp;publique&#8239;;</li>
<li>etc&nbsp;etc.</li>
</ul>
<p>Il y a très peu de dépôt populaires qui répondent ne serait-ce qu’à ces trois critères. Et c’est tout a fait acceptable. L’importance de créer une catégorie explicite est de pouvoir aussi faire des choix éclairés lors de ses propres contributions, d’avoir le sentiment de s’impliquer pour participer à un <em>bien commun</em> (lâchons les gros mots). Les étoiles Microsoft Github ne sont pas forcément un bon indicateur pour évaluer la santé d’un produit. Et donc sa&nbsp;pérennité.</p>
<p>On voit aussi qu’il est facile de se heurter aux limites de règles strictes/mesurables si on en vient à ajouter des indications du type «&nbsp;l’équipe d’administration est <a href="https://thom4.net/2022/03/06/pluriversite/">pluriversifiée</a>&nbsp;(<a href="/david/cache/2022/ae3792ebced6f8b2b12b04723d982462/">cache</a>)&nbsp;» qui seraient pourtant essentielles pour un écosystème sain. Il est beaucoup mentionné en ce moment la notion de réciprocité (pécuniaire) dans l’usage de l’open-source, il y aurait peut-être des choses à creuser pour rendre les attentes explicites à ce niveau, indépendamment de la&nbsp;licence.</p>
<p>Comment arriver à une définition légère et vérifiable&#8239;? Dans quel·s espace·s discuter de ces distinctions&#8239;? Comment <strong>ne pas</strong> en faire un label&#8239;? Qu’en est-il des <a href="/david/stream/2018/04/01/">questions éthiques</a>&#8239;?</p>
<p><em>Note&nbsp;: au passage je retrouve <a href="/david/blog/2016/inclusive-developer/">Inclusive developer</a> qui a 5&nbsp;ans et où j’écrivais <q lang=en>turn open-source into free software (more in a future article)</q>, c’est maintenant chose&nbsp;initiée.</em></p>
<h2 id="open-links">Open links <a href="#open-links" title="Ancre vers cette partie">#</a></h2>
<blockquote>
<p>💔 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 «&nbsp;libristes&nbsp;», quand les employés des Gafam répètent que la question ne présente aujourd’hui plus <mark>guère d’intérêt</mark> pour une majorité de&nbsp;contributeurs.</p>
<p><cite><em><a href="https://www.monde-diplomatique.fr/2022/01/O_NEIL/64221">Le pillage de la communauté des logiciels libres</a></em>&nbsp;(<a href="/david/cache/2022/8d9cffcd9bdc116b8934310706def4bc/">cache</a>)</cite></p>
</blockquote>

<blockquote lang="en">
<p>💯 Q: Who maintains&nbsp;dataklasses?</p>
<p>A: If you’re using it, you do. <mark>You</mark> maintain&nbsp;dataklasses.</p>
<p><cite><em><a href="https://github.com/dabeaz/dataklasses#questions-and-answers">dataklasses: A different spin on dataclasses.</a></em>&nbsp;(<a href="/david/cache/2022/891705d1555d09a941fd1f7685de9370/">cache</a>)</cite></p>
</blockquote>

<blockquote lang="en">
<p>💰 If you can make sponsorship happen, great: you should do that. But if not… <mark>how about reaching out to the maintainers and offering to hire them for an hour-long “consultancy” speaking engagement&nbsp;instead?</mark></p>
<p>Thanks to the rise of remote working and Zoom, giving a talk no longer requires traveling to a venue—which can easily turn an hour-long opportunity into a full&nbsp;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 that monthly&nbsp;donations.</p>
<p><cite><em><a href="https://simonwillison.net/2022/Feb/23/support-open-source/">Support open source that you use by paying the maintainers to talk to your team</a></em>&nbsp;(<a href="/david/cache/2022/9eac0872e78f3de333ff5df423060de2/">cache</a>)</cite></p>
</blockquote>

<blockquote lang="en">
<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>But financials are one part of the sustainable open source equation. <mark>There’s an emotional cost</mark> to having a publicly available project that hundreds or thousands of people and companies depend on as&nbsp;well.</p>
<p><cite><em><a href="https://daverupert.com/2021/12/sustaining-maintaining/">Sustaining Maintaining</a></em>&nbsp;(<a href="/david/cache/2022/ed0eff49e75f35733437d71da03b0af3/">cache</a>)</cite></p>
</blockquote>

<blockquote lang="en">
<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 <mark>“Open Source” being a pool of free labor</mark> makes it hard for me to want to have my side projects be actually useful like that unless you pay&nbsp;me.</p>
<p><cite><em><a href="https://christine.website/blog/open-source-broken-2021-12-11">“Open Source” is Broken</a></em>&nbsp;(<a href="/david/cache/2022/f57abf8bb9e96e5cb5cfe845d76729f5/">cache</a>)</cite></p>
</blockquote>

<blockquote lang="en">
<p>💍 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 <mark>from being engaged to being married</mark> to your project, rather than a free solution to balance maintainer responsibilities with new compensatory&nbsp;income.</p>
<p><cite><em><a href="https://nadim.computer/posts/2021-12-12-maintainers.html">On Paying Open Source Maintainers</a></em>&nbsp;(<a href="/david/cache/2022/acd4b5cdd3ebf13e74a102563aa90b9a/">cache</a>)</cite></p>
</blockquote>

<blockquote lang="en">
<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 <mark>the relationship between maintainers and users to form a toxic imbalance</mark> 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&nbsp;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&nbsp;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&nbsp;developers.</p>
<p><cite><em><a href="https://matt.life/writing/the-asymmetry-of-open-source">The Asymmetry of Open Source</a></em>&nbsp;(<a href="/david/cache/2022/e8d6bd5b11ae399009cf9258869be09c/">cache</a>)</cite></p>
</blockquote>

<blockquote lang="en">
<p>⏳ Here is the thing: making a project’s code accessible to any audience is just a small piece of running an open-source project. 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&nbsp;projects.</p>
<p>The problem, though, is that reviewing pull requests, paying adequate attention, and providing helpful feedback takes <mark>a lot of time and energy.</mark> 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&nbsp;itself.</p>
<p><cite><em><a href="https://overengineer.dev/blog/2021/12/12/why-not-everything-i-do-is-open-or-free.html">Why not everything I do is “Open” or “Free”</a></em>&nbsp;(<a href="/david/cache/2022/571d5d3f9d63d9ec4a8107e5abd15941/">cache</a>)</cite></p>
</blockquote>


<nav>
<p class="center">
<a rel="prev" href="/david/2022/03/18/" title="Publication précédente : Temps">← Précédent</a> •
<a href="/david/2022/" title="Liste des publications récentes">↑ En 2022</a>
</p>
</nav>
</article>


<hr>

<footer>
<p>
<nobr>
<a href="/david/" title="Aller à l’accueil"
><svg class="icon icon-home">
<use
xlink:href="/static/david/icons2/symbol-defs-2022-03.svg#icon-home"
></use>
</svg>
Accueil</a
>
</nobr>
•
<nobr>
<a href="/david/log/" title="Accès au flux RSS"
><svg class="icon icon-rss2">
<use xlink:href="/static/david/icons2/symbol-defs-2022-03.svg#icon-rss2"></use>
</svg>
Suivre</a
>
</nobr>
•
<nobr>
<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-2022-03.svg#icon-user-tie"></use>
</svg>
Pro</a
>
</nobr>
•
<nobr>
<a href="mailto:david%40larlet.fr" title="Envoyer un courriel"
><svg class="icon icon-mail">
<use xlink:href="/static/david/icons2/symbol-defs-2022-03.svg#icon-mail"></use>
</svg>
Email</a
>
</nobr>
•
<nobr>
<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-2022-03.svg#icon-hammer2"></use>
</svg>
Légal</abbr
>
</nobr>
</p>
<template id="theme-selector">
<form>
<fieldset>
<legend><svg class="icon icon-brightness-contrast">
<use xlink:href="/static/david/icons2/symbol-defs-2022-03.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>

+ 72
- 0
david/2022/_sources/2022-03-23 - Open-source.md View File

@@ -0,0 +1,72 @@
# Open-source

> [en] *[En commentaires de l’article]*
> — But really open-source (as in free) is the misnomer here, it should be called free open-source, or FOSS as some correctly name it.
> — That battle has been fought already, and the accepted term is ==“source available”==, not “open source”.
>
> <cite>*[Server-Sent Events: the alternative to WebSockets you should be using](https://germano.dev/sse-websockets/#comments)* ([cache](/david/cache/2022/b17f8ac80615c86cade89dd81c8aa50b/))</cite>

Cela fait longtemps que je souhaite aborder ce sujet. Il y a la traditionnelle ambigüité entre « libre » et « gratuit » qui vient d’un quiproquo de traduction-trahison de *free* en anglais. Mais il y a quelque chose de plus profond entre **rendre du code disponible** — librement utilisable au sens de sa licence — et le **maintenir en vie**. Si <q>l’Open-Source c’est de la solidarité entre développeurs</q> ([ce qui est déjà pas mal](/david/blog/2013/open-source-solidarite/)) et que la [distinction avec le logiciel libre](https://www.bortzmeyer.org/free-software-open-source.html) ([cache](/david/cache/2022/850c5e99f499d9703c9b9bc116914429/)) est si floue, toute la différence se situe au niveau des échanges et de leur gouvernance.

Le code en tant que tel, lorsqu’il est publié, est déjà mort. (Comme une pensée écrite mais je digresse.) C’est l’effort qui est mis pour continuer à l’alimenter, à le guider, ensemble, qui est intéressant. Il faut peut-être un nouveau terme pour désigner cela d’ailleurs, je proposerais bien **« inclusive-source »** avec une définition qu’il faudrait co-définir (pour rester cohérent) mais dont les grandes lignes à titre d’exemple pourraient être :

* le ou la contributeur·ice principal·e participe a moins de 80 % du code ;
* il y a plusieurs administrateur·ices du dépôt principal ;
* les discussions et la gouvernance s’effectuent de manière publique ;
* etc etc.

Il y a très peu de dépôt populaires qui répondent ne serait-ce qu’à ces trois critères. Et c’est tout a fait acceptable. L’importance de créer une catégorie explicite est de pouvoir aussi faire des choix éclairés lors de ses propres contributions, d’avoir le sentiment de s’impliquer pour participer à un *bien commun* (lâchons les gros mots). Les étoiles Microsoft Github ne sont pas forcément un bon indicateur pour évaluer la santé d’un produit. Et donc sa pérennité.

On voit aussi qu’il est facile de se heurter aux limites de règles strictes/mesurables si on en vient à ajouter des indications du type « l’équipe d’administration est [pluriversifiée](https://thom4.net/2022/03/06/pluriversite/) ([cache](/david/cache/2022/ae3792ebced6f8b2b12b04723d982462/)) » qui seraient pourtant essentielles pour un écosystème sain. Il est beaucoup mentionné en ce moment la notion de réciprocité (pécuniaire) dans l’usage de l’open-source, il y aurait peut-être des choses à creuser pour rendre les attentes explicites à ce niveau, indépendamment de la licence.

Comment arriver à une définition légère et vérifiable ? Dans quel·s espace·s discuter de ces distinctions ? Comment **ne pas** en faire un label ? Qu’en est-il des [questions éthiques](/david/stream/2018/04/01/) ?

*Note : au passage je retrouve [Inclusive developer](/david/blog/2016/inclusive-developer/) qui a 5 ans et où j’écrivais <q lang=en>turn open-source into free software (more in a future article)</q>, c’est maintenant chose initiée.*

## Open links

> 💔 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 « libristes », 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.
>
> <cite>*[Le pillage de la communauté des logiciels libres](https://www.monde-diplomatique.fr/2022/01/O_NEIL/64221)* ([cache](/david/cache/2022/8d9cffcd9bdc116b8934310706def4bc/))</cite>

> [en] 💯 Q: Who maintains dataklasses?
>
> A: If you’re using it, you do. ==You== maintain dataklasses.
>
> <cite>*[dataklasses: A different spin on dataclasses.](https://github.com/dabeaz/dataklasses#questions-and-answers)* ([cache](/david/cache/2022/891705d1555d09a941fd1f7685de9370/))</cite>

> [en] 💰 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?==
>
> Thanks to the rise of remote working and Zoom, giving a talk no longer requires traveling to a venue—which can easily turn an hour-long opportunity into a full day.
>
> One-off paid speaking opportunities are much more likely to fit into a regular company’s model of how money should spent that monthly donations.
>
> <cite>*[Support open source that you use by paying the maintainers to talk to your team](https://simonwillison.net/2022/Feb/23/support-open-source/)* ([cache](/david/cache/2022/9eac0872e78f3de333ff5df423060de2/))</cite>

> [en] 🤕 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. […]
>
> 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.
>
> <cite>*[Sustaining Maintaining](https://daverupert.com/2021/12/sustaining-maintaining/)* ([cache](/david/cache/2022/ed0eff49e75f35733437d71da03b0af3/))</cite>

> [en] 🍌 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.
>
> <cite>*[“Open Source” is Broken](https://christine.website/blog/open-source-broken-2021-12-11)* ([cache](/david/cache/2022/f57abf8bb9e96e5cb5cfe845d76729f5/))</cite>

> [en] 💍 Starting a company, anytime, anywhere, for virtually anything, is an extra set of commitments *on top* 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.
>
> <cite>*[On Paying Open Source Maintainers](https://nadim.computer/posts/2021-12-12-maintainers.html)* ([cache](/david/cache/2022/acd4b5cdd3ebf13e74a102563aa90b9a/))</cite>

> [en] ⚖️ 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.
>
> 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.
>
> 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.
>
> <cite>*[The Asymmetry of Open Source](https://matt.life/writing/the-asymmetry-of-open-source)* ([cache](/david/cache/2022/e8d6bd5b11ae399009cf9258869be09c/))</cite>

> [en] ⏳ Here is the thing: making a project’s code accessible to any audience is just a small piece of running an open-source project. 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.
>
> The problem, though, is that reviewing pull requests, paying adequate attention, and providing helpful feedback takes ==a lot 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.
>
> <cite>*[Why not everything I do is “Open” or “Free”](https://overengineer.dev/blog/2021/12/12/why-not-everything-i-do-is-open-or-free.html)* ([cache](/david/cache/2022/571d5d3f9d63d9ec4a8107e5abd15941/))</cite>

+ 2
- 1
david/2022/index.html View File

@@ -99,7 +99,8 @@
<h3>Mars 2022</h3>
<p>
<a href="/david/2022/03/04/">Régime</a>,
<a href="/david/2022/03/18/">Temps</a>.
<a href="/david/2022/03/18/">Temps</a>,
<a href="/david/2022/03/23/">Open-source</a>.
</p>

+ 1
- 0
david/index.html View File

@@ -76,6 +76,7 @@

<nav>
<p>
<a href="/david/2022/03/23/">Open-source</a>,
<a href="/david/2022/03/18/">Temps</a>,
<a href="/david/2022/03/04/">Régime</a>,
<a href="/david/2022/02/17/">Envie</a>,

+ 77
- 1
david/log/index.xml View File

@@ -6,13 +6,89 @@
<link href="https://larlet.fr/david/" rel="alternate" type="text/html" />
<link href="https://larlet.fr/david/log/" rel="self" />
<id>https://larlet.fr/david/</id>
<updated>2022-03-21T12:00:00+01:00</updated>
<updated>2022-03-23T12:00:00+01:00</updated>
<author>
<name>David Larlet</name>
<uri>https://larlet.fr/david/</uri>
</author>
<rights>Copyright (c) 2004-2022, David Larlet</rights>
<entry xml:lang="fr">
<title type="html">Open-source</title>
<link href="https://larlet.fr/david/2022/03/23/" rel="alternate" type="text/html" />
<updated>2022-03-23T12:00:00+01:00</updated>
<id>https://larlet.fr/david/2022/03/23/</id>
<summary type="html">

&lt;blockquote lang=&quot;en&quot;&gt;
&lt;p&gt;&lt;em&gt;[En commentaires de l’article]&lt;/em&gt;&lt;br /&gt;
— But really open-source (as in free) is the misnomer here, it should be called free open-source, or FOSS as some correctly name it.&lt;br /&gt;
— That battle has been fought already, and the accepted term is &lt;mark&gt;“source available”&lt;/mark&gt;, not “open&amp;nbsp;source”.&lt;/p&gt;
&lt;p&gt;&lt;cite&gt;&lt;em&gt;&lt;a href=&quot;https://germano.dev/sse-websockets/#comments&quot;&gt;Server-Sent Events: the alternative to WebSockets you should be using&lt;/a&gt;&lt;/em&gt;&amp;nbsp;(&lt;a href=&quot;https://larlet.fr/david/cache/2022/b17f8ac80615c86cade89dd81c8aa50b/&quot;&gt;cache&lt;/a&gt;)&lt;/cite&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;Cela fait longtemps que je souhaite aborder ce sujet. Il y a la traditionnelle ambigüité entre «&amp;nbsp;libre&amp;nbsp;» et «&amp;nbsp;gratuit&amp;nbsp;» qui vient d’un quiproquo de traduction-trahison de &lt;em&gt;free&lt;/em&gt; en anglais. Mais il y a quelque chose de plus profond entre &lt;strong&gt;rendre du code disponible&lt;/strong&gt; —&amp;nbsp;librement utilisable au sens de sa licence&amp;nbsp;— et le &lt;strong&gt;maintenir en vie&lt;/strong&gt;. Si &lt;q&gt;l’Open-Source c’est de la solidarité entre développeurs&lt;/q&gt; (&lt;a href=&quot;https://larlet.fr/david/blog/2013/open-source-solidarite/&quot;&gt;ce qui est déjà pas mal&lt;/a&gt;) et que la &lt;a href=&quot;https://www.bortzmeyer.org/free-software-open-source.html&quot;&gt;distinction avec le logiciel libre&lt;/a&gt;&amp;nbsp;(&lt;a href=&quot;https://larlet.fr/david/cache/2022/850c5e99f499d9703c9b9bc116914429/&quot;&gt;cache&lt;/a&gt;) est si floue, toute la différence se situe au niveau des échanges et de leur&amp;nbsp;gouvernance.&lt;/p&gt;
&lt;p&gt;Le code en tant que tel, lorsqu’il est publié, est déjà mort. (Comme une pensée écrite mais je digresse.) C’est l’effort qui est mis pour continuer à l’alimenter, à le guider, ensemble, qui est intéressant. Il faut peut-être un nouveau terme pour désigner cela d’ailleurs, je proposerais bien &lt;strong&gt;«&amp;nbsp;inclusive-source&amp;nbsp;»&lt;/strong&gt; avec une définition qu’il faudrait co-définir (pour rester cohérent) mais dont les grandes lignes à titre d’exemple pourraient&amp;nbsp;être&amp;nbsp;:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;le ou la contributeur·ice principal·e participe a moins de 80&amp;#8239;% du&amp;nbsp;code&amp;#8239;;&lt;/li&gt;
&lt;li&gt;il y a plusieurs administrateur·ices du dépôt&amp;nbsp;principal&amp;#8239;;&lt;/li&gt;
&lt;li&gt;les discussions et la gouvernance s’effectuent de manière&amp;nbsp;publique&amp;#8239;;&lt;/li&gt;
&lt;li&gt;etc&amp;nbsp;etc.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Il y a très peu de dépôt populaires qui répondent ne serait-ce qu’à ces trois critères. Et c’est tout a fait acceptable. L’importance de créer une catégorie explicite est de pouvoir aussi faire des choix éclairés lors de ses propres contributions, d’avoir le sentiment de s’impliquer pour participer à un &lt;em&gt;bien commun&lt;/em&gt; (lâchons les gros mots). Les étoiles Microsoft Github ne sont pas forcément un bon indicateur pour évaluer la santé d’un produit. Et donc sa&amp;nbsp;pérennité.&lt;/p&gt;
&lt;p&gt;On voit aussi qu’il est facile de se heurter aux limites de règles strictes/mesurables si on en vient à ajouter des indications du type «&amp;nbsp;l’équipe d’administration est &lt;a href=&quot;https://thom4.net/2022/03/06/pluriversite/&quot;&gt;pluriversifiée&lt;/a&gt;&amp;nbsp;(&lt;a href=&quot;https://larlet.fr/david/cache/2022/ae3792ebced6f8b2b12b04723d982462/&quot;&gt;cache&lt;/a&gt;)&amp;nbsp;» qui seraient pourtant essentielles pour un écosystème sain. Il est beaucoup mentionné en ce moment la notion de réciprocité (pécuniaire) dans l’usage de l’open-source, il y aurait peut-être des choses à creuser pour rendre les attentes explicites à ce niveau, indépendamment de la&amp;nbsp;licence.&lt;/p&gt;
&lt;p&gt;Comment arriver à une définition légère et vérifiable&amp;#8239;? Dans quel·s espace·s discuter de ces distinctions&amp;#8239;? Comment &lt;strong&gt;ne pas&lt;/strong&gt; en faire un label&amp;#8239;? Qu’en est-il des &lt;a href=&quot;https://larlet.fr/david/stream/2018/04/01/&quot;&gt;questions éthiques&lt;/a&gt;&amp;#8239;?&lt;/p&gt;
&lt;p&gt;&lt;em&gt;Note&amp;nbsp;: au passage je retrouve &lt;a href=&quot;https://larlet.fr/david/blog/2016/inclusive-developer/&quot;&gt;Inclusive developer&lt;/a&gt; qui a 5&amp;nbsp;ans et où j’écrivais &lt;q lang=en&gt;turn open-source into free software (more in a future article)&lt;/q&gt;, c’est maintenant chose&amp;nbsp;initiée.&lt;/em&gt;&lt;/p&gt;
&lt;h2&gt;Open&amp;nbsp;links&lt;/h2&gt;

&lt;blockquote&gt;
&lt;p&gt;💔 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 «&amp;nbsp;libristes&amp;nbsp;», quand les employés des Gafam répètent que la question ne présente aujourd’hui plus &lt;mark&gt;guère d’intérêt&lt;/mark&gt; pour une majorité de&amp;nbsp;contributeurs.&lt;/p&gt;
&lt;p&gt;&lt;cite&gt;&lt;em&gt;&lt;a href=&quot;https://www.monde-diplomatique.fr/2022/01/O_NEIL/64221&quot;&gt;Le pillage de la communauté des logiciels libres&lt;/a&gt;&lt;/em&gt;&amp;nbsp;(&lt;a href=&quot;https://larlet.fr/david/cache/2022/8d9cffcd9bdc116b8934310706def4bc/&quot;&gt;cache&lt;/a&gt;)&lt;/cite&gt;&lt;/p&gt;
&lt;/blockquote&gt;

&lt;blockquote lang=&quot;en&quot;&gt;
&lt;p&gt;💯 Q: Who maintains&amp;nbsp;dataklasses?&lt;/p&gt;
&lt;p&gt;A: If you’re using it, you do. &lt;mark&gt;You&lt;/mark&gt; maintain&amp;nbsp;dataklasses.&lt;/p&gt;
&lt;p&gt;&lt;cite&gt;&lt;em&gt;&lt;a href=&quot;https://github.com/dabeaz/dataklasses#questions-and-answers&quot;&gt;dataklasses: A different spin on dataclasses.&lt;/a&gt;&lt;/em&gt;&amp;nbsp;(&lt;a href=&quot;https://larlet.fr/david/cache/2022/891705d1555d09a941fd1f7685de9370/&quot;&gt;cache&lt;/a&gt;)&lt;/cite&gt;&lt;/p&gt;
&lt;/blockquote&gt;

&lt;blockquote lang=&quot;en&quot;&gt;
&lt;p&gt;💰 If you can make sponsorship happen, great: you should do that. But if not… &lt;mark&gt;how about reaching out to the maintainers and offering to hire them for an hour-long “consultancy” speaking engagement&amp;nbsp;instead?&lt;/mark&gt;&lt;/p&gt;
&lt;p&gt;Thanks to the rise of remote working and Zoom, giving a talk no longer requires traveling to a venue—which can easily turn an hour-long opportunity into a full&amp;nbsp;day.&lt;/p&gt;
&lt;p&gt;One-off paid speaking opportunities are much more likely to fit into a regular company’s model of how money should spent that monthly&amp;nbsp;donations.&lt;/p&gt;
&lt;p&gt;&lt;cite&gt;&lt;em&gt;&lt;a href=&quot;https://simonwillison.net/2022/Feb/23/support-open-source/&quot;&gt;Support open source that you use by paying the maintainers to talk to your team&lt;/a&gt;&lt;/em&gt;&amp;nbsp;(&lt;a href=&quot;https://larlet.fr/david/cache/2022/9eac0872e78f3de333ff5df423060de2/&quot;&gt;cache&lt;/a&gt;)&lt;/cite&gt;&lt;/p&gt;
&lt;/blockquote&gt;

&lt;blockquote lang=&quot;en&quot;&gt;
&lt;p&gt;🤕 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. […]&lt;/p&gt;
&lt;p&gt;But financials are one part of the sustainable open source equation. &lt;mark&gt;There’s an emotional cost&lt;/mark&gt; to having a publicly available project that hundreds or thousands of people and companies depend on as&amp;nbsp;well.&lt;/p&gt;
&lt;p&gt;&lt;cite&gt;&lt;em&gt;&lt;a href=&quot;https://daverupert.com/2021/12/sustaining-maintaining/&quot;&gt;Sustaining Maintaining&lt;/a&gt;&lt;/em&gt;&amp;nbsp;(&lt;a href=&quot;https://larlet.fr/david/cache/2022/ed0eff49e75f35733437d71da03b0af3/&quot;&gt;cache&lt;/a&gt;)&lt;/cite&gt;&lt;/p&gt;
&lt;/blockquote&gt;

&lt;blockquote lang=&quot;en&quot;&gt;
&lt;p&gt;🍌 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 &lt;mark&gt;“Open Source” being a pool of free labor&lt;/mark&gt; makes it hard for me to want to have my side projects be actually useful like that unless you pay&amp;nbsp;me.&lt;/p&gt;
&lt;p&gt;&lt;cite&gt;&lt;em&gt;&lt;a href=&quot;https://christine.website/blog/open-source-broken-2021-12-11&quot;&gt;“Open Source” is Broken&lt;/a&gt;&lt;/em&gt;&amp;nbsp;(&lt;a href=&quot;https://larlet.fr/david/cache/2022/f57abf8bb9e96e5cb5cfe845d76729f5/&quot;&gt;cache&lt;/a&gt;)&lt;/cite&gt;&lt;/p&gt;
&lt;/blockquote&gt;

&lt;blockquote lang=&quot;en&quot;&gt;
&lt;p&gt;💍 Starting a company, anytime, anywhere, for virtually anything, is an extra set of commitments &lt;em&gt;on top&lt;/em&gt; of being an open source maintainer. It is more like going &lt;mark&gt;from being engaged to being married&lt;/mark&gt; to your project, rather than a free solution to balance maintainer responsibilities with new compensatory&amp;nbsp;income.&lt;/p&gt;
&lt;p&gt;&lt;cite&gt;&lt;em&gt;&lt;a href=&quot;https://nadim.computer/posts/2021-12-12-maintainers.html&quot;&gt;On Paying Open Source Maintainers&lt;/a&gt;&lt;/em&gt;&amp;nbsp;(&lt;a href=&quot;https://larlet.fr/david/cache/2022/acd4b5cdd3ebf13e74a102563aa90b9a/&quot;&gt;cache&lt;/a&gt;)&lt;/cite&gt;&lt;/p&gt;
&lt;/blockquote&gt;

&lt;blockquote lang=&quot;en&quot;&gt;
&lt;p&gt;⚖️ 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 &lt;mark&gt;the relationship between maintainers and users to form a toxic imbalance&lt;/mark&gt; 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&amp;nbsp;succeed.&lt;/p&gt;
&lt;p&gt;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&amp;nbsp;licenses.&lt;/p&gt;
&lt;p&gt;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&amp;nbsp;developers.&lt;/p&gt;
&lt;p&gt;&lt;cite&gt;&lt;em&gt;&lt;a href=&quot;https://matt.life/writing/the-asymmetry-of-open-source&quot;&gt;The Asymmetry of Open Source&lt;/a&gt;&lt;/em&gt;&amp;nbsp;(&lt;a href=&quot;https://larlet.fr/david/cache/2022/e8d6bd5b11ae399009cf9258869be09c/&quot;&gt;cache&lt;/a&gt;)&lt;/cite&gt;&lt;/p&gt;
&lt;/blockquote&gt;

&lt;blockquote lang=&quot;en&quot;&gt;
&lt;p&gt;⏳ Here is the thing: making a project’s code accessible to any audience is just a small piece of running an open-source project. 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&amp;nbsp;projects.&lt;/p&gt;
&lt;p&gt;The problem, though, is that reviewing pull requests, paying adequate attention, and providing helpful feedback takes &lt;mark&gt;a lot of time and energy.&lt;/mark&gt; 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&amp;nbsp;itself.&lt;/p&gt;
&lt;p&gt;&lt;cite&gt;&lt;em&gt;&lt;a href=&quot;https://overengineer.dev/blog/2021/12/12/why-not-everything-i-do-is-open-or-free.html&quot;&gt;Why not everything I do is “Open” or “Free”&lt;/a&gt;&lt;/em&gt;&amp;nbsp;(&lt;a href=&quot;https://larlet.fr/david/cache/2022/571d5d3f9d63d9ec4a8107e5abd15941/&quot;&gt;cache&lt;/a&gt;)&lt;/cite&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;nav&gt;&lt;p&gt;&lt;/p&gt;&lt;/nav&gt;&lt;hr/&gt;&lt;p&gt;&lt;a href=&quot;mailto:david@larlet.fr&quot;&gt;Réagir ?&lt;/a&gt;&lt;/p&gt;</summary>
</entry>
<entry xml:lang="fr">
<title type="html">Temps</title>
<link href="https://larlet.fr/david/2022/03/18/" rel="alternate" type="text/html" />

+ 6
- 0
david/recherche/index.html
File diff suppressed because it is too large
View File


Write Preview
Loading…
Cancel
Save