DEV Community: Kat Marchán

I replaced htmx with a simple web component

Kat Marchán — Fri, 06 Sep 2024 19:01:59 +0000

(Image credit: https://www.maicar.com/GML/Ajax1.html)

I recently posted on Mastodon about how I was using htmx to much success, and someone rolled into my mentions challenging me on that, and how htmx is actually a pretty heavy dependency considering what I was using it for. They linked me to this post and everything.

At first, I was kind of annoyed. I thought I was doing a pretty good job of keeping things lightweight, and htmx had served me well. But then, I put on the hat that I've been trying to wear this whole time when it comes to reinventing the way I do web dev: are my assumptions right? Can I do better?

So I went ahead and replaced my entire usage of htmx with a tiny, 100-line, vanillajs web component, that I'm going to include in this post in its entirety:

export class AjaxIt extends HTMLElement {
  constructor() {
    super();
    this.addEventListener("submit", this.#handleSubmit);
    this.addEventListener("click", this.#handleClick);
  }

  #handleSubmit(e: SubmitEvent) {
    const form = e.target as HTMLFormElement;
    if (form.parentElement !== this) return;
    e.preventDefault();
    const beforeEv = new CustomEvent("ajax-it:beforeRequest", {
      bubbles: true,
      composed: true,
      cancelable: true,
    });
    form.dispatchEvent(beforeEv);
    if (beforeEv.defaultPrevented) {
      return;
    }
    const data = new FormData(form);
    form.dispatchEvent(new CustomEvent("ajax-it:beforeSend", { bubbles: true, composed: true }));
    const action = (e.submitter as HTMLButtonElement | null)?.formAction || form.action;
    (async () => {
      try {
        const res = await fetch(action, {
          method: form.method || "POST",
          headers: {
            "Content-Type": "application/x-www-form-urlencoded",
            "Ajax-It": "true",
          },
          body: new URLSearchParams(data as unknown as Record<string, string>),
        });
        if (!res.ok) {
          throw new Error("request failed");
        }
        form.dispatchEvent(new CustomEvent("ajax-it:afterRequest", { bubbles: true, composed: true }));
        const text = await res.text();
        this.#injectReplacements(text, new URL(res.url).hash);
      } catch {
        form.dispatchEvent(new CustomEvent("ajax-it:requestFailed", { bubbles: true, composed: true }));
      }
    })();
  }

  #handleClick(e: MouseEvent) {
    const anchor = e.target as HTMLAnchorElement;
    if (anchor.tagName !== "A" || anchor.parentElement !== this) return;
    e.preventDefault();
    anchor.dispatchEvent(new CustomEvent("ajax-it:beforeRequest", { bubbles: true, composed: true }));
    anchor.dispatchEvent(new CustomEvent("ajax-it:beforeSend", { bubbles: true, composed: true }));
    (async () => {
      try {
        const res = await fetch(anchor.href, {
          method: "GET",
          headers: {
            "Ajax-It": "true",
          },
        });
        if (!res.ok) {
          throw new Error("request failed");
        }
        anchor.dispatchEvent(new CustomEvent("ajax-it:afterRequest", { bubbles: true, composed: true }));
        const text = await res.text();
        this.#injectReplacements(text, new URL(res.url).hash);
      } catch {
        anchor.dispatchEvent(new CustomEvent("ajax-it:requestFailed", { bubbles: true, composed: true }));
      }
    })();
  }

  #injectReplacements(html: string, hash: string) {
    setTimeout(() => {
      const div = document.createElement("div");
      div.innerHTML = html;
      const mainTargetConsumed = !!hash && !!div.querySelector(
        hash,
      );
      const elements = [...div.querySelectorAll("[id]") ?? []];
      for (const element of elements.reverse()) {
        // If we have a parent that's already going to replace us, don't bother,
        // it will be dragged in when we replace the ancestor.
        const parentWithID = element.parentElement?.closest("[id]");
        if (parentWithID && document.getElementById(parentWithID.id)) {
          continue;
        }
        document.getElementById(element.id)?.replaceWith(element);
      }
      if (mainTargetConsumed) return;
      if (hash) {
        document
          .querySelector(hash)
          ?.replaceWith(...div.childNodes || []);
      }
    });
  }
}
customElements.define("ajax-it", AjaxIt);

