24.5 Protecting Yourself as a Maintainer¶

Open source maintainership can be deeply rewarding—your code helps people, you're part of a global community, and you develop skills that matter. But it can also be exhausting, isolating, and sometimes dangerous. Maintainers face demanding users, corporations expecting free support, sophisticated social engineering attacks, and occasionally harassment. The XZ Utils incident showed that attackers specifically target maintainer burnout as a vulnerability to exploit.

Your personal wellbeing isn't separate from project security—it's foundational to it. A burned-out maintainer makes mistakes, accepts help uncritically, and may miss social engineering attempts. Protecting yourself protects your project and your users. This section addresses the human side of maintainership: recognizing threats to your wellbeing, setting sustainable boundaries, and knowing when and how to step back.

Recognizing Social Engineering Attempts¶

The XZ Utils compromise succeeded because the attacker exploited a maintainer who was overwhelmed and desperate for help. Understanding social engineering patterns helps you recognize when you're being manipulated.

Social engineering red flags (XZ Utils patterns):

Red flags in contributor behavior:

• Pushing for elevated access faster than warranted
• Becoming unusually interested in build systems or CI/CD
• Dismissing security concerns as paranoia
• Creating urgency around their specific contributions
• Discouraging involvement of other maintainers
• Making you feel guilty for normal scrutiny

When to be extra cautious:

• When you're exhausted or overwhelmed
• When someone seems "too good to be true"
• When you feel pressured to bypass normal processes
• When contributors show interest specifically in security-sensitive areas
• When multiple "independent" voices align suspiciously

Many maintainers who have experienced social engineering attacks report similar patterns in retrospect: exhaustion made them want to believe offers of help were genuine, which is exactly what attackers counted on.

Protective responses:

• "I appreciate your contribution, but I need to follow our normal review process."
• "I'll review this when I have time to do it properly."
• "I'd like another maintainer to look at this before we proceed."
• "I don't feel comfortable with this timeline."

Managing Pressure and Burnout¶

Maintainer burnout is endemic in open source.

Burnout signs:

Burnout prevention strategies:

According to the 2021 Tidelift survey, 46% of maintainers are unpaid, yet users and corporations often expect immediate responses and continuous support. Sustainable practices are essential:

1. Set sustainable pace: Open source is a marathon, not a sprint
2. Define "enough" work per week
3. Protect time for non-project activities

4. Take breaks without guilt

5. Manage expectations explicitly:

6. Response time estimates in README/SECURITY.md
7. Clear statement that this is volunteer work (if it is)

8. Documented scope of what you will and won't do

9. Distribute load:

10. Recruit co-maintainers before you desperately need them
11. Delegate specific responsibilities

12. Empower trusted contributors to help triage

13. Limit exposure to negativity:

14. Triage notifications; don't read every comment immediately
15. Use email filters to batch non-urgent issues

16. Take breaks from social media during controversies

17. Celebrate wins:

18. Acknowledge releases and milestones
19. Keep record of positive feedback
20. Remember the good your project does

When you're already burned out:

• It's okay to step back (see below)
• Take a break without announcing a timeline
• Ask for help—from co-maintainers, community, or mental health professionals
• Consider whether you want to continue at all

Setting Boundaries with Users and Companies¶

Maintainers often struggle to set boundaries because they care about their users. But boundaries protect both you and your project.

Boundary setting strategies:

With demanding users:

"I understand this issue is important to you. However, this is a 
volunteer-maintained project, and I can't guarantee response times.

If you need faster resolution, options include:
- Contributing a fix yourself
- Hiring someone to create a fix (we welcome PRs)
- Using commercial alternatives with support SLAs

I'll get to this when I can."

With companies expecting free support:

"This project is provided as-is under [license]. While I'm happy to 
review community contributions, I'm not able to provide consulting 
or priority support for commercial users.

If your organization needs support, please consider:
- Sponsoring development through [link]
- Engaging a consultant to work on your needs
- Contributing engineering resources directly"

With scope creep requests:

"Thank you for the feature suggestion. However, this is outside the 
scope of what I intend for this project.

You're welcome to:
- Fork the project and add this yourself
- Create a plugin/extension if our architecture supports it
- Start a separate project that builds on this one"

Boundaries to establish:

