Update

custom.css

@@ -0,0 +1,24 @@
+h1 {
+	text-align: center;
+}
+
+div > p {
+	padding-left: 40px;
+}
+
+div > ul {
+	padding-left: 53px;
+}
+
+.centered {
+	p {
+		padding-left: 0px !important;
+		margin-left: 0px !important;
+        margin-right: 60px;
+        padding-right: 20px;
+	}
+	ul {
+		padding-left: 0px !important;
+	}
+	text-align: center;
+}

notes.md

@@ -10,45 +10,62 @@
   - functions
   - libraries
   - programs (unix)
+
 - lesson: specifications
   - LSP (open source milestone)
+
 - lesson: caring about features and code instead of maintenance and collaborations
 
-- lesson: dicatorships work
+- lesson: users (user experience)
+    - what if you diverge from the happy path
 
-- decision making (processes)
+- lesson: how to drive change
-  - lightweight when risk of mistakes is low (can revert?)
+  - good value proposation (e.g. when breaking backwards compat)
+  - risk: can you revert?
 
-- tests in CI are garbage
+
+- you guessed it, I like small programs
+
+- self-perception/myth
+
+- how to test (on the end users system)
+    - tests in CI are garbage
+    - tests vs good code
 
 - reverse dependencies <-> me <-> users
 - collaboration vs boundaries, communication
 
 
-- what distribution work taught me for programming
+- autotools intro?
+
+
+- mindful about what you don't know
+
+
 - posix principles and their connection to functional programming (streams)
 
 - navigation
 
 - strings
-- open source politics
-- how to drive change
-- how to handle contributions (contribution experience, PRs, documentation, mentoring,. ..)
 - collaboration
+    - open source politics
+    - how to drive change
+    - how to handle contributions (contribution experience, PRs, documentation, mentoring,. ..)
+    - respect other projects when contributing
+    - bus factor
+    - enabling and supporting (switching from coding wizard to support role)
+    - boundaries vs collaboration
+
 - relationship between industry and FOSS
-- what is the main currency (money vs energy)
+
-- bus factor
 - feedback from universities regarding Haskell tooling
-- respect other projects when contributing
+
-- enabling and supporting (switching from coding wizard to support role)
 - project life cycles
 - support
-- stability vs. ..
-- boundaries vs collaboration
 - trust, respect, relationship
 - working mode in open source
 - dealing with expectations
-- how to test (on the end users system)
+
-- what if you diverge from the happy path
+- stability vs. ..
 - why is stability an interesting goal?
 

nus.md

