Why we celebrate weekend projects while ignoring the people who keep open source alive.
There is something fundamentally wrong with how we celebrate software development today.
Build a project in 24 hours, add a polished UI, integrate a few APIs, prepare a convincing pitch, and present it to a panel of judges. You might win a prize, earn a certificate, gain visibility, or add an impressive project to your résumé.
Now spend six months maintaining a useful open-source library. Fix bugs. Review pull requests. Update dependencies. Improve documentation. Respond to confused users. Handle security vulnerabilities. Keep the project working as the ecosystem around it changes.
How many hackathon trophies will you receive for that?
Probably none.
That contrast reveals a problem worth discussing: we have become exceptionally good at rewarding software creation and remarkably bad at rewarding software maintenance.
1. The hackathon incentive problem
Hackathons are supposed to encourage experimentation, collaboration, and creative problem-solving. They can introduce people to new technologies, help beginners build confidence, and turn ideas into working prototypes.
The problem is not the hackathon itself. The problem is what its reward system often prioritizes.
A typical hackathon has a fixed deadline, limited judging time, and a strong emphasis on demonstrations. Under these constraints, teams have an incentive to optimize for what judges can see immediately.
A polished dashboard is visible. A working demo is exciting. An AI integration is easy to explain. A compelling presentation makes an idea memorable.
Good error handling, meaningful tests, clear documentation, maintainable architecture, and a reliable release process are much harder to demonstrate in five minutes.
Consequently, developers can be rewarded for building something that looks complete without proving that it is reliable, secure, or maintainable.
This does not mean every hackathon project is low quality. Nor does it mean every winning team ignores engineering fundamentals. It means the format can reward short-term demonstration more directly than long-term software quality.
When the evaluation window is 24 hours, the incentives naturally favor what can be built in 24 hours.
2. The graveyard of impressive repositories
Visit enough hackathon repositories and you may recognize a familiar pattern:
- The README contains screenshots, badges, and an ambitious feature list.
- The demo works under carefully controlled conditions.
- Setup instructions are incomplete or assume undocumented dependencies.
- There are few meaningful tests, or none at all.
- Configuration, secrets handling, and error cases receive little attention.
- The repository has no clear roadmap or plan for future maintenance.
- After the event, commits stop and issues remain unanswered.
The project might have been an excellent learning experience. It might even contain a genuinely useful idea.
But an interesting prototype and a dependable software project are not the same thing.
A repository being public does not automatically make it useful to the public. A project with a permissive license but no working installation instructions can be difficult to adopt. A promising tool that breaks after an upstream API changes may quickly become irrelevant.
The deeper issue is that publishing code is treated as the finish line when it should often be the beginning of the maintenance journey.
And this problem is not exclusive to hackathons. Personal side projects, startup MVPs, academic prototypes, and AI-generated repositories can suffer from the same incentives.
Hackathons simply make the mismatch especially visible because the deadline and judging criteria are so concentrated.
3. Software development does not end at the first commit
Software is not a static artifact. It exists in an environment that constantly changes.
Dependencies release new versions. APIs change. Operating systems evolve. Security vulnerabilities emerge. Users discover unexpected edge cases. Requirements shift.
A project that worked perfectly on launch day may stop working a few months later.
This is why maintenance includes much more than fixing obvious bugs. It involves:
- Bug fixing: Resolving issues that prevent users from relying on the software.
- Code review: Ensuring contributions do not introduce regressions or security problems.
- Dependency management: Keeping third-party packages compatible and secure.
- Documentation: Helping new users and contributors understand the project.
- Testing: Detecting regressions before they reach users.
- Release management: Packaging and publishing reliable versions.
- Community management: Triaging issues, reviewing proposals, and coordinating contributors.
Much of this work is invisible when everything goes well.
Users rarely celebrate the vulnerability that was patched before it could be exploited. They rarely notice the dependency upgrade that prevented a future compatibility issue. They may never know that a maintainer spent an evening reviewing a pull request instead of building something new.
Yet these activities determine whether software remains useful.
Open-source sustainability research has repeatedly highlighted the importance of funding, community support, manageable workloads, and recognition for maintainers. GitHub's Maintaining Balance for Open Source Maintainers also discusses burnout and the practical challenges of sustaining this work.
4. The people maintaining software are often the least celebrated
Consider two developers.
Developer A builds a new project during a weekend hackathon. The project wins a prize, receives social media attention, and attracts hundreds of stars.
Developer B has maintained a popular library for three years. They review contributions, fix regressions, improve performance, and respond to users who depend on the library.
Developer A has a clear achievement to showcase. Developer B has a long history of less visible work.
Both may have contributed real value. But the reward systems surrounding software development frequently make Developer A's achievement easier to recognize.
The consequences go beyond hurt feelings.
Developers respond to incentives. If new projects bring visibility, prizes, résumé value, and career opportunities while maintenance brings repetitive work and little recognition, developers have a rational reason to move on to the next new thing.
Why spend months improving an existing library when creating a new repository could provide a more visible accomplishment?
Why review someone else's pull requests when building your own product offers more opportunities for recognition?
Why take responsibility for a project when there is no clear reward for doing so?
Over time, this can create an unhealthy cycle: more projects are created, fewer receive sustained attention, and the burden falls on a relatively small number of people willing to keep important software running.
Maintainer burnout is not merely theoretical. In a 2023 survey discussed by Sonar, 58% of respondents said they had quit or considered quitting maintenance of at least one open-source project. The reported reasons included competing priorities, loss of interest, and burnout.
Source: Sonar — Maintainer burnout is real.
We should be careful not to attribute all abandoned repositories to hackathons. Projects naturally become obsolete, people's interests change, and not every prototype deserves years of support. The concern is that our incentives can encourage creation without encouraging responsible decisions about what happens next.
5. What if hackathons rewarded maintenance too?
We do not need to eliminate hackathons. We need to broaden our definition of a successful contribution.
Imagine a hackathon where teams can choose between building a new application and improving an existing open-source project.
One team builds a prototype for an innovative application.
Another team fixes a long-standing bug in an established library, adds regression tests, improves installation instructions, and submits a well-documented pull request.
A third team takes an abandoned but useful project, identifies its critical dependencies, restores its test suite, and creates a realistic maintenance roadmap.
Why should only the first team have a chance to win?
All three teams can produce meaningful outcomes. The difference is that their contributions solve different problems.
Hackathons could introduce dedicated categories such as:
- Best Maintainer Contribution: The most useful, well-tested improvement to an existing project.
- Best Bug Fix: A fix that resolves a real problem without introducing regressions.
- Best Documentation Improvement: Making an existing tool easier to understand and adopt.
- Best Security or Reliability Improvement: Strengthening an existing project's resilience.
- Best Long-Term Impact: A contribution evaluated after a follow-up period rather than only on demo day.
- Best Maintainer Experience: Reducing the effort required to review contributions, triage issues, or release software.
These categories would not need to replace innovation awards. They would simply recognize that innovation includes making existing technology more dependable.
6. Introduce a maintenance track with follow-up evaluation
A particularly useful change would be to evaluate certain projects after the hackathon instead of making every decision on presentation day.
For example, organizers could divide the competition into two tracks.
Track A: Build something new
Teams create prototypes, experiment with new ideas, and demonstrate what they have learned. Evaluation focuses on originality, usefulness, implementation, and responsible engineering.
Track B: Improve something that already exists
Teams work on existing repositories with genuine user needs. Evaluation considers the quality of the contribution, tests, documentation, maintainability, and feedback from project maintainers.
For the second track, organizers could reserve a portion of the award for a follow-up assessment 30–90 days later.
Did the contribution get merged? If not, was there a valid technical or project-specific reason? Did the tests pass? Was the documentation useful? Did the team respond constructively to review feedback?
A merged pull request should not be the only measure of success. Maintainers may reasonably reject a contribution because it conflicts with a project's direction or adds unnecessary complexity. The judging process should account for that.
The goal is not to force maintainers to accept hackathon submissions. It is to reward contributors for producing changes that meet real project needs.
A project that remains healthy six months later tells us something that a five-minute demo cannot.
7. Reward maintainers directly, not just contributors
Recognition is useful, but appreciation alone cannot sustain an ecosystem indefinitely.
If organizations benefit from open-source software, they should consider supporting the people who maintain it.
There are several practical approaches.
Financial rewards
Organizers could allocate a portion of prize money to existing project maintainers, particularly when teams build on their work or when a maintenance contribution directly benefits their project.
Sponsors could fund small maintenance grants for critical libraries, infrastructure tools, and under-resourced projects.
Longer-term programs could offer recurring support for maintainers who take responsibility for releases, security updates, and community coordination.
Recognition and career opportunities
Hackathons could issue maintainer awards that recognize sustained contributions rather than isolated output.
Recruiters and sponsoring companies could evaluate meaningful maintenance work alongside new-project portfolios. Reviewing complex pull requests, managing releases, and improving reliability are genuine engineering skills.
Communities could also publish maintainer spotlights that explain the impact of the work rather than merely listing commit counts.
Time and infrastructure
Rewards do not have to be cash alone.
Maintainers may benefit from access to testing infrastructure, security audits, hosting credits, documentation support, contributor onboarding assistance, and dedicated time to address technical debt.
These resources can make maintenance easier without creating another obligation to deliver flashy features.
Shared responsibility
Projects should not have to depend indefinitely on a single exhausted developer.
Organizations can help establish co-maintainers, documented release procedures, clear contribution guidelines, and succession plans. Users can contribute through testing, documentation, issue triage, and sponsorship instead of expecting the maintainer to do everything.
The Open Source Pledge is one example of an initiative encouraging companies to financially support open-source maintenance.
The larger principle is simple: if an ecosystem depends on maintainers, it should create incentives for people to become and remain maintainers.
8. But won't rewarding maintenance encourage meaningless activity?
This is a legitimate concern.
If we award points for every commit, people may split trivial changes into dozens of commits. If we reward closed issues, contributors may focus on easy issues rather than important problems. If funding is based only on repository popularity, essential but less visible infrastructure may remain neglected.
A poorly designed maintenance award could become another vanity contest.
Therefore, rewards should focus on outcomes and project context rather than raw activity.
A reasonable evaluation framework might consider:
- Usefulness: Does the change solve a real problem for users or maintainers?
- Quality: Are the implementation, tests, and documentation appropriate?
- Maintainability: Can future contributors understand and safely modify the code?
- Collaboration: Did the contributor communicate with maintainers and respond to feedback?
- Sustainability: Does the contribution reduce future maintenance costs or improve the project's ability to remain healthy?
Not every criterion needs a numerical score. Experienced reviewers should be able to evaluate context, and small projects should not be forced to meet enterprise-level processes just to participate.
We should also avoid measuring maintainers solely by how quickly they respond. Maintainers have jobs, families, studies, and lives outside their repositories. A healthy project is not one where a volunteer answers every issue within an hour.
The objective is to reward meaningful work without turning open-source maintenance into a competition for the most activity.
9. A better definition of developer success
There is nothing inherently wrong with creating a new repository. New ideas matter. Prototypes help us learn. Hackathons are valuable environments for experimentation, especially for students and early-career developers.
But we should stop confusing novelty with lasting impact.
A developer who creates a useful tool has contributed something valuable. A developer who keeps that tool secure, reliable, documented, and usable for years has contributed something valuable too.
Sometimes the most impactful contribution is not another framework, another dashboard, another AI wrapper, or another application with a promising README.
Sometimes it is fixing the bug that has frustrated users for months.
Sometimes it is documenting an obscure configuration option.
Sometimes it is reviewing a security-sensitive pull request carefully enough to prevent a serious mistake.
Sometimes it is deciding that a project can no longer be maintained and helping users migrate responsibly.
These contributions may not produce the most exciting demos, but they are part of what makes software trustworthy.
Conclusion: Build new things, but take responsibility for what already exists
The future of open source should not be a choice between innovation and maintenance.
We need people who experiment with new ideas, and we need people who ensure that useful ideas survive. We need hackathons that encourage creativity, and we need reward systems that recognize reliability, documentation, testing, and long-term responsibility.
The next generation of hackathons could help change the culture by making maintenance a first-class category, funding meaningful improvements, involving existing maintainers in judging, and recognizing contributions that remain useful after the event ends.
We should ask not only, "What did you build this weekend?" but also, "What did you improve, who benefits from it, and will it still be useful six months from now?"
A repository created in a day can be impressive. A project sustained for years can be transformative.
Let's stop treating the first commit as the whole achievement. Reward the people who make sure it is not the last meaningful one.
Top comments (0)