• Response time expectations (not SLAs, but realistic estimates)
• Scope of the project (what you will and won't add)
• Support boundaries (community support, not personalized help)
• Communication channels (where you will and won't respond)
• Availability (weekends, holidays, etc.)

Document boundaries in your project:

# Support & Response Times

This is a volunteer-maintained project. I work on it when I can.

- Security issues: I try to respond within 1 week
- Bug reports: No guaranteed timeline
- Feature requests: May never be implemented

For urgent needs, please consider commercial alternatives or 
contributing fixes directly.

When to Say No or Step Back¶

Saying no is essential for sustainable maintainership. Stepping back—temporarily or permanently—is sometimes the healthiest choice.

Saying no:

You can say no to: - Features that don't fit your vision - Contributions that aren't maintainable - Support requests beyond what you offer - Timelines you can't meet - Responsibilities you didn't sign up for

How to say no gracefully:

• Acknowledge the request/effort
• Explain briefly why you're declining
• Offer alternatives where possible
• Don't apologize excessively
• Don't argue or justify repeatedly

"Thank you for this PR. I can see you put significant effort into it.

Unfortunately, I'm not going to merge this because [reason]. This 
isn't about the quality of your work—it's about what I want for 
this project's direction.

You're welcome to maintain a fork if this functionality is 
important to you."

Graceful step-back approaches:

Temporary break:

"I'm stepping away from active maintenance for [duration/indefinitely].

During this time:
- Security issues: [email/alternative contact]
- Regular issues: May not be addressed
- PRs: Review will be delayed

I hope to return [when/maybe], but make no promises."

Finding successors:

"I'm looking for new maintainers for this project.

What's needed:
- [Technical requirements]
- [Time commitment]
- [Any philosophical alignment]

If you're interested, please [contact method]. I'm happy to support 
a transition."

Archiving:

"After [X years], I'm archiving this project.

This means:
- No new features or bug fixes
- No security support
- Repository remains available but read-only

For alternatives, consider: [list alternatives]

Thank you to everyone who contributed over the years."

It's okay to step back because:

• You're burned out
• Life circumstances changed
• You lost interest
• The project succeeded beyond your ability to maintain
• You want to do something else
• Any reason at all—you don't owe anyone free labor

Community Support and Mental Health Resources¶

Maintainership can be isolating, but you're not alone. Communities exist specifically to support maintainers.

Mental health resources:

Community support resources:

Peer support:

• Connect with other maintainers who understand the challenges
• Attend maintainer-focused events and meetups
• Join maintainer Slack/Discord communities
• Talk to people who've navigated similar situations

Many maintainers find that connecting with peers who understand the unique challenges of open source work is transformative. Fellow maintainers can offer insights and support that friends outside tech may not fully grasp.

Documenting and Reporting Harassment¶

Some maintainers face harassment—ranging from aggressive demands to threats. Document everything and report where possible.

Harassment documentation:

Documentation format:

# Harassment Log

### Incident 1 - 2024-03-15

**Platform**: GitHub Issues
**Account**: @username
**Content**: [description or quote]
**Screenshot**: [filename]
**Your response**: [what you did]
**Notes**: [context, pattern, impact]

Reporting channels:

When to escalate:

• Threats of violence or harm
• Doxxing (publishing personal information)
• Persistent harassment despite blocking
• Coordinated harassment campaigns
• Harassment spreading to personal channels

Protecting yourself:

• Separate project identity from personal identity where possible
• Use project-specific email addresses
• Be cautious about sharing personal information
• Consider privacy settings on personal social media
• Have trusted community members handle hostile interactions

You don't have to engage:

• Block harassers without explanation
• Close issues without response if they're abusive
• Refuse to debate people acting in bad faith
• Walk away from toxic conversations

Recommendations¶

We recommend the following self-protection practices for maintainers:

1. Learn social engineering patterns: Understanding manipulation tactics—especially those used in the XZ incident—helps you recognize when you're being targeted.

2. Monitor your wellbeing: Burnout is a security vulnerability. Recognize the signs and take action before you're desperate for help from anyone willing to offer it.

3. Set boundaries explicitly: Document your availability, support scope, and response expectations. Saying no is a skill essential for sustainable maintainership.

4. Know when to step back: There's no shame in taking breaks, finding successors, or archiving projects. Your health and life matter more than any software.

5. Connect with community: Other maintainers understand your challenges. Peer support reduces isolation and provides practical wisdom.

6. Seek professional help when needed: Therapists, counselors, and mental health resources exist for a reason. Maintaining software doesn't mean you have to maintain yourself alone.

7. Document and report harassment: You don't deserve abuse. Document incidents, report to platforms, and involve authorities for serious threats.

8. Protect your personal information: Separate your project identity from personal identity where possible. Harassment is harder when harassers can't find your personal details.

Your project benefits from your continued health and engagement. Protecting yourself isn't selfish—it's essential for sustainable maintainership. The best thing you can do for your users is ensure you're in a position to keep maintaining the software they depend on.