A whole bunch of emoji. What could they mean?

This particular post comes out of left field a bit. I was playing around with a web application I had made - an online disassembler for the x86 - when I noticed that emoji were being encoded into the url. 

I pasted a goat emoji, 🐐  and I noticed the encoding %F0%9F%90%90.

Now, if you're familiar with x86 assembly language at all, hexadecimal 90h is probably familiar to you. It's the opcode for a null operation or NOP.

I had a brief nerd chuckle over the thought that goats were the NOPs of emoji, but then I got curious. F0h on the 8088 is the LOCK prefix. This prefix is generally used to coordinate exclusive bus access with a coprocessor such as the 8087, but otherwise does nothing for most instructions on the 8088 and is ignored (this would change on later Intel CPUs). That leaves us with 9Fh. 

9Fh is LAHF. 

The entire goat emoji is valid 8088 machine code, a sequence that reads

lock lahf
nop
nop

As it turns out, the vast majority of emoji graphemes, as they are called, start with the sequence F09F. A dim little light bulb started to flicker above my head.  Could you actually write an 8088 program using nothing but displayable emoji?  

The idea is not without precedent. It has been well-established that executables can be generated with only printable ASCII characters - the most famous example probably being the EICAR test file, an ASCII string that is also a valid DOS executable that prints "EICAR-STANDARD-ANTIVIRUS-TEST-FILE!" and exits.

Other small ASCII programs were printed in magazines or distributed in other ways, such as the tiny terminal utility TCOM, the entire source of which is reproduced below:

