DEV Community: Rahul Kumar

In most open source projects we measured, one person gives most of the first answers

Rahul Kumar — Thu, 05 Nov 2026 19:35:12 +0000

Porchlamp followed 95,078 first pull requests, each from someone who hadn't sent that project a pull request in about six months or more. Projects that lean on one person answer them within a day at least as often as projects that share the job.

One person gives over half of first answers: 79% of 2,843 projects
Merged where one person gives 90% or more: 56% of first pull requests in the typical project, against 43% where nobody gives over half
Silent at two weeks, then asked: 28% got an answer in the next 30 days, against 14% with no comment in the same projects
Merged, counting every pull request: 32% of first pull requests, against 47% for people who had sent one before

In 1,175 of 2,843 projects, one person gives 90% or more of the first answers

Count who gives the first answer to each outside pull request, and the median project has 3 people giving first answers at all. In 79% of these projects, one person gives more than half of them. Fame barely changes it: among 266 projects with 50,000 stars or more, it's 73%, with a median of 4 people.

Only projects with at least 20 first answers we could attribute to a person. Known bots are left out; a few automation accounts that look like people remain.

More first pull requests get merged where one person does the answering

In the typical project where one person gives 90% or more of the first answers, 56% of first pull requests get merged. Where nobody gives more than half, it's 43%. Answers within two weeks lean the same way, 75% against 64%, but that gap is smaller and less sure.

Stars and volume don't explain the merges. Comparing only projects with similar stars and a similar number of first pull requests, the gap is 13 percentage points (95% range 8 to 18). Leaving out projects owned by the busiest person's own account, and projects where only one person answers at all, leaves 140 and 92 projects and a gap of 13 percentage points (95% range 7 to 19). The same two comparisons in answers give 6 points (1 to 12) and 4 points (−3 to 11).

The typical project is the median of 1,199 projects with at least 20 first answers we could attribute to a person and at least 10 first pull requests at least 14 days old: 702 with one person at 90% or more, 93 with nobody over half. Each project counts once, so a busy one weighs no more than a small one, and a project has to answer often to clear that floor. That's why these shares run higher than the page's counts by pull request: 47% answered within two weeks, 32% merged. Another 961 projects have at least 10 first pull requests and fewer than 20 such answers: the typical one answers 23% of its first pull requests within two weeks. In 572 of them one person gave nearly all of the few answers, and the typical one answers 30%.

One possible reason is the bystander effect: a job that's clearly one person's gets done, and a job that's everyone's can wait. This compares projects, so it can't prove that. Shared projects may also get harder pull requests or have stricter rules for merging.

Authors who asked got about 9 percentage points more answers. A comment with no ask and no tag got none.

Of first pull requests silent at two weeks, 28% got an answer in the next 30 days (by day 44) if the author had asked in the past week, with words like "friendly ping" or "could you take a look". In the same projects, with no comment after the first hour, it was 14%. Part of that gap comes from which projects get asked. Inside one project, about 9 percentage points remain. A comment with no ask and no tag shows nothing.

First pull requests silent at two weeks, 286 with a recent ask in 236 projects. Lines show the 95% range. Across all outside pull requests the same comparison gives 8 points (6 to 10) for asking, from 1,821 pull requests in 850 projects, and 0.3 points (−0.8 to 1.3) for a comment with no ask and no tag.

Merges follow: by the end of the data, 19% merged against 9%, or 5.5 points inside one project (1.4 to 9.7). An ask in the first week shows less: 2.3 points (−0.9 to 5.6), measured at one week.

Authors who ask may also care more, or have a better pull request. A comment with no ask and no tag shows no gap, which argues against plain engagement as the whole explanation. This still compares what happened and doesn't prove that asking causes the answer.

After two weeks of silence, the odds of a merge have more than halved

More than half of first pull requests, 53%, hear nothing from the project's people for two weeks, and the longer the silence, the lower the odds of a merge. Each point counts pull requests at least four months old that had no answer by that day, and how many of them were merged in the end: 17% after a week of silence, 13% after two weeks, 9% after a month, 5% after two months. By then the two lines nearly meet, at 5% and 6%.

A late answer is still possible. Of first pull requests silent at two weeks, 11% hear something by day 30, 21% by day 60 and 27% by day 90.

Share merged by the end of the data, at least four months after opening, by days with no answer. 24,917 first pull requests are old enough to count. An answer means a reply or review from the project's people, a merge, or a close by them.

The first pull request waits longest

Within a day, 25% of first pull requests have an answer, against 33% for people the project has seen before. After two weeks the gap is still there: 47% against 60%.

The time scale is logarithmic, and the shares allow for pull requests too young to tell or closed by their author. 95,078 first and 83,226 returning pull requests.

Weekend pull requests wait longer

Inside the same project, weekday pull requests beat weekend ones in 69% of 2,261 projects, by a median of 6 percentage points.

All outside pull requests, days in UTC, including the busiest projects that the first and returning figures leave out, so don't compare these shares with those. The inside-a-project figure uses projects with at least 30 weekday and 10 weekend pull requests. Weekend senders may differ from weekday ones, which that comparison only partly removes.

Ten projects that answer first-timers quickly and merge their work

Picked by hand from the 800 projects with at least 25 first pull requests old enough to judge, so this isn't a ranking. All ten answered at least 78% of them within a day and merged at least 52%. Most have under 60 first pull requests, so read them as examples. These count first pull requests only, so each differs from the number on the project's Porchlamp page, which counts every outside pull request.

Project	Typical first answer	Within a day	Merged	First PRs
smallvec (small vectors for Rust)	58 minutes	97%	72%	36
PostCSS (tool for transforming CSS)	1.2 hours	88%	70%	33
Faker (fake data for tests)	1.6 hours	90%	83%	30
freeCodeCamp (free coding curriculum)	1.8 hours	80%	52%	238
bgfx (cross-platform graphics library)	2.4 hours	87%	80%	30
Learn Git Branching (interactive Git tutorial)	3 hours	93%	96%	28
Tracy (frame profiler)	3.2 hours	89%	71%	28
croc (send files between computers)	3.5 hours	78%	78%	36
Quinn (QUIC in Rust)	4 hours	83%	56%	54
calibre (e-book manager)	4.8 hours	92%	81%	36

How this was measured

