Open source contribution and job search as matching markets under AI-induced congestion

Apr 18, 2026 matching market market design

In one of my previous posts, I discussed congestion in the job market caused by the surge of AI tools that scrape job descriptions and auto-apply to jobs. I suggested pay-to-apply as a possible solution, where payment is made with platform-issued virtual points available in limited supply rather than real money. I focused more on explaining why dynamic pricing can solve the problem better than AI screening tools, and I did not go into the details of matching market design.

Since that post, another problem has emerged: progress in the capabilities of coding agents has caused a sharp rise in vibe-coded pull requests in open source repositories on GitHub. This problem can also be framed as a matching-market congestion problem.

This problem is not particularly new. It is well researched and described in detail in "Who Gets What―and Why: The New Economics of Matchmaking and Market Design" by Alvin Roth, a winner of the Nobel Prize in Economics.

I became familiar with the problem while working in a services marketplace and solving matching-market-related problems there. That gave me direct practical experience with the typical issues.

In this post, I want to share that experience and knowledge. I will:

• Explain the concepts of matching markets, market failure, friction, and congestion.
• Provide examples of matching markets with a congestion problem.
• Consider job search and open source contribution markets, and how AI tools create a congestion problem there.
• Describe common patterns: how the congestion problem appears.
• Propose a possible market design to solve the problem.

For simplicity, I consider only two-sided markets here.

Warning: this is a long read. I wrote it myself and only used AI to check for grammar, punctuation, logical errors, and awkward wording. I really hope you find it interesting and useful.

Matching markets #

Difference between matching and commodity markets #

A two-sided matching market is a market in which both sides have to make a choice to get what they want, unlike a commodity market, where only one side chooses. Amazon is an example of a commodity marketplace: when a customer places an order, the seller does not get to choose whether to sell to that customer. Examples of matching markets include:

• Job market.
• Dating platforms, like Tinder and Bumble.
• Platforms for freelancers, like Upwork and Fiverr.

Generally, turning a matching market into a commodity market increases the number of matches. For example, Airbnb increased the number of bookings on the platform when it introduced the instant book feature, eliminating the host approval step.

Not all matching markets can be effectively turned into commodity markets, because both sides can have unique preferences that can be resolved only through interaction.

Optimal matching problem and market failure #

In a simplified form, the matching problem can be framed as maximizing the total number of matches given a number of searchers on each side of the market. An example from the job market is maximizing the number of hires given a number of candidates and a number of vacancies.

In reality, not all matches are equal. For example, a candidate's satisfaction depends on the job they find, and a firm's performance depends on the candidate it hires. So the quality of matches matters. In other words, different matches have different economic value for both sides of a market.

In a more precise form, the matching problem can be framed as maximizing the total value created for both sides of the market by the matches that are formed. When the actual economic value from formed matches is lower than it could be, I will call it a market failure.

In other words, market failure can happen for two reasons:

• Fewer matches are formed than possible.
• Average economic value per match is lower than possible.

Market friction and congestion #

Market friction is any obstacle that makes it harder for mutually good matches to form, leading to market failure. That includes:

• search costs,
• application costs,
• incomplete information,
• screening costs,
• interaction costs,
• communication delays,
• and similar barriers.

There is also a more specific congestion problem: there are too many potential interactions to process in the time or attention available. In matching markets, this shows up when hospitals, schools, firms, or users receive more applications, messages, or candidates than they can reasonably evaluate, so some promising opportunities are never screened or are screened too late.

Matching market examples #

Services marketplace #

As the first example, let's consider a services marketplace: a two-sided matching platform where customers can find professionals, and professionals can find customers.

The matching process:

• Customers place orders and describe the details of the work.
• Professionals search, choose orders, and send proposals to the customers.
• The customers review the proposals and choose the professionals, or do not choose anyone.
• If a professional sends a proposal to a customer, and the customer chooses the professional, that results in a deal.

