The Maintainer Hire-Terms Read: Standard Offer, Maintainer Terms, or Leave Be

Run this read once you have found the maintainer of a repository your team depends on, and before you contact them. It answers two questions: can this person be hired at all, and if so, will a normal offer work or do they need protected project time and an IP carve-out? It is for in-house recruiters, sourcers, talent leaders, and founders doing their own hiring. You score six public signals and get one of three verdicts. Each verdict comes with an angle for the first message and a list of offer terms for legal to approve before the first call.

What does the Maintainer Hire-Terms Read decide?

It decides which of three verdicts fits one maintainer, before anyone reaches out: Standard Offer, Maintainer Terms, or Leave Be. Each verdict needs its own first message and its own legal preparation. Pick the wrong one and you lose either the relationship or the offer.

• Standard Offer. The person is only loosely tied to the project, or the project is far from your business. A normal offer and a normal pitch will work. You still do one routine check of the prior-inventions schedule.
• Maintainer Terms. The person is central to the project and nobody pays them to keep it going. They will probably only move if they can keep the project. The offer therefore needs protected time and an IP carve-out, approved by legal before the first call. An IP carve-out is a contract clause that leaves named project work with the employee.
• Leave Be. An employer already pays this person to maintain a project they are central to. Nothing you can offer right now beats that, and a pitch could cost you the goodwill of someone your stack depends on. Support the project and check again later.

Most sourcing advice for open source ends at "find contributors on GitHub and personalize the message." That gets you to the right person. It doesn't answer the two questions that sink these hires. First, is someone already paying them for this work? Second, will a standard invention-assignment clause take their project away from them? An invention-assignment clause is the contract term that gives the employer ownership of what the employee creates.

Who pays maintainers, in numbers

The most useful public survey of maintainer income is Tidelift's maintainer report, which had 437 respondents. Its figures shape the first dimension of the read.

Two rows change how you score. The first is the gap between 60% and 47%. Both figures mean "unpaid", but they differ by 13 points because the questions were worded differently: some people who call themselves hobbyists still get a little money. The second is salary. The 24% paid through salary because maintenance is part of their job never appear on a sponsor page. If you only look at funding listings, you will miss every salaried maintainer.

The same survey found that 12% earn most or all of their income from maintaining, and 24% earn part of it. Among unpaid maintainers, 44% would like to be paid and 16% would not.

Where do maintainers show up, and why do titles miss them?

Repository records find maintainers far more reliably than job titles do. Most maintainers don't put the word in their headline, so a title search gives you a thin, lopsided list that misses whole ecosystems.

Refolk's index of professional profiles shows the size of the gap:

The employer field can mislead too, but in a useful way. In Refolk's index, 3 of the top 10 US employers listed by self-described maintainers are a foundation or project, not a company: CNCF, AboutCode.org, and the literal label "Open Source". In Germany, 2 of the top 10 are freelance or project labels: "Freiberuflich" and YaCy.net. These top-10 lists come from samples of 25 profiles, so read them as a pattern, not a full count. They show that a foundation or project name in the employer field is a signal for the affiliation dimension. Check it against commit records before you score it.

Keywords also produce false matches. In the same sample, "maintainer" matched employees of MaintainX, a company, in 2 of 25 profiles.

In practice, use titles to start a list and score from repository records. Refolk searches GitHub, LinkedIn, and the open web together. You can ask for maintainers by the project they maintain instead of the word in their headline, and you get the person back with their public profile attached.

The six dimensions and how to score each one

Score each dimension 0, 1, or 2 from public evidence. The first three measure lock: how much an employer already pays this person for this work. The last three measure attachment: how much the person and the project need protected time and an IP carve-out.

Write the evidence next to every score. If you can't back a score with a link or a commit range, it is a guess. Score guesses as 1 and flag them.

1. Who pays for the maintenance

What it proves: whether money already reaches this person for this work, and where it comes from. Check sponsor and donation listings, donation-program participation, and Tidelift participation. Score 2 only when maintenance is an explicit part of a job. You infer that from dimension 2, not from a funding page.

When it lies: an empty sponsor page does not mean unpaid, because salary never shows up there. A "hobbyist" self-label doesn't mean unpaid either. The 13-point survey gap shows that some hobbyists accept donations. If the only evidence is a self-label, score 0 and mark it as weak.

2. Employer-affiliation stability

What it proves: whether one employer has backed this work steadily. That is the strongest public stand-in for salaried maintenance. Build a dated employer timeline from the email domains on their commits, year by year. For CNCF projects, add CNCF's gitdm developers_affiliations files, which map each developer's emails to companies with dates. An entry looks like "Atmark Techno Inc. until 2018-06-01 Space Cubics from 2018-06-01". Developers with no employer are marked "Independent". gitdm supplies the data for every CNCF DevStats project.