Data. Porchlamp's 2026-11-05 snapshot holds 1,726,945 outside pull requests opened from 27 April 2026 to 24 October 2026, across 10,998 projects with a record. These results read 592,986 of them, those with recorded replies after the rules below.
Left out. Bots, drafts never marked ready, accounts under 90 days old, and project members, including anyone the record shows merging or closing someone else's pull request, whatever GitHub's label says. In very busy projects, replies are read from the snapshot's even random sample.
First pull request. The author has no earlier pull request to that project in its record of the past 365 days or in the window. Every pull request here opened in the last six months, so the look-back runs from about six months to a year. Only projects whose record isn't cut off at its cap of about 500 can tell, so most of the busiest projects are missing. The split covers 178,304 of the 592,986 pull requests read, 30%.
Which results use what. The waiting curve, the answered-by curve and the listed projects use first pull requests only. So do the asking figures unless a line says all outside pull requests, and the answered and merged shares beside who answers. The weekday results and who gives the first answers use all outside pull requests.
Who answers. The person behind the first answer to each outside pull request: who wrote the reply or review, or who merged it. Known bots are left out. A project counts once, whatever its size, so the shares beside who answers are the median project's. The comparison of similar projects uses bands of stars (under 3,000, 3,000 to 10,000, 10,000 to 30,000, 30,000 or more) and of first pull requests (under 15, 15 to 30, 30 to 60, 60 or more), and the 95% range comes from resampling projects.
An answer. The earliest reply or review from the project's people, a merge, or a close by them. A reply needs at least 40 characters, and automated greetings and replies from bots don't count. The clock starts when a draft is marked ready.
Asking. A comment from the author after the first hour, matched against a word list: ping, bump, gentle nudge, could you review, take a look, any update and similar. A hand check of 60 matches found 57 real asks. The list also misses requests: of 60 comments that only tagged someone, 25 were asking. Tool commands and CLA signatures aren't asks, but they do count as commenting. The baseline is no comment after the first hour. The inside-one-project gap compares the groups project by project, weighted by how many each has (Mantel-Haenszel), and the 95% range comes from resampling projects. We tightened the word list after a first look at the data, so this is a result to test again on the next snapshot.
Waiting curve. Pull requests at least four months old. One an author closed unanswered drops out from that day. The 53% in the waiting section uses all 95,078 and treats an author closing their own pull request as leaving the count, so it doesn't divide out from the curve's table.

Not covered

Why a project didn't answer. Silence may mean a closed list, a mailing-list workflow, or a pull request nobody wanted.
Not seen. Merges after the record's date, and any pull request's quality or size.
Cause. All of this describes what happened, including who answers and the asking and weekday comparisons. Authors who ask may also care more, or have a better pull request, and projects with shared answering may get harder ones.
When that person stops. We didn't measure what happens to a project when its one answerer leaves.
Six months is one season. Volume and answer rates may move with the time of year.

The original page has the waiting-curve slider, every point in a table, the numbers as JSON, and a lookup for your own pull requests.

30 open source projects to contribute to that actually answer your pull request

Rahul Kumar — Tue, 03 Nov 2026 20:29:10 +0000

You can spend an evening on a fix, send the pull request, and hear nothing for weeks.

I track this in Porchlamp, a ranking I built of open source projects by what happens to pull requests from outsiders. At the typical ranked project, the first human reply takes about 19.5 hours.

The 30 projects below are much quicker. At every one, half the outside pull requests hear from a person in under four and a half hours.

How to use this list

Pick a language, then a project you already use. Add /contribute to its GitHub address, like github.com/curl/curl/contribute. That page lists open issues marked for newcomers.

Rust

The compiler itself is here. Half the outside pull requests to rust-lang/rust get a human reply in about 70 minutes.

Project	What it is	Median first reply
probe-rs/probe-rs	Debugging tools for embedded ARM and RISC-V	58 min
ruffle-rs/ruffle	A Flash Player emulator	1.0 h
rust-lang/rust	The Rust compiler and standard library	1.2 h
rust-lang/cargo	The Rust package manager	1.4 h
servo/servo	A lightweight browser engine	1.4 h

Python

Astronomers answer quickest here: Astropy's median is 1.8 hours.

Project	What it is	Median first reply
astropy/astropy	Core library for astronomy	1.8 h
pallets/click	A toolkit for command line interfaces	2.5 h
numpy/numpy	The core package for scientific computing	3.4 h
inventree/InvenTree	Inventory management you host yourself	3.4 h
home-assistant/core	Home automation with local control	4.2 h

JavaScript

freeCodeCamp has more than 450,000 stars and still replies in about two and a half hours.

Project	What it is	Median first reply
ag-grid/ag-grid	A data table for web apps	45 min
playcanvas/engine	A web graphics runtime	1.7 h
faker-js/faker	Generates fake data for tests	1.8 h
RaspberryPiFoundation/blockly	A visual programming editor	1.9 h
freeCodeCamp/freeCodeCamp	The learning platform and its curriculum	2.5 h

Go

Dolt, a database you can branch and merge like Git, replies in 24 minutes.

Project	What it is	Median first reply
dolthub/dolt	Git for data	24 min
hajimehoshi/ebiten	A simple 2D game engine	41 min
k3s-io/k3s	Lightweight Kubernetes	1.7 h
go-gitea/gitea	Self-hosted Git service	1.7 h
pulumi/pulumi	Infrastructure as code	3.2 h

Java

JabRef manages BibTeX libraries for people who write papers, and it replies in under two hours.

Project	What it is	Median first reply
vespa-engine/vespa	A search and AI platform	1.3 h
crate/crate	A distributed SQL database	1.6 h
traccar/traccar	A GPS tracking platform	1.8 h
JabRef/jabref	A reference manager	1.9 h
strimzi/strimzi-kafka-operator	Apache Kafka on Kubernetes	3.7 h

C and C++

Stockfish, the chess engine, and curl both reply in under three hours.

Project	What it is	Median first reply
RIOT-OS/RIOT	An operating system for IoT	1.2 h
RPCS3/rpcs3	A PlayStation 3 emulator	1.4 h
libsdl-org/SDL	Cross-platform media library	2.0 h
official-stockfish/Stockfish	A strong open chess engine	2.3 h
curl/curl	The tool and library for fetching URLs	2.7 h

What normal looks like

More than half of the 3,246 projects I could time give a first reply within a day. Rust and C and C++ are quickest; Python takes longest.

So if you've waited a week, you're past the median at more than 9 in 10 of them. A short, polite comment is fair at that point.

Check your own project

Every ranked project has a page with its reply time and how many outsiders heard nothing. Search for yours on porchlamp.org.

Longer lists, ordered by reply time: Rust, Python, JavaScript, Go, Java, C and C++.

Ranked for first-time contributors: Rust, Python, JavaScript, Go, Java, C and C++.

How I picked these
Numbers come from Porchlamp's snapshot of 2 November 2026, covering pull requests from 27 April to 24 October 2026.

"Outside" leaves out bots, drafts, pull requests their authors closed, brand-new accounts and each project's own members.

To qualify, a project needed all of these:

at least 100 timed outside pull requests
under 10% with no reply within 14 days
a place in the top 1,500 of the 4,044 ranked projects

I dropped medians under 15 minutes, which can be automation rather than a person. From the rest I took five open source projects per language that I thought readers would know.

A fast first reply is not a merge. It tells you someone is reading.

Which project answered you fastest? I'd like to check it against the numbers.

How to tell if an open-source project will answer your pull request

Rahul Kumar — Sat, 24 Oct 2026 18:06:47 +0000

Before you send a pull request to a project you don't know, ask one question first: will anyone answer it?

I followed 1.4 million pull requests to 11,000 GitHub projects to see how much the answer varies. A lot.

At some projects, half the outside pull requests get a human reply within about 30 minutes. At more than 1 in 8 of the projects I could judge, most outsiders hear nothing for two weeks.

The check

On the project's GitHub page, open Pull requests and search for is:pr is:closed.
Open five recent ones whose authors are not labelled Member, Owner or Collaborator. Those labels mark insiders.
For each, note how long the first comment or review from a human took. Skip bots.

If most of the five heard back within a day or two, that's a good sign. If they waited weeks, yours may too.

What normal looks like

At 2,300 projects there were enough replies to time. At more than half of them, the median first reply comes within a day, and one in ten takes longer than a week.