@@ -1,6 +1,24 @@
-% Two decades of Open Source
+---
-% Julian Ospald
+output:
-% Sep 20, 2024
+  slidy_presentation:
+    duration: 45
+title: Two decades of Open Source
+author: Julian Ospald
+date: Sep 20, 2024
+---
+
+## Follow the presentation {.centered}
+
+![](QR.png){#id .class height=500px}
+
+## Structure of this talk
+
+1. Introduction (about me and my career)
+2. Open Source (what it is and its value)
+3. First chapter: Gentoo and package management
+4. Second chapter: GHCup
+5. Third chapter: Haskell Core Libraries
+6. Lessons learned
 
 # Introduction
 
@@ -66,6 +84,8 @@
   * users
   * collaborators
 * 🕸️ network effects
+  * OSS community adopts fast
+  * compare with git
 
 ## Reality of Open Source
 
@@ -80,7 +100,7 @@
   * will stop maintenance at some point
   * don't care much about their users
 
-# Gentoo and package management
+# First chapter: Gentoo and package management
 
 ## What is Gentoo
 
@@ -146,7 +166,7 @@ src_install() {
   - shipping a "chain" instead of a single artifact
 * high impact on small mistakes (e.g. assuming a specific shell)
 
-## Packaging challenges (pt 2.)
+## Packaging challenges (pt. 2)
 
 * communication between teams/maintainers
 * execution of large changes
@@ -166,18 +186,19 @@ src_install() {
 * combining components to a coherent system (init system, coreutils, kernel, ...)
 * a choice of **defaults**
 
-## Why Gentoo made me a better programmer
+## Programming lessons
 
 * primary packaging skill: being meticulous
   * small mistakes -> big impact
+  * being as precise as possible about what you want to achieve
 * long term maintenance of small code pieces
 * intense review culture
 * strict policies and workflow guidelines
 * how to learn complex system
 
-# GHCup
+# Second chapter: GHCup
 
-## Demo
+## Demo {.centered}
 
 ![](ghcup.png){#id .class height=500px}
 
@@ -232,14 +253,6 @@ curl -s -L \
   - VSCode, stack, cabal-install integration
 * ![](ghaction.png){#id .class width=32 height=32px} CI provisioning (e.g. github actions)
 
-## The difference to Gentoo
-
-* one-man project (mostly)
-* much tighter coupling between upstream (e.g. GHC developers) and downstream (GHCup developers)
-  * heavier on relationship issues
-* much more responsibility
-* position of authority
-
 ## Relationships in detail
 
 Dependencies:
@@ -255,7 +268,7 @@ Dependencies:
   - platform support
   - binary distributions (the `.tar.gz`/`.zip`)
 
-## Relationships in detail
+## Relationships in detail (pt. 2)
 
 Dependents:
 
@@ -269,3 +282,179 @@ Dependents:
 - 🧰 tools
   - [vscode-haskell](https://github.com/haskell/vscode-haskell), [Haskell playground](https://play.haskell.org/), [nvim-lsp-installer](https://github.com/williamboman/nvim-lsp-installer)
 
+## Programming lessons
+
+* writing a small single-purpose program from scratch
+* how to design command line interfaces
+* high impact of decisions (not just mistakes)
+  - bugs now affect GitHub CI and companies
+  - can make "Haskell" look bad
+* no one to review
+  - => review your own code
+* constantly thinking about ways to improve reliability
+  - can't rely on anyone else to catch bugs
+
+## The difference to Gentoo
+
+Both deal with installation, but...
+
+* more code to maintain (not just packaging) for me
+* one-man project (mostly)
+* much tighter coupling between upstream (e.g. GHC developers) and downstream (GHCup developers)
+  * heavier on relationship issues
+* less dependencies, but much more responsibility
+* position of authority
+  - what to consider?
+* most of my work today is support
+
+# Third Chapter: Haskell Core Libraries
+
+## What are Haskell Core Libraries?
+
+* bundled with the compiler
+* fundamental building blocks (primitives)
+* base library
+  - available to all programs by default
+  - contains the "Prelude" (standard library)
+
+## Core libraries I maintain
+
+* filepath
+* unix
+* os-string
+* file-io
+
+## Challenges
+
+* changes are extremly expensive
+* writing good primitives is hard (non-specific APIs)
+* lots of odd knowledge
+  - e.g. Windows filepaths
+    - `C:foo`
+    - `/bar`
+    - `\\?\GLOBALROOT\Device\Harddisk0\Partition2\foo\bar`
+  - Posix standard
+* portability
+
+## Core Libraries Committee
+
+* 7 members
+* manages API changes of `base` only
+  * requires a proposal
+  * requires impact assessment for breaking changes
+  * requires an up-front implementation of the change
+* ensures other core libraries have active maintainers
+  * does not interfere with maintenance
+
+## Driving changes across core libraries (case study)
+
+Abstract FilePath Proposal:
+
+- Haskell String type: `type String = [Char]`
+  - `Char` is a unicode code point
+  - not bytes
+  - is interpreted (decoded)
+  - depends on locale
+- affects most core libraries
+- implement as a breaking change (base), or...
+  - in "user-space"
+- lack of higher authority
+  - building consensus
+  - convincing multiple maintainers
+  - patching many libraries
+- open source politics
+
+## Programming lessons
+
+* how to design good primitives
+  - as opposed to abstractions
+* considering every impact of API changes
+* doing history research on past design choices
+  - important design decisions may not be documented
+  - may look innocent
+  - chaning them might be devastating
+
+# Lessons Learned
+
+## Collaboration
+
+::: incremental
+
+* main currency in Open Source is energy
+* treat contributors like kings
+* be mindful about boundaries (tricky balance)
+* respect other projects workflows
+* driving large changes requires
+  - consensus
+  - support
+  - a good value proposition
+  - a good execution plan (risk, breakage, ...)
+* Haskell Foundation
+
+:::
+
+## Project maintenance
+
+::: incremental
+
+* dicatorships work, but are not sustainable
+* plan for your departure
+* bus factor is your constant enemy
+* good decision making processes
+  - lightweight when risk is low
+  - elaborate when risk is high
+* actively think about the contribution experience
+  - comment early
+* how to maintain the project vision?
+
+:::
+
+## User Experience
+
+::: incremental
+
+* UX is harder than CS
+  * yet often an afterthought
+* toolchains often lack a holistic UX vision
+* UX vision gets easily lost in "maintenance mode"
+  * feature creep
+  * maintainer turnover
+  * collective decisions
+* UX is a fascinating problem (e.g. OS)
+  - plug & play (intuition... about interfaces)
+  - happy path (control)
+  - defaults (expectations... about behavior)
+
+:::
+
+## Stability vs Progress
+
+* 🤼 conflicting goals
+* ⚔️ breaking API can have large rippling effects
+  - experience report of a facebook engineer on GHC upgrades
+* 🗼 small breakages add up
+  - large projects have hundreds of dependencies
+* 🗣️ many discussions in the Haskell community
+  - upgrade cost
+  - language changes (Haskell report)
+  - academic background of Haskell (academia vs industry?)
+  - the role of committees
+* ⚖️ how to strike a balance?
+  - SemVer does not solve it (why?)
+
+## Composition
+
+* 💜 I love small programs
+* categories of composition
+  - λ: functions
+  - 📚 libraries (the issue with types)
+  - ⚙️ programs
+* unix philosophy
+  - 🛠️ do one thing and do it well
+  - ⚗️ pipes, compose stdout and stdin (re-usable)
+* how to make your project composable?
+  - [https://clig.dev/](https://clig.dev/)
+
+## Questions/Arguments? {.centered}
+
+![](jiddu.jpg){#id .class height=500px}