When it lies: the "until" dates in gitdm are edited by hand, and how often the files are regenerated is not public, so a file can be out of date. Check it against the email domains on their most recent commits. A maintainer who commits from a personal address at work will look independent when they aren't. If the timeline and the commit hours disagree, trust neither and score 1.

The most useful thing this dimension can show is a recent change of employer. It lowers the lock score and opens a window to approach them.

3. Commit-hour pattern

What it proves: whether the work happens inside a job. Riehle et al. treat 9am to 5pm local time, Monday to Friday, as working time and everything outside it as spare time. Their research estimates that about half of open-source development is paid work. Group commits by author date, not committer date, using the local timezone offset stored on each commit, and leave out merges. git log --no-merges --author=<email> --format='%aI %cI' prints each commit's author and committer dates side by side, with their offsets.

Look at frequency before timing. A study of the Rust project argues that how often someone contributes separates paid from volunteer work better than when they contribute. A steady daily or weekly rhythm over many months points to a job. Bursts with long gaps between them point to spare time. Survey data on hours agrees: 78% of unpaid hobbyists work 10 hours a week or less. In an earlier survey year, 81% of professional maintainers worked more than 20 hours a week, against 7% of hobbyists.

When it lies: a rebase changes the committer date but keeps the author date. A rebased or squashed branch shows almost the same time on every commit. Flags such as --committer-date-is-author-date and --reset-author-date rewrite dates. Some tools also drop the timezone offset, so a Berlin morning shows up as a California midnight.

4. Governance role

What it proves: the person's formal standing, which you will be asking them to keep in the offer. Read the project's MAINTAINERS or OWNERS files and any foundation governance records.

When it lies: these lists go out of date, and there is no known public schedule for updating them. A name in a MAINTAINERS file with no recent merges deserves 1 at most. Confirm the role against recent merges and releases.

5. How much the project needs this one person

What it proves: whether hiring this person changes the health of a dependency you rely on. Count who has merged and released recently. 61% of unpaid maintainers maintain alone, so this dimension tends to score high exactly when dimension 1 scores low. That combination pushes the verdict toward Maintainer Terms.

When it lies: co-maintainers who are listed but inactive make a solo project look shared. Count actions, not names.

6. Overlap with your business

What it proves: whether state law will still protect the candidate's project work after they sign. Score this with the hiring manager.

When it lies: hiring managers tend to play down overlap to keep a hire simple. Ask what the roadmap says, not just what ships today. New York, for example, judges whether an invention relates to the employer's business at the time it was conceived or first put into practice.

How do six scores become a verdict?

Add dimensions 1 to 3 to get the lock score (L, 0 to 6). Add dimensions 4 to 6 to get the attachment score (T, 0 to 6). Then read the verdict off the matrix. A business-overlap score of 2 sends the terms to legal whatever the verdict.

The rules, in order:

1. T is 0 to 2: Standard Offer. If L is 4 to 6, expect a counteroffer.
2. T is 3 to 6 and L is 0 to 3: Maintainer Terms.
3. T is 3 to 6 and L is 4 to 6: Leave Be for now.
4. Override: if business overlap scores 2, send the Exhibit A wording and carve-out language to legal, whatever the verdict.
5. Override: if the maintainer has said publicly that they don't want a job or pay, Leave Be. In the survey, 16% of unpaid maintainers said they don't want pay.

The Maintainer Terms quadrant tends to fill with one profile: solo maintainers of widely used packages who have signalled they are open to work.

First-message angle for each verdict

Money is a weaker opener than most recruiters assume. In one survey year, 58% of maintainers had quit (22%) or considered quitting (36%). Their reasons were:

• Other priorities: 54%
• Lost interest: 51%
• Burnout: 44%
• Not paid enough: 38%
• Too much time: 36%

An offer of less workload answers more of those reasons than salary does. For Leave Be, don't send a hiring message. Contribute to the project, sponsor it, or ask for advice. Don't expect a quick pull request to build trust fast: 66% of maintainers say they trust pull requests from non-maintainers less since xz.

Hi [name],

My team runs [project] in [where it sits in your stack], and from the issue tracker I can see how much of the release and review work lands on you.

I'm hiring for [role]. Before anything else about it: the offer I can put in front of you includes protected time for [project] written into the contract, and legal has already approved an IP carve-out that names the project, so you would not be signing it away.

If the bigger problem right now is workload rather than pay, I'd like to hear what would actually help, even if the answer is not this role.

Would a short call next week work?

[your name]

How to run the read on one maintainer

The procedure has eight steps. The sourcing work takes about two hours, and legal review takes another 1 to 3 days. Two points of order matter: score business overlap before you assume any carve-out applies, and look at commit frequency before commit timing.

The scorecard below keeps the evidence and the verdict in one place, so a second person can check the read.

Maintainer:
Repository:
Date of read:

LOCK (is someone already paying them for this work?)
1. Who pays                  0 / 1 / 2   Evidence:
2. Affiliation stability     0 / 1 / 2   Evidence:
3. Commit pattern            0 / 1 / 2   Evidence:
Lock score (L):      /6