So if you've waited a week, you're past the median at 9 in 10 of these projects. A short, polite comment asking whether anything is needed from you is fair at that point.

The fast end

These eight are well known and quick. Ebiten and Nomad have a median first reply of about half an hour; cargo, Servo, k3s, Stockfish, Click and React Hook Form all come in under three hours. If you want a quick answer on a first contribution, they are good places to start.

A high star count is no guarantee

12 of the 100 most-starred projects leave most outside pull requests with no human answer for two weeks. Stars measure popularity. Whether anyone reads the queue is a separate question.

Skip the counting

Porchlamp does this count for 2,300 projects. Each project's page opens with its median first reply and the share of outside pull requests that got no reply within two weeks. I built it.

How I counted
I followed 1,442,863 pull requests from 227,260 outside contributors to 11,000 GitHub projects, from 25 April to 22 October 2026 (Porchlamp's snapshot of 25 October 2026). Bots, drafts, pull requests their authors closed, brand-new accounts and each project's own members are not counted. A project is judged when it is licensed, maintained software with at least 10 counted outside pull requests; 4,168 were. "Most outsiders hear nothing" means a black hole: with 95% confidence, more than half of those pull requests got no human reply, review, merge or close within 14 days. Reply times come from the 2,300 ranked projects with enough timed replies. For projects with more than 2,000 pull requests, replies are read on an even random sample of 1,000. I picked the eight named projects from the fast group; each had at least 100 timed outside pull requests.

What's the longest you've waited on a pull request, and did it ever get merged?

Keras to TFLite on Android: wrong normalization and a backwards top-5

Rahul Kumar — Thu, 22 Oct 2026 02:16:39 +0000

For a photo of a quail, my Android app's top-5 code picks American alligator, sea cucumber, barracouta, reel and sea
urchin. The model is right; the app is not. It keeps the five worst labels, and it scales the pixels with the wrong
numbers.

I added LiteRT export to Keras (keras#21674) and its PyTorch path
(keras#22758), so the export was the part I trusted. The scores and
labels below come from a run on 22 October 2026 on a computer's CPU, with the app's preprocessing and top-5 code copied into
Python. I did not run the app on a phone for this post.

The export: one call

LiteRT is the new name of TensorFlow Lite; the files still end in .tflite. The
keras.io guide installs Keras, KerasHub and litert-torch from their main
branches. On 22 October 2026 that broke this export, with
'tfl.batch_matmul' op found invalid output rank, expected 3 but got 4. The released versions worked:

pip install torch \
    --index-url https://download.pytorch.org/whl/cpu
pip install keras==3.15.1 keras-hub==0.32.0 \
    litert-torch==0.10.0 ai-edge-litert==2.3.0

Then the whole export, from my app's README:

# Run with KERAS_BACKEND=torch set in the shell.
import keras_hub, torch

m = keras_hub.models.MobileNetImageClassifier.from_preset(
    "mobilenet_v3_small_100_imagenet")
m.export("/tmp/mobilenetv3.tflite", format="litert",
         input_signature=[torch.randn(1, 224, 224, 3)])

from_preset loads a KerasHub preset: a pretrained model, fetched by name. input_signature fixes the input to one
224 by 224 colour image, because the PyTorch export path needs one fixed shape
(keras#22997). The keras.io guide picks the PyTorch backend because
its files need no flex ops, the TensorFlow ops that the new LiteRT Android runtime cannot run. With the pinned
versions it wrote a 10,255,480-byte file.

Bug 1: the pixel numbers

The exported file starts after preprocessing: calling a KerasHub model directly "does not apply preprocessing"
(pipeline_model.py).
So the app has to resize and normalize every photo itself, with the numbers the model was trained with. My app reads
them from a sidecar, a small JSON file that sits next to the model file.

The sample sidecar in my app's tests uses 127.5 for every mean and standard deviation. The preset's own
preprocessor.json
uses ImageNet's numbers, a different pair for each colour:

Nothing crashes, and on my quail photo the answer did not even change: quail stayed first, but its raw score fell
from 10.11 to 9.72. A wrong number that leaves the top answer alone is easy to ship. The fix is to copy the preset's
numbers instead of guessing them: mean is -offset / scale and std is 1 / scale, on pixels from 0 to 255. As a
sidecar:

{
  "task": "image_classification",
  "image_width": 224,
  "image_height": 224,
  "normalization": {
    "mean": [123.675, 116.28, 103.53],
    "std": [58.395, 57.12, 57.375]
  },
  "labels": "imagenet_labels.txt",
  "num_classes": 1000
}

Bug 2: the top-5 list

These lines pick the five labels the screen shows
(ImageClassificationTask.kt, lines 64 to 72,
wrapped to fit):

val top5 = PriorityQueue(
    compareByDescending<Classification> { it.score })
probs.forEachIndexed { idx, score ->
    if (score.isFinite()) {
        val label = labelList.getOrElse(idx) { "class_$idx" }
        top5.add(Classification(label, score))
        if (top5.size > 5) top5.poll()
    }
}
TaskResult.Success(
    top5.sortedByDescending { it.score }, latency)

Java's PriorityQueue keeps the smallest item, by its comparator, at the head, and compareByDescending makes that
the highest score. poll() removes the head. So each time the queue holds six, it throws away the best score, and the
screen ends up with the five least likely of 1,000 classes. For the quail photo that list is classes 50, 329, 389,
758 and 328, while the real top five for the same input are quail, prairie chicken, partridge, black grouse and
ruffed grouse. The
fix is one word: compareBy instead of
compareByDescending, so the head is the lowest score and poll() drops that one. The test for this screen only
checks that one to five labels come back, so it could not catch this.

Both bugs are still in the repository at commit b8d3e2f (3 July 2026). The fixes are small, and I have left them in
for now: if you want a first pull request, they are yours. To run the app yourself, the
README has the three adb push lines and the install
command.

The rule I took from it

Never retype preprocessing numbers. Either the export script writes the sidecar from the preset's own
preprocessor.json, or the normalization goes inside the exported model, so there is nothing left to keep in sync.
This app keeps the sidecar, because it loads any model that has one next to it.

Which do you use, a sidecar written by code or normalization inside the model? If inside, how do you export it?

Next: the check that would have caught both →

This article was written with the help of AI, from my own repository and the public docs it links.

Two Android ML tests that could never fail, and a TFLite check that can

Rahul Kumar — Thu, 22 Oct 2026 02:16:22 +0000

Two tests in my Android app could never fail. One only counts the labels; the other compares the output with an
answer file that holds no answers. And both of them look at this picture:

The app runs a Keras model exported to LiteRT, the new name of TensorFlow Lite. This post is about one rule: a check
proves something only if you have seen it fail. Here is how mine could not, and the check I would build instead.

Two tests that could not fail

The classification test asks only this of the result
(ClassificationE2ETest.kt, line 66):

assertTrue("Expected top-5 results",
    success.output.size in 1..5)

Any five labels pass, including the five least likely ones the app shows
(part 1
explains why it shows those).

The detection test looks better. It reads a golden file, the saved answer a test compares against, and matches each
expected box by its label and its overlap. Here is the golden file
(detection_golden.json,
its note cut to fit):

{
  "_note": "Golden generation skipped: ...",
  "model": "ssd_mobilenet_v1_detect.tflite",
  "image": "images/test_image.jpg"
}

The note in full reads "Golden generation skipped: No module named 'ai_edge_litert'". No boxes. The match loop runs
once per expected box, so with none it checks nothing, and the size check becomes "at least zero"
(DetectionE2ETest.kt, lines 130 to 131).
The script that should write the answers wrote this placeholder and carried on.

The check that can fail

1. Get the notebook's answer

Start from a real photo with a known answer. KerasHub's own example uses a California quail, and "quail" is class 85
in ImageNet, the label set these classifiers use
(imagenet_utils.py).
Its example downloads the photo with keras.utils.get_file, and on 22 October 2026 Wikimedia answered
403 -- Forbidden. That photo is CC BY-SA 3.0, too, not public domain. So I downloaded a public-domain one from the
U.S. Fish and Wildlife Service,
cropped it square, and loaded it from disk. With my exported preset in the example's place:

image = keras.utils.load_img("california_quail.jpg")
classifier = keras_hub.models.ImageClassifier.from_preset(
    "mobilenet_v3_small_100_imagenet",
    activation="softmax",
)
preds = classifier.predict(np.array([image]))
top_labels = keras_hub.utils.decode_imagenet_predictions(preds)

predict() runs the preset's own preprocessing, so this is the answer the model was built to give. On a computer's
CPU it gave quail 10.30, partridge 3.94, prairie chicken 3.77, black grouse 3.57 and ruffed grouse 3.43. One surprise:
those are raw scores. Despite activation="softmax", the 1,000 scores summed to 162.5 (a softmax would have
summed to 1).

2. Check the .tflite file in Python first

Run the .tflite file on the array the Keras model sees after preprocessing (KerasHub's hint is
model(model.preprocessor(x))), with the interpreter code from the
keras.io guide. Then compare the two outputs the way KerasHub's own export
tests do
(test_case.py):

abs_diff = np.abs(keras_val - litert_val)
mean_abs_diff = np.mean(abs_diff)
max_abs_diff = np.max(abs_diff)

On the quail photo they agreed: max_abs_diff 1.1e-05 and mean_abs_diff 1.9e-06 over the 1,000 scores, with the
same five labels in the same order and quail at 10.31 in both. If the file disagrees with the notebook here, the phone will too, and the bug is
in the export, not the app.

3. Hold the phone to the saved answer

Save the five labels and scores as the golden file, or for detection the boxes as label, score, x1, y1, x2,
y2: the keys my detection test already reads. Push the same photo to the phone and keep the test's matching rule:
the same label, and a box overlap of 0.5 or more, measured as IoU (the area two boxes share divided by the area they
cover together). Two guards make it a test that can fail:

An empty or missing golden file fails. It never counts as a pass.
The same pixels go in. The preset crops the photo to a square before it resizes it, and my app stretches it. Use a square photo, or crop it first.

Here it is failing

I copied my app's preprocessing into Python (resize to 224 by 224, then the preset's numbers) and fed the same file
the same square photo. Quail still came first, at 10.11 instead of 10.31, but prairie chicken and partridge swapped
places. A check that compares the ordered five labels fails right there, with the right numbers in the sidecar: what
is left is the resize step. That is the rule working, on a computer's CPU; I did not run the phone for this post.

What I have not solved

How close is close enough? The resize alone produced that gap, before any quantization (weights stored in fewer
bits to make the file smaller), and I do not yet have a rule for the tolerance. KerasHub's thresholds are set by hand,
per model and per output, and I have not found one to copy. If you have a rule, I would like to read it.

The two tests are still in the repo as they were at commit b8d3e2f (3 July 2026). The scores and differences above come from a run
on 22 October 2026 with keras 3.15.1, keras-hub 0.32.0, litert-torch 0.10.0 and ai-edge-litert 2.3.0.

Next: five ways the export itself breaks, each with its public record →

This article was written with the help of AI, from my own repository and the public docs it links.

Why a Keras model fails to convert to TFLite: 11 known cases, 5 traps

Rahul Kumar — Thu, 22 Oct 2026 02:15:45 +0000

KerasHub, the Keras library of pretrained models, expects 11 of its own models to fail the export to LiteRT (the new
name of TensorFlow Lite), and its tests say why in one line each. Here are all 11, the five traps they fall into, and
what to write instead.

I contribute to Keras and KerasHub. The change that switched these export tests back on for the PyTorch backend,
keras-hub#2698, is mine.

The 11, in KerasHub's own words

An expected failure is a test marked to fail until an upstream fix lands; when the fix lands, the test turns loud
instead of silently passing. Each name links to its line in the tests:

Model	Trap	The test's own reason
D-Fine	2. One shape	"D-FINE's multi-scale features hit a torch.export shape guard."
Flux	2. One shape	"torch.export guard from Flux's dynamic num_heads reshape."
F-Net	3. No lowering	"litert-torch has no lowering for aten.complex (from ops.fft2)."
GPT-OSS	3. No lowering	"litert-torch NHWC rewriter has no lowering for aten.amax."
Mixtral	3. No lowering	"litert-torch cannot lower aten._assert_async from MoE routing."
Qwen3-MoE	3. No lowering	"litert-torch cannot lower aten._assert_async from MoE routing."
Qwen-MoE	3. No lowering	"litert-torch cannot lower aten._assert_async from MoE routing."
SAM3	3. No lowering	"torchvision::nms is not registered in the torch.export op set."
SegFormer	3. No lowering	"Unsupported ops during SegFormer's torch export decomposition."
StableDiffusion3	3. No lowering	"AdjustablePositionEmbedding cannot be lowered by torch.export."
VAE	3. No lowering	"VAE's pow ops fail TFLite legalization (tfl.pow)."

At the commit that merged it, KerasHub has 75 export tests in 67 model folders: 63 carry no mark, 11 are expected
failures and 1 is skipped. I counted the marks in the code; I did not run the tests. The pull request names 7 models
that now pass on PyTorch: VGG, Moonshine, SAM, GPTNeoX and BASNet, plus ViTDet and Whisper within a tolerance rather
than an exact match.

1. "symbolic tf.Tensor used as a Python bool"

Export turns your Python into a graph. A Python if on a tensor, or a size read with x.shape, can break that step
or freeze one case into the graph. KerasHub still skips its DeepLabV3 export test with exactly this message
(test).

Fix: keep sizes and branches inside the graph. One merged change, before and after
(keras-hub#2466):

# Before: x.shape is read once, while the graph is built
t = ops.arange(x.shape[position], dtype=x.dtype)

# After: "for dynamic shape compatibility with TFLite"
t = ops.arange(ops.shape(x)[position], dtype=x.dtype)

For a Python if, keras-hub#2467 removed the branch instead: it
builds the tensor so that one token gives an empty tensor, "avoiding the need for a Python conditional".

2. A `torch.export` shape guard

On the PyTorch backend the input shape is fixed when you export. In my words from
keras#22996, the issue I filed:

The only viable workaround is to export with a fixed static shape matching the runtime maximum.

D-Fine and Flux are this trap in the table.

Fix: give the export one shape, the largest you will feed it:

# Fails (keras#22996, shortened): the sequence length is left
# open, traced at 1, and the file breaks on longer input.
lm = keras_hub.models.Gemma3CausalLM.from_preset(
    "gemma3_270m_it")
lm.export("lm.tflite", format="litert")

# Works: one fixed shape at export (an image model here).
m.export("m.tflite", format="litert",
         input_signature=[torch.randn(1, 224, 224, 3)])

The working half ran on 22 October 2026, on a computer's CPU, for my demo app's MobileNetV3.

To feed a different batch size later, resize the input at run time with resize_tensor_input(), as the
keras.io guide shows.

3. "no lowering for aten.complex"

The export stops at the name of one operation. Lowering is the step that turns each PyTorch operation into a LiteRT
one, and litert-torch, the converter, has no rule for some of them. Seven of the 11 in the table name such an
operation (aten.complex, aten.amax, aten._assert_async, torchvision::nms, tfl.pow); SegFormer and StableDiffusion3 give
a vaguer reason.

Check, then a fallback with a cost: find your model in the table before you start. The keras.io guide's fallback
is the TensorFlow backend, but its flex ops, TensorFlow operations carried into the file, "are not supported by the
new LiteRT Android runtime". The app then needs the legacy runtime, org.tensorflow:tensorflow-lite, plus
tensorflow-lite-select-tf-ops.

4. Inputs named `args_0`

Your app asks for an input by name, and the file calls it args_0. litert-torch flattened dict inputs to generic names
(litert-torch#1022, closed 4 June 2026).

Fix: use litert-torch newer than 0.9.1, which keeps the original keys
(keras#23053), and print the names before you write app code. For
my MobileNetV3 file, with litert-torch 0.10.0, it printed this:

print("Signatures:", interpreter.get_signature_list())
# {'serving_default': {'inputs': ['args_0'],
#                      'outputs': ['output_0']}}

A single image input is still called args_0; the fix keeps the keys of dict inputs.

5. `tf.lite` is deprecated, and the toolchain moves

KerasHub switched all its export tests off in February 2026, when TensorFlow 2.20 deprecated tf.lite
(keras-hub#2573), and back on in July for PyTorch only, with
Keras 3.15 or newer. Keras 3 with TensorFlow 2.20 and Python 3.13 crashed during export until
keras#22816.

It moved again on 22 October 2026. Installed from the main branches, the way the keras.io guide does it, the export
above failed in the converter with 'tfl.batch_matmul' op found invalid output rank, expected 3 but got 4. The
released versions of the day before exported it: keras 3.15.1, keras-hub 0.32.0, litert-torch 0.10.0 and
ai-edge-litert 2.3.0.

Check, not a fix: record the versions that worked, next to the exported file:

pip freeze | grep -iE "keras|litert" > export-versions.txt

The one I cannot close

KerasHub's DeepLabV3 export test is still skipped, while my demo app exports a DeepLabV3 preset on the same PyTorch
backend. One of the two is out of date; my 22 October run covered MobileNetV3 only. If you have run that export recently, which one is it? And which trap did you
hit that is not on this list?

New here? Start with part 1: one model on a phone →

This article was written with the help of AI, from my own repository and the public records it links.

A hot-expert cache made a 181 GiB model faster on one 96 GiB GPU

Rahul Kumar — Wed, 21 Oct 2026 19:22:03 +0000

The build of GLM-5.3-Flash I run is 181 GiB, and my GPU has 96 GiB. It still writes up to 16.5 tokens a second on one desktop. Offloading more on its own made it slower; keeping each layer's hot experts on the card made it faster.

One of the eight bugs on the way gave no error at all. The model just emitted the same token, forever. I will come back to that one.

Each bar is its own measured setup. Source: the README at commit 865edb6; 16.50 is dated 2026-09-01.

What you get

A model bigger than the card at about 15 tokens a second, output unchanged.
Three changes that made writing 1.5x faster and prompt reading 2.9x faster, and the ideas that failed.

The numbers, with their conditions

One RTX PRO 6000 Blackwell card, one request at a time.

Writing (decode), peak: 16.50 tokens a second over 8 back-to-back 200-token answers to short prompts, with 66 hot experts per layer on the card.
Writing, as shipped: 14.99 tokens a second with 54 hot experts per layer, leaving room for long prompts.
Reading a prompt: 1,771 and 1,729 tokens a second on two fresh prompts of about 10,300 tokens (5.82 s and 5.96 s to the first token).
Longest prompt: 304,800 tokens in 205 s, 93% of the 327,680 configured.
Output: unchanged; on the prompt path, log-probabilities stay within the baseline's own run-to-run spread over 13,519 tokens.

Prompts are streamed and fresh, so no cache helps. The setups differ in more than one setting (context length, hot experts). The peak ran on 2026-09-01, the rest on 2026-09-02 (prompt runs logged in artifacts/prefill-fresh-2026-09-02.txt).

How it got faster

The wall: one PCIe transfer per token

It is an NVFP4 build of GLM-5.3-Flash, so its weights are 4-bit numbers. 90% of it is "experts": each layer has 288, and a router picks 8 per token. In the first setup, 105 GiB of experts lived in host RAM, and the GPU fetched the ones each token needed over PCIe, the link to the rest of the machine. That version wrote 10.77 tokens a second, and nearly all its time went to that one transfer.

Measured on this machine before vLLM PR #53906 merged on 2026-09-03; the card's memory is the vendor figure. Data: the README at commit 865edb6.

A gather kernel that reads wide

The link was not the problem; the way it was read was. The default gather (index_select) used narrow, scattered loads. A small Triton kernel that reads wide blocks roughly doubled the rate, to 52.1 GB/s, 92% of the link. Its list of experts stays on the GPU, so the CPU never stops to read it, and CUDA graphs could come back: replaying a recorded step added 13%, for 13.53 tokens a second.

Offload more, cache the hot experts

vLLM decides what stays on the card one whole layer at a time, in module order, so the experts left in VRAM were arbitrary. Summed across all layers, my routing counts looked flat and capped any cache at about 1.15x, so I closed caching as a dead end. One groupby by layer reopened it.

The same routing data, counted two ways, measured before vLLM PR #53906 merged on 2026-09-03. Data: the repository's assets/routing-skew.svg at commit 865edb6.

In each layer, the hottest 35% of the experts take 74% of the picks. So I offloaded more, 125 GiB instead of 105, and spent the freed VRAM on a cache of each layer's 66 most-used experts: 16.50 tokens a second. The same offload without the cache gave 11.34, slower than the 13.53 before it. The two only work as a pair.

Prefill in groups of 64 experts

A long prompt (prefill) routes to nearly every expert, which overflowed the 64-expert staging buffer and fell back to slow reads at about 23 GB/s. Walking the experts in groups of 64 took prompt reading from 614 to about 1,750 tokens a second.

Fresh prompts, streamed. Source: the README at commit 865edb6; the grouped runs are logged in artifacts/prefill-fresh-2026-09-02.txt (2026-09-02).

Grouping costs short prompts (a 14-token prompt waited 2.05 s for its first token instead of 0.85 s), so it switches on only at 48 tokens or more.

What did not work, with the numbers

A recency (LRU) cache: 9.0% hits against 5.6% at random.
Experts on the CPU: 0.895x, slower; host RAM is only 1.15x the link.
Re-profiling on sampled traffic: 13.02 against 15.77 on prose; sampling flattens the skew.
6 of the 8 experts per token: 20.48 tokens a second, 24% faster, but the output looped ("Jupiter (planet) (planet) (planet)"). It stays off.

The bug with no error

Nothing crashed or logged an error; the model emitted the same token forever. vLLM can run the expert math with several kernels, and on this card two that compute in 4-bit directly return wrong numbers silently. Marlin, which unpacks the weights first and warns that the GPU lacks native FP4, is the one that works, and the fastest. Take this one line:

--kernel-config '{"moe_backend":"marlin"}'

Try it (it is not turnkey)

You need an RTX PRO 6000 Blackwell card (96 GiB), vLLM with GLM-5.3-Flash support from pull request #53906, the repository's patch, and host RAM for the offloaded experts. Of the 181.3 GiB checkpoint, 163.3 GiB is experts; 125 GiB of them sit in RAM (the test machine has 182 GiB), and the rest stays on the card. The tests ran on a pre-release build, and the setup was not re-run on vLLM 0.30.0 or later. Boot takes 5 to 6 minutes. Without the card, you can still reuse the ideas.

To start reading:

git clone https://github.com/pctablet505/glm53-flash-single-gpu
cd glm53-flash-single-gpu
less RUNNING-GLM53-ON-ONE-GPU.md   # the build and the eight bugs, in order
less config/serve-opt.sh           # the shipped settings, each with its reason

Limits

One machine, one checkpoint and one pre-release vLLM build with local patches.
Most numbers are single runs, with about ±1 token a second of spread.
Without changing the output, this hardware tops out near 16 to 17 tokens a second.
If a model that fits in 96 GiB will do, use it: Qwen3.8-Flash-Next (78.5 GiB) runs at 173 tokens a second here.

Still open: a masked variant of grouped prefill, which skips experts the prompt does not use, reached the first token in 0.36 s on the 14-token prompt, against 0.85 s for what ships. Its correctness was never properly tested. Have you tried masked staging for prefill?

Where next

RUNNING: start here: the build and all eight bugs.
OPTIMIZING: the cost model behind these numbers, and the settings that do nothing.
LAB-NOTEBOOK: the same work day by day, mistakes included.
servedeck: the small control plane I use to start, stop and switch the models on this workstation, with an OpenAI-compatible endpoint in front.

I am pctablet505 on GitHub. I measure what actually happens and leave the failures in; the repositories above are where the rest of it lives.

This article was written with the help of AI, from my own measurements; the logs are in the repository.

Keras #22561 speedups: compiled Keras on PyTorch now generates text 11.6x faster

Rahul Kumar — Fri, 16 Oct 2026 16:29:52 +0000

Between master on Jul 18 and master on Oct 15, 2026, 15 of our PRs landed in Keras. Same GPU, same torch and jax versions, same models; only the Keras source changes. On the issue's test LM, compiled Keras[torch] now generates text 11.6× faster, torch.compile went from slowing Keras down to making it 6.56× faster than eager Keras, and an LLM forward makes 12–23% fewer Python calls on all four backends.

Here is compiled generation at every merge. Pick a config or a workload, and hover a point to see its runs:

Generate-32 throughput, July master vs today

Tokens per second from the 2.1M-parameter test LM, 128 tokens per call (4 sequences × 32 steps); longer bars are faster. In July, compiling a Keras[torch] model made it slower: 1,458 tok/s compiled against 2,139 eager. Today the compiled model runs at 16,975 tok/s: 6.56× faster than eager Keras, within 1.53× of plain compiled PyTorch, down from 17.8×.

Three merges that made torch.compile work with Keras

Three merges each turned one compiled workload from slow to fast in a single step.

The three PRs: #23327 (attention), #23201 (dict ordering in the tree code) and #23647 (identity checks in the tree code). Graph breaks per forward pass, at every merge:

Less Python in every Keras call, on all four backends

Most of the series changed shared code (Layer.call, op tracebacks, dtype handling, input checks), so the saving reaches every backend, not just torch. Python function calls per forward pass, July to today: PyTorch −23% on the LM and −33% on the CNN; JAX −12% on the LM and −17% on the CNN; TensorFlow −13% on the LM and −19% on the CNN; NumPy −16% on the LM and −18% on the CNN. Adding #23336 takes NumPy to −36% on the LM. These counts are exact and repeat call for call on any machine.

Keras[jax]

Under jax.jit the Python runs once at trace time, so Keras[jax] was already close to plain JAX and stays there: 2.30 → 2.45 ms per generate-32 against 2.22 ms for plain JAX. Eager Keras[jax] is where the saving shows in the exact counts: −12% Python calls per forward. The timing agrees: the sweep gives 293 → 267 ms (1.10×) and the back-to-back A/B rounds give 1.08×.

Every config, every workload

Show all 12 configs and workloads (ms per call)

Keras config	Workload	Plain framework (ms)	Jul 18 (ms)	Oct 15 (ms)	Change	+ #23336 (ms)	A/B check
Keras[torch] · eager	CNN forward	0.064	0.668	0.477	1.40×	0.466	1.39×
Keras[torch] · eager	LLM forward	0.189	1.88	1.55	1.22×	1.48	1.20×
Keras[torch] · eager	LLM generate-32	5.85	59.8	49.5	1.21×	47.2	1.20×
Keras[torch] · torch.compile	CNN forward	0.076	1.28	0.160	8.03×	0.161	8.41×
Keras[torch] · torch.compile	LLM forward	0.160	2.69	0.302	8.93×	0.299	9.60×
Keras[torch] · torch.compile	LLM generate-32	4.92	87.8	7.54	11.6×	7.66	12.4×
Keras[jax] · eager	CNN forward	0.508	1.34	1.23	1.08×	1.18	1.15×
Keras[jax] · eager	LLM forward	2.79	8.46	8.38	1.01×	7.90	1.12×
Keras[jax] · eager	LLM generate-32	89.0	293	267	1.10×	269	1.08×
Keras[jax] · jax.jit	CNN forward	0.077	0.079	0.081	0.97×	0.080	1.02×
Keras[jax] · jax.jit	LLM forward	0.120	0.131	0.135	0.97×	0.130	1.05×
Keras[jax] · jax.jit	LLM generate-32	2.22	2.30	2.45	0.94×	2.27	1.05×

A/B check: July ÷ today from 3 separate back-to-back rounds (higher is a bigger speedup).

Each of our PRs, measured where it landed

Each PR was timed on the commit just before and just after it merged, so every row is that one PR's own effect. Δ is just after the merge minus just before it; negative is better.

Show the per-PR table

PR	Merged	What it changed	Δ calls/fwd torch	JAX	TF	NumPy	Δ eager gen-32 (ms)	Δ compiled gen-32 (ms)	Graph breaks
#23183	07-28	Traceback details are built only when an op fails, not on every call	−598	−586	−622	−546	−2.9	−5.2	·
#23327	08-30	Removed the torch.compile graph break in the torch backend's dot_product_attention	+6	0	0	0	+0.40	−12.3	LLM 11 → 0
#23189	09-03	Fixed an always-true device check that sent every tensor through .to()	0	+38	0	0	+0.28	−1.1	·
#23200	09-05	Layer.call stops re-setting built/_called on every call	−1,848	−1,098	−1,188	−1,100	−4.9	−10.5	·
#23182	09-10	O(1) dtype membership and a fast path for canonical dtype strings	−300	−82	−497	−116	−0.89	−1.5	·
#23199	09-10	Dropped a redundant channels_last copy on torch conv inputs	0	−50	0	0	+0.40	−0.29	·
#23201	09-11	Torch tree code made traceable: canonical dict key order	−142	+8	0	0	+0.55	−5.2	CNN 9 → 0
#23296	09-11	Keeps call-context kwargs on the recorded Node (fix)	−109	−78	−14	−46	−0.24	−0.09	·
#23187	09-12	TorchTrainer skips a full flatten walk to find the batch size	0	−26	0	0	+0.14	−0.21	·
#23301	09-12	Layer name scope opened once per call, not twice	−330	−568	−638	−330	−0.89	−0.21	·
#23190	09-15	torch slice() keeps dynamic dims under torch.export	0	−16	0	0	−0.23	−0.16	·
#23647	09-30	Torch tree code stops comparing id()s	0	−8	0	0	−0.58	−49.4	·
#23645	10-07	torch pooling ops run in channels_last	0	−16	0	0	+0.10	−0.05	·
#23184	10-13	Fast path for single-InputSpec input checks	−102	−59	−63	−63	+0.06	+0.05	·
#23920	10-15	Functional models reject a mismatched last axis (fix)	0	−54	0	0	+0.10	+0.02	·
#23336	not merged yet (approved)	Memoized dtype promotion in result_type	−713	−378	−1,471	−3,399	−2.2	+0.12	·

Hot functions in one Keras[torch] LLM forward

Show the hot-functions table

Function	Jul 18	Oct 15	Change	+ #23336
isinstance	2,600	1,740	−33%	1,680
traceback error wrappers	74	48	−35%	48
thread-local config lookups	624	513	−18%	513
standardize_dtype	177	244	+38%	184
tree.flatten	93	67	−28%	67
tree.map_structure	102	62	−39%	62
InputSpec checks	14	14	+0%	14
CallSpec objects built	23	23	+0%	23
inspect.Signature.bind	22	22	+0%	22
convert_to_tensor	86	86	+0%	86
get_device	138	138	+0%	138

How this was measured

Machine: one NVIDIA RTX PRO 6000 Blackwell, kept idle during the runs.
Software: the same for every run: torch 2.13.0, jax 0.11.2, Python 3.14.7. Only the Keras source changes.
Commits: 31 snapshots of master: Jul 18 (a2f8eac8), just before and just after each of the 15 merges, Oct 15 (cc9de2b31), and Oct 15 plus #23336.
Models: the issue's two test models: a small CNN (114k parameters) and a 2-layer transformer LM (2.1M parameters, 32-token greedy generate).
Timing: the issue's benchmark script, one process at a time, warm-up first, a GPU sync after every call. Each number is a median, and the whole sweep ran three times for PyTorch and twice for JAX.
Cross-check: a separate back-to-back run of July against October gives 12.4× compiled and 1.20× eager (the sweep: 11.6× and 1.21×).
Counts: Python calls from cProfile, graph breaks from torch._dynamo.explain. These are exact and repeat on any machine.
Not covered: training, CPU, larger models, and TensorFlow or NumPy timing (call counts only).

The work is tracked in issue #22561. Thank you to the Keras maintainers who reviewed and merged these PRs.

Why two out of three open-source projects don't get a Porchlamp score

Rahul Kumar — Fri, 16 Oct 2026 00:15:14 +0000

TL;DR: Of 11,000 open-source projects, only about 1 in 3 gets a score. The rest aren't hidden: each one is listed with a plain reason, like "no recent activity" or "most outside pull requests go unanswered".

In Porchlamp's October 2026 snapshot, 3,833 of 11,000 GitHub projects received a score; the other 7,167 are listed with the reason they were not ranked.

How are open-source projects ranked fairly?

A ranking is only useful if every project in it is a real choice for a contributor. A project that's archived, has no license, or hasn't had a commit in months isn't one, however good its numbers look.

So before scoring, every project goes through a few simple checks. Fail one, and the project is listed with the reason instead of a rank.

The checks, in plain words

Is it software? Docs-only repos, awesome lists and data dumps are left out. (1,067 projects)
Is it still a real project? Archived repos, mirrors and most forks are left out. (624)
Does it have an open-source license? Without one, you can't safely contribute. (491)
Is anyone still working on it? No human commits in six months means it's stale. This is the biggest group. (2,475)
Does anyone answer outside PRs? If most pull requests from outsiders get no human response within two weeks, it's a black hole. (1,133)

Then there's a last group: projects that pass every check, but where too little could be measured to score them fairly. They're listed as unrated (1,377).

That leaves 3,833 ranked projects.

The black-hole check is careful on purpose

Calling a project a black hole is a strong statement, so the check leans towards giving projects the benefit of the doubt:

It needs at least ten outside PRs. With fewer, there's no verdict.
PRs younger than two weeks don't count yet.
Bots, drafts, maintainers' own PRs and brand-new accounts are ignored.
The rule only fires when the data clearly says "most go unanswered", not on a borderline case.

Undecided isn't failed

Some projects do their reviews somewhere else, on Gerrit or a mailing list, and their GitHub PRs only point there. Porchlamp spots those and leaves them undecided rather than calling them silent. Eight projects are handled that way.

See the reasons yourself

The Not ranked list on Porchlamp shows every project that didn't get a score, with its reason. If you think a check treats a project unfairly, open an issue and say why.

Which of these checks would you loosen, and which would you make stricter?

Where to send your first open-source pull request (the projects that actually answer)

Rahul Kumar — Thu, 15 Oct 2026 23:52:12 +0000

TL;DR: For a first contribution, the projects worth your time are the ones where humans answer outside pull requests and first changes are easy to make. Right now the list starts with llama.cpp, Meshery, open-design, stdlib and Ant Design.

In Porchlamp's October 2026 snapshot of 11,000 GitHub projects, the first-contribution ranking scores projects mostly on two things: how quickly humans respond to outside pull requests (35% of the score) and how easy a first change is (30%).

Which open-source projects are good for a first contribution?

The usual advice for a first open-source contribution is to pick something popular. But popular projects are often the slowest to answer a stranger. Your first PR can sit for weeks with no reply, and that's usually where people give up.

So I built a ranking that asks a different question: if you're new, where will your pull request actually get seen?

What it looks at

Two things carry most of the weight:

Responsiveness (35%): how fast a human answers outside PRs, and how many of those PRs get a decision.
Accessibility (30%): good first issues that are actually open, and whether first-time contributors get merged and come back.

The rest is governance (15%), how much other software depends on the project (10%), and review and CI practices (10%).

The best projects for a first contribution right now

llama.cpp
Meshery
open-design
stdlib
Ant Design
Organic Maps
Apache Maka
Cluster API
freeCodeCamp

A few of these jump up a lot compared with the default ranking. open-design climbs 63 places and stdlib 49. That means their strengths are exactly the things a newcomer needs.

Two labels you'll see

"B (capped)": not a bad grade. It means only part of the project's data could be measured, so the tier can't go higher yet.
The Δ rank column: how far a project moves between the default ranking and this one. It isn't movement over time.

How to use it

Open the Porchlamp first-contribution rankings.
Pick two or three projects in a language you know.
Open each one's pull requests on GitHub and read a few recent ones from outside contributors. Do they get answers?
Then find a good first issue and start small.

A high rank isn't a promise about your particular PR, but it's a much better bet than stars.

If a row looks wrong to you, an issue on the repository with the pull requests that show it is the most useful thing you can send.

Which project gave you your first merged PR, and how long did it take?

Which ecosystems leave your pull request hanging? npm and PyPI more than Rust, Go or Java

Rahul Kumar — Thu, 15 Oct 2026 22:56:51 +0000

TL;DR: If you send a pull request to an npm or PyPI project, you're more likely to hear nothing back than with a Rust, Go or Java one. About 3 in 10 active npm and PyPI projects leave most outside PRs unanswered for two weeks, against about 1 in 5 for crates.io.

In Porchlamp's October 2026 snapshot, 33.8% of active PyPI projects and 30.0% of active npm projects left most outside pull requests unanswered for two weeks, compared with 20.0% of crates.io projects.

Does the ecosystem matter?

To find out, I split my data on outside pull requests by package ecosystem.

A quick definition first. I call a project a black hole when most pull requests from outside contributors get no human reply, review or merge within two weeks. Only active, licensed projects with at least ten outside PRs are judged.

Which ecosystems answer outside pull requests?

Ecosystem	Projects judged	Black holes
PyPI	968	33.8%
npm	1,283	30.0%
Go	609	22.2%
Systems (C, C++ and others)	573	20.1%
crates.io	586	20.0%
Maven	278	19.4%

Two groups stand out:

npm and PyPI: roughly 3 in 10 projects go quiet on outsiders.
Rust, Go, Java and systems projects: closer to 1 in 5.

Rust isn't alone at the good end. Maven is a touch better, and systems projects are level with it.

What I wouldn't read into it

It's not about community character. These are averages over very different projects.
Size isn't controlled for. Bigger projects go silent more often in general, so an ecosystem with more big projects looks worse for that reason alone.
Off-GitHub review isn't counted. Projects that review on Gerrit or a mailing list aren't judged, and they may cluster in some ecosystems.

So if you're picking where to send your first PR, this is a mild nudge, not a guarantee about any single project.

Check the project, not just the ecosystem

The full ranking is on Porchlamp. Here is the Porchlamp ranking of crates.io projects; switch the filter to see any other ecosystem. Every black-hole verdict lists the pull requests behind it. If a project looks misjudged, open an issue with the evidence.

Would you expect the Rust number to hold up once project size is taken into account?

I measured silence: 212,390 outside pull requests across 11,000 GitHub projects

Rahul Kumar — Thu, 15 Oct 2026 22:03:24 +0000

TL;DR: More than 1 in 4 active open-source projects leave most pull requests from outside contributors with no human response for two weeks. The more stars a project has, the more likely it is to be one of them.

In Porchlamp's October 2026 snapshot of 11,000 GitHub projects, 1,133 of the 4,297 active projects (26.4%) left most outside pull requests with no human reply, review or merge within 14 days.

Why I looked

One of my pull requests once sat for four months before anyone merged it. Around the same time, a different project merged five of mine in a single day.

Same person, same kind of code. The only difference was the project. And nothing on a GitHub page tells you which kind you're about to deal with. Stars tell you a project is popular. They don't tell you if anyone will read your PR.

What I measured

I followed six months of pull requests from outside contributors to 11,000 GitHub projects: 212,390 PRs from 110,605 people.

For every PR the question was simple: did a human respond within two weeks? A reply, a review or a merge all count. A bot comment doesn't.

To keep it fair I left out bots, maintainers' own PRs, drafts, PRs the author closed themselves, and brand-new accounts.

Do popular open-source projects answer pull requests?

1. Silence is common. Of the 4,297 active, licensed projects with at least ten outside PRs, 1,133 left most of them unanswered for two weeks. I call these black holes.

2. More stars, more silence.

About 1 in 5 projects with 1k to 10k stars is a black hole. Above 50k stars it's closer to 2 in 5.

3. Popular isn't the same as welcoming. Of the 100 most-starred projects, just 9 reach the top 100 of the default Porchlamp ranking.

What this doesn't mean

It's not a verdict on maintainers. Big projects get far more PRs than anyone can review.
It only sees GitHub. Projects that review on a mailing list or Gerrit aren't judged at all.
It's a snapshot (April to October 2026), so it will drift.

Check a project before you give it a weekend

I turned all of this into a free site, the Porchlamp rankings. It ranks open-source projects by what happens to a stranger's pull request, and you can re-rank it for your goal: a first contribution, career value, deep systems work, or AI-assisted work.

👉 See the Porchlamp rankings of 11,000 open-source projects

Looking for your first project? Here's where to send your first open-source pull request.

Every black-hole verdict links to the pull requests behind it, so you can check the evidence yourself.

What's the longest one of your PRs has ever waited?

DEV Community: Rahul Kumar

In most open source projects we measured, one person gives most of the first answers

In 1,175 of 2,843 projects, one person gives 90% or more of the first answers

More first pull requests get merged where one person does the answering

Authors who asked got about 9 percentage points more answers. A comment with no ask and no tag got none.

After two weeks of silence, the odds of a merge have more than halved

The first pull request waits longest

Weekend pull requests wait longer

Ten projects that answer first-timers quickly and merge their work

How this was measured

Not covered

30 open source projects to contribute to that actually answer your pull request

How to use this list

Rust

Python

JavaScript

Go

Java

C and C++

What normal looks like

Check your own project

How to tell if an open-source project will answer your pull request

The check

What normal looks like

The fast end

A high star count is no guarantee

Skip the counting

Keras to TFLite on Android: wrong normalization and a backwards top-5

The export: one call

Bug 1: the pixel numbers

Bug 2: the top-5 list

The rule I took from it

Two Android ML tests that could never fail, and a TFLite check that can

Two tests that could not fail

The check that can fail

1. Get the notebook's answer

2. Check the .tflite file in Python first

3. Hold the phone to the saved answer

Here it is failing

What I have not solved

Why a Keras model fails to convert to TFLite: 11 known cases, 5 traps

The 11, in KerasHub's own words

1. "symbolic tf.Tensor used as a Python bool"

2. A torch.export shape guard

3. "no lowering for aten.complex"

4. Inputs named args_0

5. tf.lite is deprecated, and the toolchain moves

The one I cannot close

A hot-expert cache made a 181 GiB model faster on one 96 GiB GPU

What you get

The numbers, with their conditions

How it got faster

The wall: one PCIe transfer per token

A gather kernel that reads wide

Offload more, cache the hot experts

Prefill in groups of 64 experts

The bug with no error

Try it (it is not turnkey)

Limits

Where next

Keras #22561 speedups: compiled Keras on PyTorch now generates text 11.6x faster

Generate-32 throughput, July master vs today

Three merges that made torch.compile work with Keras

Less Python in every Keras call, on all four backends

Keras[jax]

Every config, every workload

Each of our PRs, measured where it landed

Hot functions in one Keras[torch] LLM forward

How this was measured

Why two out of three open-source projects don't get a Porchlamp score

How are open-source projects ranked fairly?

The checks, in plain words

The black-hole check is careful on purpose

Undecided isn't failed

See the reasons yourself

Where to send your first open-source pull request (the projects that actually answer)

Which open-source projects are good for a first contribution?

What it looks at

The best projects for a first contribution right now

Two labels you'll see

2. A `torch.export` shape guard

4. Inputs named `args_0`

5. `tf.lite` is deprecated, and the toolchain moves