2026
OpenSourceHub
Open-source issues and code battles platform · built by Vikrant Kumar
A developer community for discovering open-source issues, chatting with contributors, and competing in fairly judged code battles.
The problem
Getting into open source is hard when you don't know where to start, and a GitHub profile shows almost nothing about how well someone actually codes. I wanted one place where a developer can find beginner-friendly issues on real repositories, follow and chat with other contributors, and prove their skills in head-to-head code battles. The battles had to be judged fairly enough that a win actually means something.
Decisions and why
No model decides who won
Every submission runs in a sandbox against hidden tests. Passing all of them is a gate, not a score. After that, players are ranked by runtime, then memory, then who finished first. The problem is only picked when the battle starts, so nobody, not even the person who created it, can prepare in advance.
A copy-detection threshold that was measured, not guessed
I ran the similarity check over a problem bank where every problem has two independently written solutions. The closest honest pair scored 89%. Every lazy copy (a paste, a reformat, added comments, a variable renamed everywhere) scored 100%. The line sits at 95%, with zero false positives across 94 pairs. A flag goes to a human reviewer instead of banning anyone automatically.
Ghost mode so there is always someone to play
A small community often has nobody online. Every judged submission becomes a permanent opponent: its code is copied into a new battle and judged again next to yours, in the same sandbox at the same time. Clicking 'Find a battle' first waits ten seconds for a live opponent. Only if nobody comes does it fall back to a ghost picked close to your own usual pace.
Test answers computed from two solutions, not written by hand
Every problem ships with two independent solutions and no expected outputs. Both solutions run over every input, and they have to agree. Whatever they print becomes the answer. If they disagree, the problem is thrown out, so a player with correct code never loses to a wrong answer key.
Editor telemetry as a signal, never a verdict
The editor records how code arrived: paste counts and sizes, typed characters, and how often the player switched tabs. It never records the content itself. These numbers are shown next to the result for a person to look at, not used to block anyone, because switching tabs to read the docs is allowed.
The hardest part
Making the app fast without guessing where the time went. Simple requests were taking over a second, but EXPLAIN ANALYZE showed the query itself running in 0.055 ms, so the database wasn't the problem. Logging every SQL statement showed the real cause: on Supabase's transaction pooler, Prisma wrapped each query in BEGIN, DEALLOCATE ALL, the query and COMMIT, which meant four network round trips for a single SELECT 1. Switching the long-running server to the session pooler made that query take 164 ms instead of 815 ms. Turning on join-based relation loading made the battle screen's main query a single SQL statement instead of three, bringing it from 1790 ms down to 185 ms against the production database. I also merged the rate limiter's two Redis commands into one round trip, which fixed a leak that left keys in Redis with no expiry.