Professionals pay the marketplace for opportunities and deals. Market efficiency heavily depends on the monetization model. Possible options:

• Pay-to-apply: a professional pays for each proposal they send to a customer.
• Pay-per-contact: a professional pays for a customer's phone number, with the customer's approval. This contact exchange happens after the professional's proposal, the customer's review of that proposal, and some interaction between the professional and the customer in the built-in chat.
• Pay-per-deal: a professional pays for a deal with a customer, the last step of the funnel.

Pay-to-apply is an example of a matching market application cost, a particular case of market friction. It turns out that reducing this friction by implementing pay-per-contact or pay-per-deal models can create a congestion problem and cause a market failure. How can this happen?

Let's consider the step in which professionals search and evaluate orders. Their experience allows them to estimate the likelihood of a deal for each particular order. Careful evaluation before deciding whether to apply can reduce application costs. But evaluation consumes time and cognitive resources. It makes sense only when evaluation costs outweigh the reduction in application costs.

When pay-to-apply is the only monetization model, careful evaluation before sending a proposal to a customer reduces total cost per deal. By cost, I mean time, money, and cognitive resources.

With pay-per-contact or pay-per-deal, the application cost is lower. In that case, it is less rational for professionals to spend time evaluating orders, because it does not save them much: they can always refuse after a short interaction with a customer. Moreover, skipping evaluation helps them be the first to apply, which increases the chances of a deal. So these monetization models create incentives for professionals to send proposals to as many new orders as they can find with minimal evaluation.

This behavior can create a congestion problem:

• There are too many proposals for customers to process.
• Some proposals are not considered, including potentially the best matches.
• Some deals do not happen. And even when they do, they are not optimal in terms of economic value for either customers or professionals.

There are two ways the marketplace can mitigate this problem:

1. Use pay-to-apply as the only monetization model.
2. Implement pay-per-contact and/or pay-per-deal with restrictions:
   • Limit the number of proposals a professional can send per unit of time, depending on their individual conversion from proposal to a "useful interaction".
   • Limit and/or delay the access to the most popular orders, depending on professionals' individual conversion from proposal to a "useful interaction".

Dating platform #

Dating platforms are another example of matching markets. Let's consider Tinder:

• People create a profile with photos and a short bio, then browse nearby users.
• You swipe right if you’re interested and left if you’re not.
• If two people both swipe right on each other, it becomes a match and they can chat in the app.

We will focus on male-female matching there. The market design is symmetrical, but the market balance is not: there are roughly three men for every one woman. The probability of a match is much lower for men. In this example, men are the long side of the market, while women are the short side. The long side can be viewed as the side that searches and applies, and the short side as the side that reviews and approves or rejects.

In a 3:1 market balance, screening each profile thoroughly before swiping becomes exhausting. This leads to the following behavior:

• Many users on the long side swipe right on almost everyone. Only after there is a match do they screen it and decide whether to start a chat.
• Users on the short side get overloaded and must spend more effort screening.
• As users on the short side face more noise, they become more selective, and the cycle reinforces itself.

This is another example of the congestion problem.

Tinder limits the number of right-swipes for free-tier users, but it is unlimited on paid subscriptions.

In the paper "Facilitating the Search for Partners on Matching Platforms", Yash Kanoria and Daniela Saban explain dating platform users' behavior with a theoretical model. They also propose a market design to deal with the congestion problem: force the short side of the market to initiate contact with potential partners, by disallowing the long side from doing so.

Markets with AI-induced congestion problem #

Job market #

In the job market, congestion occurs when too many candidates apply for a job. Recruiters' and hiring managers' attention is scarce. As a result, some applications are not considered, some are considered too late, and good candidates are rejected.

In some segments, the problem already existed in the pre-AI era. AI tools have taken it to the next level:

• Candidates use AI to find and submit more applications faster.
• Employers respond with more AI screening.
• That creates a self-reinforcing feedback loop.

AI tools reduce employers' screening costs, but that can still lead to market failure because of information asymmetry:

• No matter how advanced the AI models are, they lack crucial information about a candidate's fit for the job, and that limits their predictive ability.
• As a result, good candidates are rejected, including potentially the best fit, and less economic value is created.

A better solution would be to encourage candidates to use their own knowledge of their skills, screen jobs more carefully, and apply more selectively. In other words, we need better market design, not just better tools using the same information.

Open source contribution market #

Open source contributions can also be viewed as a matching market with two sides: contributors and projects.

• Developers select the projects they want to contribute to, develop new features or fix bugs, and then create pull requests to merge their changes.
• Project members screen and review the suggested changes, provide feedback, and then merge or reject them.

Progress in the capabilities of AI coding agents has made it possible to create more contributions. Moreover, these tools have lowered the barrier to entry for new contributors. As a result, the number of pull requests in popular projects has increased, but their average quality has decreased.

In many cases, project members do not have enough capacity to review all incoming pull requests. As a result, some high-quality contributions are not accepted or not even considered, and a lower number of useful features and fixes are merged. In other words, less economic value is created, and the market fails.

Common pattern #

A common pattern across the examples above:

• Lowering search and application costs increases the number of applications.
• Reviewers' capacity is limited, review and interaction costs are high relative to search and application costs.
• Some applications are considered with a delay or not considered at all.
• As a result, fewer matches are formed and average value per match decreases.

In some cases, there is an effort to increase review capacity by automating part of the process. This is often not very effective and can reinforce the feedback loop: more applications → stricter review → even more applications. The reason is information asymmetry: the reviewing side has limited information and cannot automate selection effectively; a costly interaction with the applicant is often needed to resolve preferences.

From my personal experience in a services marketplace, the following changes in market design can be more effective:

• Increasing application cost.
• Implementing personalized restrictions based on the applicant's "reputation" and the efficiency of previous applications.

The main reason this works better is that applicants are pushed to screen and apply more selectively, using the information available only to them, such as their skills and preferences.

Market design proposition #

Goal and hypothesis #

In this section, I propose a new design for the open source contribution market. Since most open source projects are hosted on a single platform, GitHub, and most interactions happen there, it is more feasible to implement than a similar design would be in the job market.

The goal is to increase the number of valuable merged contributions while decreasing the time and attention project members spend reviewing low-value pull requests and issues.

The hypothesis is that the suggested market design would drive two evolutionary processes:

• Mutation: contributors would change their behavior by creating more useful and less "low-value" pull requests and issues.
• Selection: "low-value" contributors unwilling to adapt would be restricted from creating pull requests and issues.

The difference from biological evolution is that mutation is not random.

Rules and processes #

First, let's introduce new concepts and rules:

• Creating a pull request or an issue requires a deposit.
• The deposit requirement is denominated in reputation credits.
• Both contributors and projects have reputation credit balances.
• By default, a contributor cannot create a pull request or an issue if their credit balance is below the deposit requirement.
• Both sides earn reputation credits through merged pull requests.
• Reputation credits can also be provided or loaned by the platform under certain conditions.
• Reputation credits cannot be bought or sold in exchange for real-world money.
• Reputation credits cannot be transferred between contributors or projects.

Matching process for pull requests:

• A contributor creates a pull request.
• The deposit for the pull request is reserved from their balance.
• Project members review the pull request and interact with the contributor, including through code changes in the pull request.
• As a result of interaction, the pull request is either merged or rejected.
• If the pull request is merged, the reserved deposit is returned to the contributor's balance. Also, additional credits are issued and added to both the contributor's and the project's balances. The amount is determined by the contributor's and the project's credit balances.
• If the pull request is rejected, the reserved deposit is debited from the contributor's balance, but not added to the project's balance. As an exception, project members can choose not to debit the contributor's balance, or to debit it only partially. This does not affect the project balance in any way.

Matching process for issues is similar, with an exception: additional credits are not added to the contributor or the project balances.

Additional details:

• Deposit requirements can differ among projects, they are defined by project members.
• In general, deposit requirements differ for creating pull requests and issues.
• The deposit requirement for a pull request can have fixed and variable components, for example per net LOC added.
• To avoid wrong incentives, credit balances are visible only to their owners.

There are also edge cases to consider. For example, a pull request might be created but not reviewed for a long time. But those details are out of scope for this post.

Why it should work #

The deposit requirement plays the same role in balancing supply (contributors) and demand (projects) as prices do in more traditional markets. Project members can use it to adjust the quantity and quality of incoming pull requests and issues.

Popular projects are expected to have higher deposit requirements on average.

The design increases application costs for contributors and pushes them to put more care into pull requests and issues.

Contributors with low-quality pull requests and issues will have lower credit balances and thus be restricted from contributing to popular projects.

Conclusions #

In this post, I examine job search and open source contribution as matching markets under congestion: AI tools lower search and application costs, which can increase volume while reducing matching quality.

When submitting an application or pull request becomes cheap, applicants screen and apply less carefully and send more low-value attempts. Because reviewer attention is scarce, some high-value submissions are reviewed too late or not at all.

The relevant solution is not simply better automated application screening, but better market design. It would make applicants bear more of the cost of low-value submissions and reveal more of their private information through selective behavior.

The proposed design relies on a good old economic principle: if something is scarce, use pricing to distribute it. The deposit requirement plays a role similar to price in balancing supply and demand, and reputation credits are the unit in which that price is denominated.

This does not mean that such a system is easy to implement or free of tradeoffs. Reputation gaming, entry barriers, and onboarding of new contributors would all require careful design. Still, the broader point remains: when AI creates congestion in a matching market, the right response is often to redesign incentives, not only to automate filtering.

Resources #

Here is a list of resources I find useful for studying matching markets in general and the congestion problem in particular:

• Roth, A. E. (2016). Who Gets What―and Why: The New Economics of Matchmaking and Market Design.
• Kanoria, Y. and Saban, D. (2020). Facilitating the Search for Partners on Matching Platforms.
• Matching theory (Wikipedia).
• Stable matching theory (Wikipedia).

Appendix. Creation of new reputation credits in the proposed market design #

In the proposed market design, the total number of reputation credits in the system increases when value is created through merged pull requests, and decreases when time and attention is wasted on rejected pull requests.

It is worth going into detail on how the additional reputation credits can be calculated. Possible formulas:

$$\Delta Y = \ln(1 + \alpha X)$$ $$\Delta X = \ln(1 + \beta Y)$$

• $X$ is the number of contributor reputation credits before creation of the pull request.
• $Y$ is the number of project reputation credits before creation of the pull request.
• $\Delta X$ is the number of additional reputation credits added to the contributor balance.
• $\Delta Y$ is the number of additional reputation credits added to the project balance.
• $\alpha$ and $\beta$ are small positive constants managed by the platform.
• $\ln$ is the natural logarithm function.

Possible alterations:

• Use an additional multiplier designating the amount of work done in a pull request. It should probably be kept secret to avoid reputation gaming.
• Replace $\ln(1 + \alpha X)$ and $\ln(1 + \beta Y)$ with other increasing concave functions of $X$ and $Y$ respectively.

Important properties:

• The higher the project's credit balance, the larger the increase in the contributor's credits after a pull request is merged, and vice versa. This protects the system from reputation gaming when a contributor creates a fake project and merges useless pull requests just to inflate their credits.
• The increasing concave form of the reputation-creation functions at least partially protects the system from excessive inequality, or a "rich get richer" dynamic.

There are other issues, risks, and edge cases. For example:

• Initializing the system.
• Entry barriers and onboarding for new contributors.
• Inflation of the average deposit requirement over time.
• Reputation expiration.

They can be resolved with more sophisticated rules and formulas. But for this article, I wanted to keep the model as simple as possible so the main idea would be easier to grasp.

© Evgeny Ivanov 2026