You use it like this:

<ajax-it>
  <form action="/some/url">
    <input name=name>
  </form>
</ajax-it>

And that's it! Any elements with an id included in the response will be replaced when the response comes back. It works for <a> elements, too!

The element works two main ways:

If your action or href includes a hash, the element on or current page with an id matching that hash will be replaced with the contents of the entire response.
If your returned html contains elements that themselves have IDs, and those IDs have matches in the current document, those elements will be replaced first (and excluded from the “whole response” replacement above). This is essentially how you do “out of band” swaps (aka hx-swap-oob).

So, with some html like this:

<div id=extra-stuff></div>
<div id=user-list></div>

<ajax-it>
  <a href="/users/list#user-list">
    Get users
  </a>
</ajax-it>

and a server response like this:

<ul>
  <li>user 1
  <li>user 2
</ul>

You'll end up with:

<div id=extra-stuff></div>
<ul>
  <li>user 1
  <li>user 2
</ul>

<ajax-it>
  <a href="/users/list#user-list">
    Get users
  </a>
</ajax-it>

But if your response had been:

<ul>
  <li>user 1
  <li>user 2
</ul>

<p id=extra-stuff>Hello, I'm out-of-band</p>

you would have ended up with:

<p id=extra-stuff>Hello, I'm out-of-band</p>
<ul>
  <li>user 1
  <li>user 2
</ul>

<ajax-it>
  <a href="/users/list#user-list">
    Get users
  </a>
</ajax-it>

...with the id=extra-stuff swapped out-of-band and the <ul> swapped normally.

To maintain idempotency, though, I don't tend to use the hash version of things, and just make sure all my response elements have attached IDs:

<ul id=user-list>
  <li>user 1
  <li>user 2
</ul>

<p id=extra-stuff>Hello, I'm out-of-band</p>

Which would maintain the <ul> id and make clicking on the <a> repeatedly idempotent (as one would expect). In this case, your href can just be href="/users/list".

It's also fully progressively enhanced: as long as your action attribute points to a regular endpoint, things will behave as expected if JS isn't working or fails to load. All you have to look for on the server side is an Ajax-It: true header, so you can respond with minimal html instead of a full response.

Huge kudos and credit to htmz, which this is largely based on, except I needed to do it with AJAX instead of the iframe trick because I actually needed lifecycle events to do some of the offline trickery I'm doing.

Anyway cheers. Feel free to use the element in your own stuff! Consider it public domain :)

I was isekaid into developing a minimal-JavaScript online game using The Platform as much as I could and wrote about it 🧙

Kat Marchán — Thu, 05 Sep 2024 16:04:24 +0000