ATTACHMENT (do they need protected time and an IP carve-out?)
4. Governance role           0 / 1 / 2   Evidence:
5. Dependence on this person 0 / 1 / 2   Evidence:
6. Business overlap          0 / 1 / 2   Evidence:
Attachment score (T):      /6

Verdict:  Standard Offer / Maintainer Terms / Leave Be
Overlap override (overlap = 2)?  Y / N
Candidate's state of residence:
Terms sent to legal on:
Check affiliation again on:

Which offer terms need legal clearance before the first call?

Clear four things before the first call for every Maintainer Terms verdict, and for any verdict where overlap scores 2. They are the Exhibit A entry, the law in the candidate's state, an explicit carve-out for the project in the contract, and the protected-time clause. Offers fall apart when these get worked out after the candidate has said yes.

State statutes

Ten states have an own-time carve-out: California, Delaware, Illinois, Kansas, Minnesota, New Jersey, New York, North Carolina, Utah, and Washington. Sources disagree on the count and cite 7, 8, or 10, so check the candidate's state directly against a current 50-state survey such as OpenAgreements'. The core test is the same in all of them: own time, own resources, and unrelated to the employer's business. Nevada and North Dakota go the other way and give the employer ownership by default. Minnesota has no timing condition like New York's.

The more the project overlaps your business, the less the state statute protects your candidate.

Exhibit A

Exhibit A, also called Schedule A or the Prior Inventions Schedule, is where the employee lists earlier projects with a name, an approximate date, and a description. Leaving it blank counts as a statement that there are no prior inventions. Listing the project is necessary, but it isn't enough. James Bottomley cites a standard clause under which the employee "will not incorporate any Prior Inventions into any products". If your company already ships the project, that clause works against the reason you are hiring. Legal has to rewrite it, not just accept the filled-in schedule.

Protected time

Primary job postings don't show a standard amount of protected time. Filippo Valsorda argues that funding for a maintainer should equal 25% to 100% of a software engineer's pay package, and says maintainers can command packages of $150k to $300k or more. One anonymous CTO forum post describes a 10% allowance for upstream work. That is weak evidence, so don't treat it as a benchmark. The Linux Foundation recommends making it easier for employees to contribute during work time. Base the allowance on the release and review load you saw in the repository, and put it in the written offer.

How does this read go wrong?

It usually goes wrong when one signal looks decisive and you trust it alone: a hobbyist label, a midnight commit, an old affiliation file, a headline keyword, or a carve-out you assumed would apply. Each has a cheap check, and skipping it is how a respected maintainer gets a generic pitch or an offer dies at the IP stage.

• Reading the hobbyist label as "unpaid". The 60% self-label overstates unpaid work by about 13 points compared with the 47% direct question. Check: look for donation income directly before scoring dimension 1 as 0.
• Reading off-hours commits as volunteer work. Some paid Linux committers commit at all hours. Check: use author date, not committer date, and look at commit frequency before timing.
• Treating rebase or squash bursts as real times. A rebased branch can show the same time on every commit. Check: compare AuthorDate with CommitDate. Leave out runs where they diverge or cluster.
• Trusting a stale affiliation file. gitdm "until" dates are edited by hand. Check: compare them with the email domains on the maintainer's most recent commits.
• Counting headline keyword matches as maintainers. In Refolk's index, "maintainer" matched MaintainX employees in 2 of 25 sampled profiles, and Rust maintainers hardly ever use the word (2 US profiles). Check: confirm every person against repository records.
• Letting a filled Exhibit A defeat the hire. A clause barring prior inventions from products conflicts with a company that already ships the project. Check: legal reviews the clause, not just the schedule, before the offer.
• Assuming a carve-out applies. If the project relates to the employer's business, state protection no longer applies. Check: score business overlap first, with the hiring manager, against the roadmap.

One more pattern is worth knowing. Unpaid maintainers work alone 61% of the time, so dimensions 1 and 5 often move together. If a profile scores salaried and solo at once, it's unusual. Check both scores again before you trust the verdict.

Keeping the read current

Lock scores go out of date fastest. Rerun the affiliation and funding checks before you reuse any old verdict, and treat Leave Be as "not now" rather than "never". A change of employer can move a maintainer from Leave Be to Maintainer Terms overnight.

• Check source freshness by mechanism, not memory. How often gitdm is regenerated is not public. Look at the date of the most recent commit to the repository before you rely on its affiliation entries.
• Expect attachment to shift. In the most recent survey year, 60% of maintainers had quit or considered quitting. A maintainer stepping back changes both their score and your exposure on that dependency.
• Set a recheck date on every Leave Be card. Then run the affiliation step again on that date, not when you happen to remember.

Saving the search that produced your list and running it again on the recheck date is the cheapest way to catch employer changes. Refolk returns the same people with their current public profile, so a changed affiliation shows up without you rebuilding the list by hand.