XPHPD[0GG0G,0G51G31GB'(G+(G:u'0g?(G>(GE1G@arwIV_F*=US@>1|_,5wXNg-7muTu(4
1m0ss1k260s@3G1g360@3G0i7t2g3A1g350@3G2E1=0C1g350@3T2M0^\1g3>0@3T=1s2g0T
1g3;0@3ToN2g391g0t@3G0^F1k0s2?0@3T4

This is an interesting "emergency terminal" solution: if someone had no other means of loading an executable onto a computer system, it could simply be entered in via the keyboard. 

It surprises me that the idea of directly executing emoji has apparently never been explored.

Hello (World)!

Of course, the first thing to do is attempt Hello World! in emoji. For space reasons and partly due to the pain of doing any sort of arithmetic in emoji, we will only print the string HELLO.

Here is the full program:

🐸☺️🐰🐎♐🗃️🧯🧯🧯🐮💗🦮🪏♐🐰🐹🗃️🧯🧯🧯🧯💗🪗🧯😗🧮🫪😗🧮😗🐮😪😔⭐

Pasted into a text editor and saved as UTF-8, no BOM, with a .COM file extension, the result should be 141 bytes with an MD5 sum of 0a5c91475ca2de33e36aacc2f0b7b840.

The disassembly of the entire program can be viewed here.

Several emoji here may display as tofu, depending on your browser and what year you are reading this article.

🪏 is the shovel emoji, introduced in Unicode 16.0 in 2024.  These glyphs still take time to trickle down into font updates.

🪗 is the accordion emoji, added to Unicode 13.0 in 2020, but somehow still not visible in Chrome on Windows 10. Go figure.

🫪 is the "Distorted Face" emoji and is brand new in Unicode 17.0, approved in 2025. 

In theory, it should be possible to copy the relevant tofu character and preserve the representational bytes, but some operating systems and programs seem to struggle with the byte-preserving concept.

This program relies on a few undocumented 8088 aliases, and so requires a fairly accurate 8088 core to execute successfully. Let's see what it does in DOSBox-X with cpu cputype=8086:

The "Hello (World!)" program executing in DosBox-X

00000000  F0 9F     lahf
00000002  90        nop
00000003  B8 E2 98  mov ax,98E2h
00000006  BA EF B8  mov dx,B8EFh
00000009  8F        db 0x8F

0000012C  F0 9F  lahf
0000012E  92     xchg dx,ax
0000012F  97     xchg di,ax

00000146  83 EF B8  sub di,FFB8h

Emojissembly Reference

Standalone Emoji

Open-Tail Emoji

Useful Gadgets

These are complete, useful sequences of multiple emoji.

BunnySad: 🐰😔 - Stack repair

This eight-byte sequence deliberately replaces the current stack pointer with FFF0h:

0000: F0 9F    lahf
0002: 90       nop
0003: B0 F0    mov al,F0h
0005: 9F       lahf
0006: 98       cbw
0007: 94       xchg sp,ax

The rabbit's final B0h consumes the sad face's leading F0h, loading AL=F0h. The second LAHF is followed by CBW, which turns that into AX=FFF0h; XCHG then installs it as the stack pointer.

This is how to recover after intentional POPs and keep asynchronous interrupt pushes near the top of the segment. It discards the current stack, so it is safe only when no return address or saved value is live. The old SP is left in AX.

BunnySnowParty 🐰☃️🐰😔 - Safe addition: DI += 48h

This 18-byte sequence advances DI by 48h (72 decimal), absorbs the snowman's dangling POP, and repairs the stack:

0000: F0 9F       lahf
0002: 90          nop
0003: B0 E2       mov al,E2h
0005: 98          cbw
0006: 83 EF B8    sub di,FFB8h
0009: 8F F0       pop ax
000B: 9F          lahf
000C: 90          nop
000D: B0 F0       mov al,F0h
000F: 9F          lahf
0010: 98          cbw
0011: 94          xchg sp,ax

The first rabbit consumes the snowman's E2h; B8h is a signed -72 immediate, so SUB DI,-72 adds 72. The snowman's final 8Fh consumes the next rabbit's F0h as the undocumented POP AX encoding 8F F0. The final rabbit/sad-face pair restores SP=FFF0h.

This was one of the first gadgets found. The eye and plate gadgets are usually more efficient, but this one is included for completeness.

PlateGoat: 🍽️🐐 - Increment SP and advance DI

The plate needs a following byte to complete its final 8Fh. A padding goat is a convenient harmless tail.

0000: F0 9F          lahf
0002: 8D BD EF B8    lea di,[di-4711h]
0006: 8F F0          pop ax
0008: 9F             lahf
0009: 90             nop
000A: 90             nop

B8EFh is the 16-bit representation of -4711h, so the LEA performs DI += B8EFh. The plate's 8Fh consumes the goat's leading F0h as undocumented POP AX; the remaining 9F 90 90 is LAHF; NOP; NOP.

Plates advance SP by two as well as moving DI a significant distance. Plates are excellent for pointer arithmetic, but their stack effects must be accounted for.

CatGoat: 😿🐐 - Absolute DI reset

The crying cat opens MOV DI,imm16. A padding goat supplies the immediate.

0000: F0 9F       lahf
0002: 98          cbw
0003: BF F0 9F    mov di,9FF0h
0006: 90          nop
0007: 90          nop

This eight-byte gadget resets DI to 9FF0h without depending on its previous value. If another emoji replaces the goat, its leading F0 9F still becomes the immediate, but its remaining bytes execute as a tail and may further change DI.

CamelWrite: 🗓️ + arithmetic + 📗🐪 - Generate and write a byte

The generic form is 15 fixed bytes plus the chosen arithmetic sequence. Here is the simplest concrete example, 🗓️🐮📗🐪, using a cow to add one:

0000: F0 9F       lahf
0002: 97          xchg di,ax
0003: 93          xchg bx,ax
0004: EF          out dx,ax      ; spurious OUT to B8EFh
0005: B8 8F F0    mov ax,F08Fh
0008: 9F          lahf
0009: 90          nop
000A: AE          scasb
000B: F0 9F       lahf
000D: 93          xchg bx,ax
000E: 97          xchg di,ax
000F: F0 9F       lahf
0011: 90          nop
0012: AA          stosb

On entry, DI is the real output pointer and AX contains the arithmetic seed. 🗓️ moves the seed into DI and saves the output pointer in BX.

The middle emoji sequence performs arithmetic on this temporary DI; the cow above adds one.

📗 restores the output pointer and transfers the computed low byte into AL, and 🐪 writes it.

The calendar also performs OUT DX,AX. The common startup establishes DX=B8EFh, a generally unmapped port. Use with caution on real hardware!

FrogStrap: 🐸☺️😖🐰😗😯😯😯😯😯😯😯 - Common register bootstrap

This 50-byte sequence obtains a known zero from the normal COM entry stack and establishes a specific register state:

0000: F0 9F       lahf
0002: 90          nop
0003: B8 E2 98    mov ax,98E2h
0006: BA EF B8    mov dx,B8EFh
0009: 8F F0       pop ax
000B: 9F          lahf
000C: 98          cbw
000D: 96          xchg si,ax
000E: F0 9F       lahf
0010: 90          nop
0011: B0 F0       mov al,F0h
0013: 9F          lahf
0014: 98          cbw
0015: 97          xchg di,ax
0016: F0 9F       lahf
0018: 98          cbw
0019: AF          scasw
001A: F0 9F       lahf
001C: 98          cbw
001D: AF          scasw
001E: F0 9F       lahf
0020: 98          cbw
0021: AF          scasw
0022: F0 9F       lahf
0024: 98          cbw
0025: AF          scasw
0026: F0 9F       lahf
0028: 98          cbw
0029: AF          scasw
002A: F0 9F       lahf
002C: 98          cbw
002D: AF          scasw
002E: F0 9F       lahf
0030: 98          cbw
0031: AF          scasw

🐸☺️ loads DX=B8EFh and leaves a dangling 8Fh. The first byte of 😖 completes POP AX, obtaining the known zero at SS:FFFEh and wrapping SP to 0000h; the rest of 😖 moves that zero into SI.

🐰 consumes the leading F0h from 😗 to make AL=F0h, after which CBW; XCHG DI,AX establishes DI=FFF0h. Seven SCASWs advance it to FFFEh.

The final state is DX=B8EFh, SI=0000h, DI=FFFEh, and SP=0000h.

The value of B8EFh in DX is within the lower portion of CGA video memory if used as a segment.

An additional 😯 can roll DI over to 0000h. The value FFFEh left in DI has conceivable uses as a -2 constant.

🐸☺️🐰🐎♐ - Load the CGA segment

This 21-byte sequence exploits the original 8088's undocumented segment-register alias to establish ES=B8EFh:

0000: F0 9F       lahf
0002: 90          nop
0003: B8 E2 98    mov ax,98E2h
0006: BA EF B8    mov dx,B8EFh
0009: 8F F0       pop ax
000B: 9F          lahf
000C: 90          nop
000D: B0 F0       mov al,F0h
000F: 9F          lahf
0010: 90          nop
0011: 8E E2       mov es,dx
0013: 99          cwd
0014: 90          nop

A Basic Loader

bits 16
org 0

    push di
    pop  si                         ; SI = encoded emoji data
    mov  di,0100h
    push di                         ; RET target after reconstruction
    mov  cx,RAW_SIZE

.decode:
    lodsw                           ; discard the fixed F0 9F prefix
    lodsw                           ; AL=third UTF-8 byte, AH=fourth
    aad  8Fh                        ; AL=(AL + 8Fh*AH) & FFh; AH=0
    stosb
    loop .decode
    ret                             ; execute reconstructed COM at 0100h

A VGA Emoji Demo

Spoiler — click to reveal

1981 was a different time for computing. It was expensive (both hardware and software), and it was far from a given that machines from one vendor would be able to talk to those from another. In fact, Columbia University had just such a problem, so in 1981, Frank da Cruz and Bill Catchings designed a serial protocol they called Kermit. Because of the many quirks of the DEC-20 and IBM mainframes, the Kermit protocol was highly adaptable from the start: able to handle systems that had trouble processing more than 96 bytes of data at once, able to transfer 8-bit files over 7-bit links, able to translate between character sets (ASCII and EBCDIC then; now also various Unicodes), and of course, handling of error-prone serial links.

Kermit spread rapidly; by 1982, Kermit had been ported to MS-DOS and Unix. Eventually, C-Kermit (an implementation of Kermit in C) became the flagship Kermit. It gained TCP support, an interactive CLI, a powerful scripting language (with features from the shell, Lisp, and expect), and optimizations for today’s high-speed links, such as jumbo packets, sliding windows, and streaming modes. Along the way, Kermit flew on the International Space Station, ran data collection from sensors during hurricanes, and many other uses including postal systems, Boeing 787 manufacturing, and more.

Today, I use it as a powerful ssh wrapper (letting me easily transfer files through multiple nested ssh, sudo, su, etc. commands), a BBS client, to exchange data with me HP 48GX calculator, and so on. It’s also used today to transmit firmware updates to embedded devices. And, of course, anyone that works with vintage systems is likely to use Kermit at some point.

It wouldn’t be until the late 1990s that the TCP/IP stack was finally adopted by most OS vendors, establishing something of a common basis for communication. Of course, we assume this today. Though transferring large files between OSs (say, Linux, Windows, MacOS, Android, iPad, etc.) is still a challenge, even though they all speak TCP/IP! I find that the easiest way to get large files from two computers is to spin up Kermit (see ckwin for a Windows fork of C-Kermit) and just set up a TCP connection over the LAN. In fact, I added a new show interfaces command in C-Kermit 11, making it easy to see your system’s local IPs.

For most of its history, Columbia’s Kermit project was self-funded. Columbia charged for commercial use, which limited its inclusion in Linux distributions. In 2011, 30 years after its founding, Columbia canceled the Kermit Project and released C-Kermit as Open Source under a BSD license. Frank da Cruz, who had still been working with the Kermit project all those years, volunteered to continue maintaining Kermit outside Columbia, and continued development with alpha and beta releases through his retirement from the project in 2025.

I dive into this C codebase

As Debian maintainer of Kermit, I noticed some areas where it wasn’t matching modern expectations. One area was, not surprising for a project of its age, security. Another area was that its character set or line-ending conversions are usually not desired now; we are used to byte-identical binary transfers, and the defaults caused confusion and even some rare instances of data corruption. So I started making a few patches last year.

I’ve worked with old C codebases before, such as Varnish. I’ve generally hated it. You usually find a mix of bad and terrible practices, unclear memory management, and so forth.

But I’ve been living in the C-Kermit codebase for a few months now, and I enjoy it. Yes, this thing is still designed to build on VMS, OS/2, and with compilers that haven’t heard of ANSI — and those that require modern practices. (That em-dash was mine; I knew how to use them before LLMs existed and I’m not going to stop just because LLMs have copied people like me! No AI was used for this post.)

The there is an elegance in all of that. As I worked, I fixed a bunch more potential security issues, both with memory safety and with protecting against a malicious remote in roughly the same manner that some patches to scp did a few years back. I added IPv6 support, of course conditionally compiled because some systems C-Kermit builds on have never heard of IPv6 and never will. (And, of course, with fallback algorithms at runtime for systems that have IPv6 support but not IPv6 connectivity.)

I added unit tests and Python-based end-to-end tests, running nearly 2000 test cases in total. Along the way, I found and fixed a number of bugs going back decades. I learned about FIONREAD being broken on macOS, about NetBSD’s bugs in the pty driver, and fixed bugs in the Kermit protocol implementation itself. I added compatibility tests with the gkermit and ekermit (embedded) implementations, as well as the last full release, C-Kermit 9.0.302 from 2011 (which was difficult to get compiled on a modern system).

There is an extensive changelog describing all the improvements in C-Kermit 11.

C-Kermit development had never really used a VCS at any point, though Kermit veteran Jeffrey Altman imported historical releases into a Git repo, along with some patches that hadn’t made it into a release (which I also pulled in.) There was a lot of disabled code behind #ifdef COMMENT, along with commentary describing why it was no longer used. With Git, we would now generally just remove the old code and explain why in a commit message. I went through and did so with a lot of it, meaning that, at last check, C-Kermit actually has fewer lines of code now than it used to.

Towards a new release

It became apparent pretty quickly that I was making more changes than would make sense as a Debian patch series. Not only that, but they would be more widely applicable to more than just Debian and Ubuntu users. As Linux and BSD distributions were running everything from the last non-beta release (2011’s 9.0.302) to the last beta release (about 1.5 years ago), depending on their different policies about running betas, even sharing patches in a useful fashion was going to be quite difficult.

So, I spun up a project at Open Kermit to coordinate future development in the open and keep Kermit going.

With modern CI, I run that test suite on Linux (x86_64 and arm64), macOS, FreeBSD, NetBSD, and OpenBSD. It builds binary releases on all those platforms, plus a statically-linked Linux binary built with musl libc.

You can download the latest C-Kermit release, and of course contribute to C-Kermit and its website.

Dedication

Frank da Cruz was directly involved with Kermit for 44 years. I’m not aware of any other Open Source project founder being involved for so long. Richard Stallman started working on GNU Emacs in 1984, 3 years after Frank started working on Kermit, but Richard hasn’t been in that role since around 2008.

Accordingly, C-Kermit 11 bears this dedication:

I dedicate this release of C-Kermit to Frank da Cruz.

Frank was directly involved with Kermit for 44 years, from its initial design in 1981 all the way through 2025. He maintained Kermit as an Open Source project after Columbia University ended its sponsorship. I know of no other Open Source project where the founder remains so personally involved for so long.

When Kermit was begun, transfers between different hardware and operating systems were difficult or impossible. Frank helped build a bridge. Kermit glued systems together, from the International Space Station to pocket calculators, and set a new standard for interoperability. It continues to do so.

Kermit is still one of the quietly-working pillars of computing today, enabling everything from firmware upgrades to radios. And, yes, it still reliably transfers files over serial lines.

As we start to spend a lot of time in the Kermit codebase, we do so standing on the shoulders of a giant. Thanks, Frank, for your decades of work on Kermit.

John Goerzen, July 2026

The release of NetBSD 11.0, the 19th major version of the operating system, has been announced. There are many changes and enhancements since the 10.1 release, including a new port to RISC-V, better support for Linux system calls in compat_linux(), as well as improvements to the NPF firewall.

As you are probably aware, the number of security issues found or suspected everywhere has massively increased with the advent of AI tools. As a consequence, we can't publish a release without open issues. Instead of delaying the release further to fix them (new ones are being reported all the time), we've instead chosen to be transparent about this.

See the full release notes for links to the binary distributions and links to the full change logs.

Project LANA interim report on IUT theory, “As of July 2026, the LANA Project has not made a final judgment on the correctness or incorrectness of IUT theory. However, through the multiple bootcamps held since February 2025 and lively discussions during numerous online meetings, it has progressed to the point of transforming the core of the controversy, which for many years had been discussed in vague terms, into the form of diagrams, types, code, black boxes, and explicit questions”, and later: “we are reserving our final judgment on whether a proof exists for Corollary 3.12 in Mochizuki’s third paper on IUT theory.”

Silk, a cooperative fiber scheduler for Linux with per-CPU scheduler threads, io_uring integration, and topology-aware work-stealing. By ClickHouse.

The git history command deserves more attention, useful additions in Git 2.55.

Justif is a JavaScript library that applies TeX-style paragraph layout to existing HTML.

Fast Synthesis of Basic Oscillators, by Artemis Everfree.

E73, a rendering of the ECMA-42 standard bitmap printer font from 1973.

Why did early ASCII have ← and ↑ but not ↓ or →?

BSD Make extravaganza computes the Mandelbrot set in bmake.

Bad Apple, animated in the browser, without JS and CSS.

Frankfurt Schoodle, guess the author of a quote.

Killing Processes

One of the features of systemd that is most controversial is the option to kill user processes when the user logs out. That initially killed screen/tmux/nohup processes too. In recent Debian releases the default configuration of systemd-logind (the login manager for systemd) is to allow processes to keep running, the configuration file /etc/systemd/logind.conf has an option KillUserProcesses that can be enabled to have user processes killed. If you do that then there are options to only kill processes for certain users and to exclude some users (default to excluding root). If using that option you can apparently use a systemd unit to start screen which prevents it being killed on logout.

This is a very handy feature for some particular user cases. One situation was that I was supporting some people who weren’t very good at computers on a system running KDE and some KDE processes would linger. So the option of logout and login again to deal with an issue of akonadi or some other KDE service misbehaving didn’t work. On that system I enabled the option to kill user processes which reduced the number of problems they had while not requiring rebooting.

It is widely believed that the “linger” feature is required to allow screen/tmux/nohup to work, in Debian (and probably most distributions) that is not the case. It might be that some combinations of configuration requires “linger” to allow screen/tmux to work but I am not interested in trying to discover them. Of all the people I have directly supported for Linux desktop use (which numbers in the hundreds) none of them have had the ability to use screen/tmux and also the cluelessnes that makes me want to automatically kill their processes when the logout.

Controlling Linger

You can enable and disable “linger” for your own account with the following commands if polkit is installed and in a typical configuration:

loginctl enable-linger
loginctl disable-linger

If running as root you can enable and disable it for another user with the following commands:

loginctl enable-linger $ACCOUNT
loginctl disable-linger $ACCOUNT

There doesn’t seem to be any documented way of discovering if an account has linger enabled or for listing accounts that have it, it seems that “ls /var/lib/systemd/linger” is the only option.

Linger on Debian

On a Debian system with close to default settings the processes won’t be killed on logout and the only difference “linger” makes is to start programs in the user’s context BEFORE they login. A friend was recently testing out a bunch of LLM programs on one of my servers and the account he used for that ended up with “linger” enabled, presumably one of the install scripts he ran was written on the assumption that enabling linger was necessary for nohup to work and it did so automatically without being asked.

One benefit I’ve found from this behaviour is on my laptop. I’m currently testing out new SE Linux policy on my laptop and rebooting it a lot. When I enabled linger on my account it caused the laptop to connect to wifi on boot without needing to login which is convenient. I can then ssh to it even when the X11/Wayland login configuration is broken.

I will leave it enabled after finishing these tests. Having background processes like Pipewire and Bluetooth start before I login will presumably make things slightly faster when I do login.

We launched GitHub Sponsors in 2019 with a simple belief: the people who build and maintain open source software deserve to be supported for their work. Since then, tens of thousands of sponsors—individuals and organizations alike—have turned that belief into action.

We’re proud to announce that more than $100 million has been invested in open source maintainers and projects through GitHub Sponsors. This milestone belongs to the developers, organizations, and maintainers who have invested in a more sustainable open source ecosystem, and it signals that the way we value open source is changing.

How we got here

GitHub Sponsors started with individuals. We wanted to make it possible for any developer to directly support the maintainers they depend on. In 2023, we made organization-funded sponsorships generally available and saw organizations like Shopify step up to fund their dependencies at scale. The program expanded to 103 regions, partnered with Patreon, and introduced tools like bulk sponsorships and invoice payments to make it easy to participate.

The result: a global funding network that supports over 70,000 maintainers and organizations, and includes more than 280,000 sponsors spanning individual developers to Fortune 500 companies.

The pace is accelerating, too. The first $10 million took nearly two years. The most recent $10 million took just five months.

The people behind the number

While $100 million is a meaningful number, the real measure of impact is what it’s made possible for real people.

GitHub Sponsors changed how I think about open source. It gave me a direct, sustainable way to fund the time it takes to build and maintain projects, instead of treating it like side work. That has let me invest more consistently in the projects and build with a much longer-term view. Thanks to GitHub Sponsors, I am able to give back to our community, build a business, and actually make a difference in OSS.

Kelvin Tegelaar, Maintainer, Lime Networks

Shopify invests in open source because our platform, our merchants, and our engineering culture all depend on a healthy open source ecosystem. GitHub Sponsors gives us a direct way to support the maintainers and projects that move the industry forward, from foundational technologies to smaller tools that make developers’ daily work better. For us, sponsorship is both practical and values-driven: it helps sustain the software we rely on while strengthening our connection to the people building it.

Shopify

As strong advocates of open source software, Mercedes-Benz recognizes the incredible contributions made by developers and maintainers worldwide. Through GitHub Sponsors, we aim to support and empower these dedicated individuals and projects that drive innovation, collaboration, and the advancement of open source. By providing financial assistance to these projects, we hope to enable them to dedicate more time and resources to their impactful work, thereby making open source more sustainable and contributing to the overall health and longevity of the projects. We extend our deep gratitude to all the participants and celebrate their dedication. Together, we can continue to foster a vibrant and sustainable open source ecosystem that benefits our teams, developers and users alike.

Dr. Wolfgang Gehring, OSPO Lead & FOSS Ambassador, Mercedes-Benz Tech Innovation GmbH

GitHub Sponsors has meant many things for me and my open source. First, it showed me people’s appreciation and motivated me. Then it showed me I could and should figure out how to do more open source. And then, for the past years, it has also allowed me to sub-sponsor many of the open source tools that power mine, to share that appreciation and support.

Sebastián Ramírez, tiangolo

My projects wouldn’t be what they are today without GitHub Sponsors. Sponsorships allowed me to quit my job and work on them full time. GitHub Sponsors opened my eyes to the opportunities available for passionate people working on projects that people care about.

Caleb Porzio, Livewire & Alpine.js

Open source careers shouldn’t depend on geography or circumstance. They should depend on the value of the work. Increasingly, the community is making that possible.

What we’ve learned

Building GitHub Sponsors over the past seven years has taught us a few things:

Organizations move the needle. In 2022, nearly 40% of sponsorship funding came from organizations, with each organization-funded sponsorship worth an average of nearly 15x more than the average individual sponsorship. As more companies recognize their dependence on open source, this share continues to grow.

Reducing friction matters. Every time we’ve made it easier to sponsor (e.g. adding invoice payments, expanding regions, enabling bulk sponsorships) we’ve seen a corresponding increase in funding. The demand to support open source is there. We aim to make that easy to do.

What’s next

This milestone proves that when the community shows up for open source, the impact is real. But the work isn’t done. The open source funding gap is still enormous, many critical projects remain underfunded, and maintainer burnout continues to be one of the biggest risks to the software supply chain. This $100 million is proof that the community can change how open source is sustained, one sponsorship at a time.

The best way to keep this momentum going? Start sponsoring the projects you depend on or encourage your organization to do the same.

How you can get involved

Behind the scenes, maintainers are working daily to make open source better for all of us. If you or your organization depend on open source — and you almost certainly do — there’s no better time to invest in the people who make it possible.

Visit the Sponsors Explore page to discover which maintainers you depend on and start supporting them today. If you’re a maintainer and haven’t set up your Sponsors profile yet, visit github.com/sponsors to get started.

Thank you to every sponsor and every maintainer who has been part of this $100 million journey. This is what happens when a community decides that open source is worth investing in. We can’t wait to see where it goes from here.

The post $100 million for open source: A milestone built by the community appeared first on The GitHub Blog.