(Cover image credit: Ian MacDougall, https://www.artstation.com/artwork/oOd05w)

Folks have been nudging me to write this for a while on Mastodon, so I thought I'd put together a little series on a fun app I've been working on for a bit, as I build it.

It's a web-based PWA intended for playing a family of tabletop RPGs that I'm very fond of: Ironsworn/Starforged. These games are designed around single-player gameplay with optional multiplayer rules, and gameplay ends up looking a lot like journaling plus notes. Or, you could say, a lot like a blog publishing platform. And, like blog publishing platforms, a key thing with this game is that you should be able to publish your journals for other players to read and interact with, along with your characters, your worlds, and all sorts of other creations. A community of fictional creativity, posing as a fun little game.

What's so different about this app? Well, it's meant to have a lot of the bells and whistles that you'd expect from a PWA with serious offline capabilities, but it's built unlike the vast majority of webapps these days, while still having a fully fancy/interactive UI with all the bells and whistles you might be used to seeing in them. And as of right now, it's all done with a ~40kb JavaScript payload.

Why am I doing things this way? Because I believe the web platform has come a long way, and frontend applications have gotten unnecessarily heavy, slow, and inaccessible to large portions of the web userbase by their over-reliance on legacy technology like React &co: you don't need to ship megabytes of minified JavaScript and wasm to have a really fancy, modern application. The problem? There's very little documentation about how you actually go about doing this and using the technologies available because so much of the community documentation and education focuses around JS frameworks. So... I'd like to help a bit on that front.

To give you a sampling of some topics I'll be covering:

The app is an entirely server-side rendered multi-page application using a plain ol' server-side MVC web framework (Phoenix, without LiveView).
Oh, and even the Lit web components are server-side rendered. No FOUC or loading spinners to be seen.
It works entirely offline, and without even having a user account. Once you've loaded the site, you're good to go to play the game on the go, and you can sync later if you want.
If you're online, you get access to real-time, multiplayer editing.
As much as possible, use the platform: HTML, CSS, and JavaScript (okay I'm cheating a bit here, because I'm using TypeScript and esbuild, but that's just nice and easy).
A smattering of web components used as-needed, and only to the extent actually needed, instead of using a frontend framework of any sort (goodbye, React, you're not needed anymore)
Because of this, as mentioned above, the JavaScript bundle is tiny, currently weighing in at ~40kb, with minimal dependencies.
A really fun, CouchDB-style entity synchronization system that can handle the split-brain problem and sync conflicts in a reasonable way (read: without just stomping all over older changes).
Using iframes (!) for things like a dynamic sidebar that you can navigate around without refreshing the current page.
Very, very aggressive progressive enhancement: As long as you're online, the entire application should be fully usable if JavaScript is disabled or fails (no, not just because of a handful of nerds who run Lynx), while still enhancing up to dynamic, interactive behavior.
Centering accessibility by using what the browser already provides as much as possible. I guess I'll also be figuring ARIA stuff that I'm not very good at.
Using htmx for HTML-centered in-page dynamicity (without duplicating a bunch of code!) (update: I've replaced all my usage of htmx with a tiny web component in vanilla JS instead)

I'll be getting pretty specific and technical about one application in particular during this series, rather than using isolated, minimal examples. That way, the stuff you read is essentially all "real world" code with all the complex concerns that entails. So if you're interested in reading more about any of this, like and subscribe! I'll be POSTing Through It™️.

Kat's Mastodon Quickstart for Twitter Users

Kat Marchán — Wed, 17 Mar 2021 00:51:34 +0000

So you like Twitter, but you're curious about Mastodon? You've come to the right place. I'll make this real quick for you, and you can explore further from there, if you want to get more out of it. My setup is pretty straightforward and lets me post to both Twitter and Mastodon as needed, and maintain both communities easily.

Step 1: Get an Account

A defining feature of Mastodon is that you can make an account on many different servers, but those servers can talk to each other (aka "Federation"). Picking a server and signing up for it is the first step, but it can be daunting, with so many choices, so let's simplify:

You like Open Source: https://fosstodon.org
You're queer and you like tech: https://tech.lgbt
You want to see/post art: https://mastodon.art or https://artalley.social
You want the most reliable/biggest instance: https://mastodon.online/ (please avoid this one. You'll miss out on some aspects of Mastodon culture by just defaulting here).
You like Kat and/or want a chill place and a cute domain name: https://toot.cat
You want to take more time to make a more informed choice: https://joinmastodon.org

P.S. You can always move to a new account. Mastodon has a migration feature that leaves a "tombstone" behind and helps you move over to your new account. Don't sweat this choice too much!

Step 2: Link Mastodon ↔ Twitter

Go here and authenticate with both accounts. It's safe.
Go here and enable crossposting both ways (if that's what you want).
BONUS: Copy my advanced settings:
- Mastodon -> Twitter
- Twitter -> Mastodon

Step 3: Get a Mobile Client

Android: There's an Official App, or Tusky
iOS: There's an Official App, or Toot!
Windows/macOS/Linux: Sengi
Or, just use the web interface, which is pretty good! It also works as a Progressive Web App, so you can set it up as a "standalone" app!

Step 4: Make Friends!

Check out your instance's local and federated timelines for interesting stuff.
Link this article on Twitter and get your friends to join.
Follow me on Mastodon: zkat@toot.cat
Send me a message by @-ing @zkat@toot.cat hello world!

Step 5: Sh*tpost

Do the thing! Welcome to the Fediverse 💞

If you want a more in-depth guide, check out https://github.com/joyeusenoelle/GuideToMastodon

Effective Codes of Conduct

Kat Marchán — Wed, 16 Oct 2019 21:10:11 +0000

Introduction

It's 2019 and the issue by now seems to be mostly settled: Codes of Conduct, as it turns out, are an important tool for any community to promote inclusion and protect their members from harassment that would otherwise distract them or push them away.

But what's the actual experience of designing one, and more importantly, enforcing one?

I was an admin on lgbtq.technology, a community Slack for LGBTQ+ members of the tech industry, for over two years. It had a couple of thousand members, with several hundred active across scores of channels. It was (and still is!) a vibrant community that brought together fairly wide representation of individuals.

In this article, I'll go over the story of how community management evolved in this particular community. Along the way, I'll share various hard-earned lessons myself and the rest of the admin team there learned about how to effectively manage a diverse community -- and how to use policy to make it inclusive.

In the Beginning, One Big House Party

It all started with a tweet. And just like that, a new Slack was born.

I don't think anyone, much less Laurie, really expected the space to take off the way it did, but before he knew it, he was being bombarded with requests to join. The space grew quickly as news spread in the twittersphere, through Laurie's fairly sizeable following and connections in the SF queer scene.

As with any community, it didn't take long for conflict to start. There was a fundamental misunderstanding between community members: some founding members expected it to be "one big house party" where people were implicitly expected to behave well, but that didn't work out too well. You see, there were people joining who were not like them. They were people of color, or trans people, or bi people, or all sorts of folks that cis, gay, white men were not necessarily used to interacting with.

Within a couple of weeks of its creation, some members drafted a Code of Conduct based on the flurry of discussions around the topic, and what to do about conflict in this new community. Some people left, but others had already left because of what they'd run into. Lesson learned.

Problems With Code of Conduct Enforcement

Codes of Conduct are not enough to promote a healthy community. Whether they work is a function of the community itself, the processes that have been put in place, and the specific group of people tasked with handling their rules.

Then the new community ran into the next problem: enforcement.

For a long time, enforcement was treated as a binary: You either behave "well enough", and you get to stay, or you "violate the CoC" or "anger the wrong person", and next thing you know, you're permanently banned -- and permanent bans they were.

Having a binary over bans created an "unofficial" way to manage conflict. Many people felt discouraged from reporting violations or "making a fuss" about them because they didn't want to be responsible for someone getting banned. Those on the other end of the report would often react aggressively and defensively when confronted by staff, because being found "guilty" meant they would lose access to a space they found valuable. There was no policy for bringing someone back into a space, after any length of time.

In reality there was a lot of leeway at the staff level. Many conflicts were resolved by just private messaging someone and having a conversation with them. But any time a conflict became public or enough people made a fuss, the reported person would lash out, and get banned more for their lashing out than their actual behavior.

An Experiment: WeAllJS

Ongoing conflicts over community management in lgbtq.technology's #meta channel eventually reached a point where it became clear us admins needed to try something else. The problem was, the large community we already had wasn't the best place to be experimenting with new ideas.

So I went and started a new one: WeAllJS, a new community Slack for JavaScript developers.

It was premised on a few ideas I wanted to play with, and eventually bring back to LGBTQ.tech:

Communities could be made for everyone while still making space for marginalized people.
Codes of Conduct could be very detailed, and communities could be made to follow them.
Emphasizing a healthy enforcement process could resolve conflict without resulting in bans or extra conflict.

WeAllJS had all the bits I wished I could've experimented with in lgbtq.technology. I wrote a new Code of Conduct for it, as well as a custom Slack bot which added the concept of a "private channel listing" where members could request invites into the channel but not see their contents right off the bat. Also important was the fact that from the very beginning, the admin staff was composed of LGBTQ people, people of color, women and non-binary people.

The experiment was fairly successful. I think the best part of it turned out to be the enforcement process itself. You'll notice that the WeAllJS CoC leads with enforcement rules, first of all, but also that those rules include the entire community in its enforcement, and the rules aren't absolute. As it turns out, violations in WeAllJS are commonplace, due to its detailed CoC, but to this day, only a single person has been permanently banned from the space, and that after plenty of warnings and very caring conversations. For an online community with no demographic restrictions on its membership and about 1700 members, over the course of three years, this is an amazing fact, to me.

Following my report on my experiences over in WeAllJS, lgbtq.technology ended up adopting a similar enforcement process in its Code of Conduct. It also adopted Wheelie, the Slack bot, as well as the WeAllJS channel system!

Conclusion, and Next Steps

So how can you put all this to use in your own communities and open source projects? Having a code of conduct is a given these days, but what else?

Include clear enforcement procedures either in the CoC itself, or somewhere obviously connected to it.
Customize your code of conduct to be relevant to your community! Don't just grab the Contributor Covenant and call it a day. That borders on irresponsible.
If you want a starting point, consider the WeAllJS CoC, or WeAllBehave for your open source projects.
Consider employing a consultant, preferable a person of color, to look over your CoC and give you more advice about your community.

And that just about wraps this up! I hope this article has proven useful and provided some context over the process and concerns surrounding codes of conduct!

I'm the former tech lead for the NPM CLI, and I've been doing FOSS for 10+ years, Ask Me Anything!

Kat Marchán — Tue, 03 Sep 2019 22:39:19 +0000

Hi! My name's Kat, and I've been an FOSS dev for over a decade.

I had the opportunity of being, and eventually tech-leading, the NPM CLI team which I was a part of from 2015 until a couple of months ago. I'm the one who wrote things like npx, npm ci, and I helped design and add package-lock.json and much of its behavior to the CLI, and I was the main author of the ~40x+ speedup between npm@4 and npm@5 and later that made the CLI catch up (and often surpass) Yarn and PNPM in performance.

I also do a lot of Rust these days, and I'm currently on the NuGet client team at Microsoft, the package manager for the .NET ecosystem. I'm also on the core dev team for the Entropic client, ds, trying to build a new, distributed package manager for the JavaScript community!

AMA!

A System for Sustainable FOSS

Kat Marchán — Tue, 03 Sep 2019 01:52:25 +0000

Disclaimers: This system is still a work in process. I look forward to reading (and incorporating!) your (constructive!) feedback and I hope to evolve this into a fully usable model that anyone can Just Adopt™. I am also not a lawyer. And even if I were, I am not your lawyer. Don't take any of this as legal advice or in any way legally sound. If you want to make sure this is legally sound for you, get your lawyer to look at it. Finally, I'm in no way affiliated with License Zero. I am writing this because I think it's created some great tools to achieve what we're trying to do here.

Before you read anything else, note this: This whole thing focuses on developer tools -- it's not intended to be used as-is for things like libraries, databases, or operating systems. It does cover compilers, linters, package managers, bundlers, and all sorts of other such tooling. My hope is that by being more focused on a specific class of software, we can have a better chance of succeeding.

This isn't to say this model can't apply to other use cases. It's just that I won't cover here the implications for those other cases, and there might be some surprising complexities in implementation for those.

The Entire System, Summarized

Since this post is meant to be used as a reference post, here's the entire model in one place. Click through the various links for a detailed explanation of the how and why of each step!

Apply the Parity License to your project.
Apply the Apache 2.0 License to your project's third-party contributions.
Set up a patronage/crowdfunding platform, and make sure it has a tier that grants licenses to sponsors.
Apply the Patron License to your project.
(Optional) Handle additional licensing with other License Zero licenses.
Read about why do this whole thing in the first place.
Quit your day job when the above makes enough money for you. Congratulations, you have a working free software business now!

The Model, in Detail

The model I'm proposing involves moving our communities back towards a Free Software model -- by which I mean, using so-called Copyleft licensing -- and using that to direct funding towards maintainers in order to compensate them for their labor. This proposed workflow is not fundamentally different from the licensing model used by companies like Red Hat or MongoDB, but it is more specific and adapted to smaller projects maintained by only one or only a couple of devs, and it's also designed to be possible for "devtools" maintainers, a usage gap not covered by most licenses used by those larger open source companies. I'll summarize the entire model in the end, but first, some background on the motivations behind all this.

The Parity License

Apply the Parity License to your project.

The first step in this model is using a strong copyleft license -- something like the AGPL, but in this case, I prefer the Parity License, due to its closing of the "devtools loophole" -- that is, it imposes the share-alike requirement on anyone using your developer tooling (linters, compilers/transpilers, editors, etc.), not just people "linking" or in the case of the Affero GPL, "using your service".

To apply the license, simply copy the license text into a LICENSE-PARITY file in the root of your tool. If you're using a package manager that recognized SPDX license expressions (like NPM and Cargo), the ID you're looking for is Parity-6.0.0.

Considering how many small-team open source projects out there are actually developer tools, I believe this is a critical gap that needs bridging. The Parity License also comes with the benefit of being way more readable to humans, and even includes clear forgiveness for those who weren't aware of the particulars of the license, so long as they start complying with the terms after finding out. Another favorite part about this license for me is that it allows others to license their own software in a more permissive license than Parity itself, so it's not the same kind of "viral" as other copyleft licenses.

What are we trying to get out of this licensing decision?

Make sure everyone in the free software community is able to use our software freely, so long as they are also sharing their software.
Open the doors to licensing arrangements so people and corporations looking to write proprietary software have to give back in some way.
Close any usage loopholes that would allow proprietary users to bypass these expectations.

Third Party Contributions

Apply the Apache 2.0 License to your project's third-party contributions.

Of course, once we start dealing with copyleft with the intention of granting proprietary licenses, we come up to probably the trickiest part of this entire model: making sure that people can still contribute to your project.

This is the part where I can only give vague advice, as a non-lawyer, but this is my own personal understanding is that every single contributor to your project must agree to one of several alternatives, if you're to be able to pull off this workflow:

Agree to license their own changes under a permissive license (like MIT or Apache 2.0).
Agree to grant you the ability to grant private licenses to third parties, while retaining their own copyright.
Assign their copyrights to you.

Which one you pick is ultimately up to you, but you must make sure that this is made clear and explicit, for example, through note on your CONTRIBUTING.md, or a Contributor License Agreement.

For the purposes of this blog post, we'll go with the first alternative: having third-party contributions licensed under Apache 2.0. Apache 2.0 is a VERY permissive license, much like the MIT and BSD0 license, except it also has language granting patent permissions, which is considered pretty important nowadays.

So go ahead and copy the text of the license and put it in a file called LICENSE-APACHE in your project's root folder. If you're using a package manager with a license field, the new SPDX expression for it would be Parity-6.0.0 AND Apache-2.0, so add that in as well.

If you want to go the other routes, or you still want to use a CLA even for the Apache licensing, you can go over to Project Harmony for some templates, and even an Agreement Selector. You can also set up a CLA bot for your GitHub repository to automate the process of signing these.

But wait, you ask, this whole exercise is about sustainability and software freedom. Why do contributors have to give up so much for no reward? My answer to that is that you shouldn't accept nontrivial patches from contributors without some kind of compensation. Once you're making money from this whole setup, I believe it is the ethical thing to do to offer some part of that to contributors that submit nontrivial changes to your project. Going further, regular contributors should be made full collaborators on the project and you should split the proceeds from your sponsorships and license agreements more fairly with them. The specifics are up to you -- and them.

Crowdfunding Platforms

Set up a patronage/crowdfunding platform, and make sure it has a tier that grants licenses to sponsors.

You have a few choices here, depending on your team:

If you're the only core dev on your project, I recommend signing up for GitHub Sponsors or Patreon if that's not available (as of this writing, Sponsors is still in beta and sponsors accounts are being granted in a trickle as GH figures out the kinks).
If you're on a team, I recommend using something like OpenCollective or similar.

You should set up some basic tiers with rewards you're willing to give your sponsors. This can be things like provide X number of hours of support, adding them to a "thank you" list in your README, or even have their logo emblazoned on your project site. Be creative!

The most important thing here, though, is to decide which of the tiers will grant people a license to use your software in closed source scenarios. Since this essentially will amount to a subscription, I recommend you aim at a reasonable number here, taking that into account.

The Patron License

Apply the Patron License to your project.

Go ahead and download the Patron License and fill it out, then stick it into PATRONAGE.md in your project root.

This bit of legalese is what will grant individual subscription licenses to anyone who wants to use your software for proprietary purposes. It's important to note that these will be single developer licenses, and will only last so long as their sponsorship does.

But what if you want to grant bulk licenses to someone, or an entity? Or let a friend or friendly project have a one-off blanket waiver to the terms of your license? That's where additional licensing comes in.

Handling Additional Licensing

Handle additional licensing with other License Zero licenses.

Now, there's a couple of important licensing scenarios here I haven't covered yet. What do you do if you just want to grant a one-off waiver to a friend or collaborator? What about selling single-purchase licenses? Or bulk enterprise licenses to enterprises? Yes, in that case, you'll need more specialized licensing.

Some of these use-cases are already covered by the License Zero tools so I recommend you head on over and install their tool and use it to grant waivers and private licenses to your heart's content!

Again, just to restate it: I am in no way affiliated with License Zero and all of this is purely because I think their tooling and licensing is the best means to the ends I'm trying to achieve here. I'm more than happy to give them a boost because of that!

Anyway that's that! You're done! Go forth and create awesome things! Happy hacking!

Some Background

The rise of Free and Open Source software, the Cult of GitHub, the ecosystems spawned by language-centered package managers, and corporate acceptance and participation in Open Source have created an incredibly unsustainable situation where freely sharing one's source code and work has become the norm, rather than the exception, for vast communities of developers, be it professionals, hobbyists, or students. So much so, that we've come to expect availability of source code in a multitude of cases where closed source was previously normalized. The dream of Open Source (as defined by the Open Source Initiative), is practically achieved.

But where does that leave us?

In getting swept away by the thrill of popularity, the excitement of other people willingly using our code to achieve great things, I believe we have gotten a bit ahead of ourselves and forgotten to care about what's most important: our own selves and our well-being.

Free Software, as defined by the FSF and other Free Software advocates, had the answer to some of this: by creating a world of free software, where certain rights were reciprocally guaranteed, we would be able to ensure the long-term sustainability of our communities and be able to push away corporate exploitation. This was achieved through software licensing that was in many ways hostile to corporate interests, but friendly to the communities developing the software: "I'll scratch your back, so long as you scratch mine."

Alas, the OSI and its efforts annihilated much of the then-rising popularity of this model, and I believe this was to the immense detriment of our communities.

You see, while many developers (and the corporations that employ them) are happily using software freely available through GitHub, NPM, Ruby Gems, and various other distribution methods, maintainers are hitting their breaking point in what's become a bit of an open source sustainability crisis: maintainers are burning out, overwhelmed by the demands of an increasingly large community on a project they are usually only allowed to work on in their "spare" time, while simultaneously being punished for any attempts at implementing more sustainable models, such as the recent advertisement-based funding controversy.

For some reason, maintainers are expected to work on what is essentially a full time job, for free, or to rely on basic charity that ultimately only benefits those who are popular enough, such as crowdfunding and sponsorship platforms. Remember that work is work, even when you're doing open source, and that pressuring people into doing work for free for you is ultimately unethical.

After some time thinking and examining various possibilities, I believe I've come up with one way to change this for the better: A way for maintainers to be able to justify spending their time on their projects while continuing to ensure the free availability of source code, and without relying on the charity of strangers to do so. That is, going from charity into a fair deal.

CHANGELOG

Updated the former CLA section to instead recommend that third-party contributions be licensed under Apache-2.0 or a similar permissive license to make the whole process easier. CLA documentation stayed in place for those interested in going that route.