Just a reminder that if you'd like to promote continued development of JSON tech like #jsonschema#jsonpath and others in #dotnet, please consider sponsoring the #maintainers.
Dnsmasq provides network addressing for small networks: DNS, DHCP, router advertisement and network boot.
Dnsmasq creator & maintainer Simon Kelley said: "This prize is valuable financially, but much more so as a mark of public recognition that dnsmasq is still something that's worth doing."
💲Software Needs To Be More Expensive | blog.glyph.im
「 For most maintainers, Tidelift pays a sub-hobbyist amount of money, and even setting it up (and GitHub Sponsors, etc) is a huge hassle. So even making the transition from “no income” to “a little bit of side-hustle income” may be prohibitively bureaucratic 」
I’m still processing everything, but I noticed some commonalities in the kinds of challenges #contributors are facing during this 2024 lonely burnout epoch (I’m not the only one who feels it right?)And I wonder if more #maintainers are facing them too.
So what are the toughest #community/ communications/ outreach challenges you’re tackling?
Little tip for when you're suggesting features to a project: "Feature Idea" sounds so much nicer than "Feature Request". Rather than sounding like "I want this, this is an order!", it's more like "Hey, this would be cool, what do you think?"
This also goes out to all the maintainers creating issue labels, by the way.
@clive I've thought about this a lot regarding the relationship of #OpenSource projects with industry as there are a lot of similarities in the power relationships there. I hope that the #OpenAI debacle leads to more #Maintainers recognizing that they have sway. I fear it is just going to lead to stronger corporate pressure to control "their" pet projects.
You make the leap of faith that this stranger will stick around and be responsive for weeks/months of intermittent communication.
Or you don't. You ignore the patch, or leave it for a "later" that never comes. Or you explicitly say it's not good enough & you'd rather do it yourself, & close the thread.
Following up on the investigation about "GitHub Discussions." We need the input from Open Source maintainers who use this feature on GitHub to understand your expectations and the real benefits of using this feature:
New blog post on user support frustration, its causes, and how we could build the "infrastructure of equanimity" in #opensource, including ideas for potential cross-project tools & practices.
Shout-outs to @davidism, Heidi Waterhouse, @offby1, @jacob, Nicole Harris, @bernard, + @georgia for work & conversations that I built on in this piece.
What specific mindset shifts can help #maintainers retain equanimity? I think each #maintainer needs to consider power & economics, develop their own analysis of what they & users owe to each other, AND reflect on their own needs/personality. Then, they ought to use those assessments to define their limits + publicly set expectations.
Collective supports:
A shared blocklist, or at least a warning flag
Boilerplate policies
Flagging old resources as old
Shared UX research efforts
I was thinking about a model for doing Free Code maintainership.
I know a few older hackers who can't be bothered writing whole software packages themselves anymore. But if there's a project they personally use or care about, and they're familiar with the programming language(s) used (or willing to brush up), they might be willing to review and merge patches.
Sparing enthusiastic coders from review duties, and maybe increasing code quality.
At #PyConUS2023, @davidism facilitated an open space discussion of "maintainer #burnout, how to survive it, and maybe how to prevent it." Our notes, my analysis, and useful links in a new blog post: