Delays with extension reviews

Developers Developer Announcements
1

We’d like to let you know that we are aware of delays with getting extension reviews done and we apologise for any delays you are experiencing.

There are a few things going on that are causing this:

  • We’re trying to bring more automation to our extension review process but this has had a few teething problems and we are still working through these. Over the medium term we are hoping to make early-process triage all automated so you can get any fail results straight away with good enough feedback to fix identified issues.
  • We have been seeing a big increase in submissions, which is great but which has taken us a bit by surprise.
  • The increase in submissions is coming with a higher degree of variance in quality. If you are heavily relying on AI to create your extensions, please make sure that you are still offering something useful and original. Please use our review guidelines to help the extension arrive in a state more likely to be approved.

To help us process extension submissions we will be prioritising the following:

  1. Reviews for submissions from vendors for paid extensions are being given highest priority
  2. Reviews for submissions from subscribers are being given the next level of priority
  3. Reviews for submissions which are updates to existing popular extensions are given the next level of priority.

Obviously we want to be able to promptly provide feedback quickly on all extension submissions and this is where we are aiming to be. We are really excited to see a lot of interest in submitting proposals - just be sure to review the criteria before submitting to help us limit delays.

Thanks - Extensibility team

(Resources)
Requirements:
https://ruby.sketchup.com/file.extension_requirements.html
Best security practices:
https://developer.sketchup.com/article-security-best-practises

2

Hi Andrew @corney,

Thank you for the explanation, I can imagine you have full hands of vibe coded extensions to review :slight_smile:

How about if you put Claude Mythos to work? I’m sure Trimble is big enough to get access to it.

And then we can also see if it’s a real deal or a marketing hype :smiling_face_with_sunglasses:

Cheers
Jernej

3

I wish! No mythos here yet unfortunately Jernej.

Thanks for understanding!

4

To: Andrew @corney, @thomthom, @eneroth3, @jiminybillybob, @Matheron

TL;DR

I’d like to propose two complementary tools that move first-pass validation out of your queue and into developers’ local workflows — before the Submit button is ever pressed. Both are designed to be community-built, open-source, and low-maintenance for your team.

Context: How Other Ecosystems Handle This

You’re not alone in this challenge. Every major extension/plugin marketplace has wrestled with the same surge-quality-security trilemma:

  • VS Code Marketplace (Microsoft): Runs automated malware scans on every submission and recently added secret scanning in their vsce CLI tool so developers catch credential leaks before upload. They also introduced a Trusted Publisher badge system to fast-track trusted vendors — directly analogous to your paid/subscriber prioritization.

  • Open VSX Registry (Eclipse Foundation): Just rolled out mandatory pre-publication security checks in early 2026 — scanning for namespace impersonation, accidental secrets, and known malicious patterns. Suspicious submissions are quarantined for manual review rather than blocked entirely. Their key insight: shift from reactive to proactive.

  • npm: The publish-please / npm audit ecosystem lets developers dry-run a publish and catch vulnerabilities, uncommitted changes, version mismatches, and sensitive files before anything reaches the registry. The prepublish hook enforces this automatically.

  • GitHub Marketplace Actions: Enforces automatic version-tag-to-manifest matching as a publish prerequisite. No mismatch, no publish. Simple, zero-review-team overhead.

The pattern is consistent: the most effective triage is the triage developers do themselves, when given good tooling and fast feedback loops.

Proposal 1 — ew-preflight: A Local Pre-Submit CLI

A command-line tool (Ruby gem) that developers run before packaging their .rbz. It wraps existing tools and adds EW-specific checks.

Tier 1 — Instant checks (< 5 seconds)

These run on every invocation and catch the most common rejection reasons:

Check What it catches
rubocop-sketchup --only SketchupRequirements Namespace pollution, exit!, $LOAD_PATH modification, Gem.install, missing SketchupExtension registration, SketchupRequire with file extension
RBZ structure validation Single root .rb + matching subfolder; root file only registers, doesn’t load
Version consistency check SketchupExtension.new version string vs. EW submission metadata — catches the 1.3.2/1.4.6 class of mismatch your team flagged
Metadata completeness Extension name uniqueness within local namespace; description non-empty; support URL present
Binary / compiled file detection Flags .so, .bundle, .dll files and prompts developer to confirm they have trusted-vendor status
Secret scanning Regex sweep for API keys, tokens, passwords in source (mirrors what VS Code’s vsce now does)

Tier 2 — Deep scan (opt-in, --deep flag, ~30–60 seconds)

Runs an LLM-assisted review against an EW-specific system prompt. Think of it as a local CodeRabbit for SketchUp extensions:

  • Checks for AI-generated “slop” patterns: generic boilerplate, lack of SketchUp API usage, copy-paste from tutorials
  • Flags use of undocumented SketchUp APIs
  • Detects obfuscated code blocks that would trigger your security concern about compiled/encrypted submissions
  • Reviews observer callbacks for missing start_operation with transparent flag
  • Can run locally via Ollama (no cloud dependency) or OpenAI-compatible endpoint

Output example

$ ew-preflight build/my_extension.rbz

EW Preflight v1.0 — AgiliCity
================================
✅  RBZ structure valid
✅  Single root .rb loader
✅  SketchupExtension registered (load-default: true)
✅  No global namespace pollution detected
⚠️  VERSION MISMATCH — loader: 2.1.0 / EW metadata: 2.0.9
❌  SketchupRequire: remove .rb extension on line 14 of main.rb
❌  Binary detected: libs/x64/my_solver.so — confirm trusted-vendor status
ℹ️  Run with --deep for AI-assisted quality review

2 errors, 1 warning. Fix errors before submitting.

Distribution

  • Ruby gem: gem install ew-preflight
  • GitHub Action: uses: sketchup-community/ew-preflight@v1 — runs on every push/tag
  • Works offline; no EW account required

Proposal 2 — Open a Subset of ew-review to the Community

We understand your internal ew-review tool is the gold standard, and we’re not asking for full access. A more modest ask:

Publish a read-only “developer preview” mode — a subset of your review checklist as a structured JSON/YAML spec that community tools (including ew-preflight) can consume.

Specifically:

  1. A machine-readable list of auto-rejection rules — the things that are always a hard NO, expressed as a schema developers can validate against locally. Version mismatch format, binary restrictions, namespace requirements, etc.

  2. A versioned “what changed” log — when rules change (like the current version-string policy), developers get notified via gem update rather than finding out after a 3-week queue wait.

  3. Optional: a sandboxed API endpoint — POST /ew-review/preflight that accepts an .rbz and returns the Tier 1 results your automated pipeline already produces, without entering the human-review queue. This is essentially what you described as “AI review on submission with feedback visible within a few minutes” — we’d just make it callable by developers before submission too.

This is the model the Open VSX Registry is moving toward, and it has the significant advantage that you control the spec — community tools stay in sync automatically when you update it.

What This Gives Your Team

Current situation With this tooling
Version mismatches discovered in review Blocked at preflight, developer fixes in minutes
Binary files from unknown developers enter queue Flagged locally, developer aware before submitting
AI slop detected manually Tier 2 scan surfaces low-effort submissions
New team member doesn’t know unwritten rules Rules are in the gem; always current
Human reviewer reads every SketchupRequire offense rubocop-sketchup already catches this; just needs a wrapper

The goal is not to replace your review — it’s to ensure that what reaches your queue has already passed the mechanical checks, leaving your reviewers free to focus on the things that actually require human judgment: originality, safety intent, UX quality.

Proposed Next Steps

  1. We build ew-preflight v0.1 (Tier 1 only) — open source, MIT license, community-maintained. We’re happy to build this without any commitment from your team.

  2. We’d welcome a 30-minute call to understand which of your current rejection reasons could be expressed as machine-readable rules. Even a rough list shared informally would let us cover 80% of the cases.

  3. If the sandboxed API endpoint (Proposal 2, item 3) is on your roadmap anyway, we’d love to be early testers.

We recognize you’re stretched thin right now, so we’ve deliberately designed this as something the developer community builds for you — not something that requires your team’s engineering time to maintain.

Thanks for all you do keeping the ecosystem healthy!

Disclaimer: I’m posting this on behalf of AgiliCity | Modelur, not as Extensioneers Guild member. But I’m pretty sure some Extensioneers would be interested in contributing if we are to move forward with this.

5

If submissions are already piling up, perhaps the best option is to pause new ones temporarily until a faster approval system can be put in place.

6

Another option would be to introduce a submission fee, similar to the Google Play Store.

7

Please NO
Why people should PAY in order to submit free plugins???
Are you serious??
This is absolute nonsense..

8

I see a future where paid ‘pro’ plugins get priority queue for screening and approval.
Free plugins wait in line.

There is SketchUcation as well. I haven’t been on there in a long time but I occasionally have need of an old snippet or something. And I believe several authors here use their system for licenses / payment.

9

A submission fee would create a basic barrier, reduce low-effort uploads, and protect the review team’s limited time. Right now, SketchUp plugins are spawning like video game characters, and reviewing every submission for free may soon become unrealistic.

10

Would create a barrier for sure, but that’s no good.
We don’t need to create a barrier to generous DEVELOPERS creating useful extensions and sharing for free.
We absolutely need to create a barrier against AI slop.

And this is a proper way of doing it. :backhand_index_pointing_down:

11

let’s thank AI for that. people don’t bother looking for a plugin, they just vibecode it now.

so many plugins are basically a reskin of something we already have… :melting_face:

12

Or maybe a fully-fledged Fredo plugin :grinning_face:
I constantly partecipate to Sketchucation. That’s the true, original community. :smiling_face_with_three_hearts:

13

Agreed. I have many from there, lots of legacy stuff that I don’t use much anymore, and of course Fredo’s work, which I happily pay for.

A long time ago in a galaxy far far away I was fairly active there. But not so much anymore. When I do visit it is like drinking a good cup of diner coffee … good stuff, from simpler times, without all the milk and sugar and sweeteners in it.

14

Yeah, definitely. It was more of having a conversation about modeling. I mean.. this is my all time favorite thread, but there are others which follow this kind of vibes.

At a certain point, the community split into various forums, Reddit, multiple social media platforms, more or less private groups… and the result is that if you remove generic help posts from beginners, feature requests, complaints about costs, self-promotion, etc., little or nothing remains compared to the good ol’times.

I believe the initial step in enshitification was with social media explosion, but I’d say AI is becoming the final blow.
And this applies not only to shared media and promotion bots, but also to plugins, as this thread proves.

15

same here.

most posts these days are broken files and bugs.
social networks (all of them) + ai (asking chat gpt for advice) diluted the pool. it’s a bit sad. it comes and goes
I wish more people would show their stuff and discuss it, but it’s mostly tech support on both forums now.

16

Guilty as charged. Probably every plugin I’ve currently vibe-coded already had an existing plugin somewhere else that I either didn’t put in enough effort to find or didn’t realize until after the fact, rofl…

17

I miss RSS feeds. And blogs that were updated. And the old forums that just aren’t the same anymore.

I still keep in touch with a friend I made via the old GoogleGroups - he and I share family stories and catch up and recently I have him working with a few of my clients (web dev and print media).

I was in a paragliding WhatsApp here, everyone knew everyone and everyone had admin access. If you were invited you knew someone… but then some changes to WhatsApp to allow for merging / more ‘social’ features happened. One of the members tossed our group in with several others. All of the sudden there were 100+ members (administrators all!) instead of maybe 20-30. The group grew exponentially, with maybe 10-15 of the early members still using it for what it was for (arranging / coordinating flying days, weather analysis, etc.). I left about a month ago.

I’ll sound like and old man yelling at clouds but I wish the days of independent publishing, RSS feeds and people hosting their own content - sharing stories, meeting in real life, curating their hobbies and photos and life experiences had not been siloed and monetized into ‘social media’.

18

Every era looks like decline if you hold it against a polished memory. But there’s fresh coffee being poured right now too. You just have to be willing to taste it.

19

We are working towards automatic AI reviews on submission.

We are also working towards publishing the current review skill we use internally. But it’s not as trivial as just putting it up on GitHub. The skill is meant to run in a specific part of a pipeline and makes assumptions on file paths, a finished rubocop report and other things that doesn’t make sense in the developer’s own workflow. Really much of the content of that skill makes more sense as development rules than a review skill. The challenge is to not have the task snowball.

We are also working on better showing the requirements before you submit.

20

Already been suggested.

Another suggestion is to work proactively on setting the expectations for the review. The review is meant primarily to protect users from extensions that can clash with other extensions and make them malfunction, extensions causing data loss, as well as to protect against unsafe code. The review is not meant as general QA to fix people’s sup-par submissions.

There’s also a discussion what content we want to host. There’s already 24 or something AI renderer extensions. With AI, anyone can generate an extension, and it does not necessarily have to solve an actual problem. Many extensions just do the same things. Many extensions are broken. Other extensions are technically functional but do nothing useful. With recent submissions, often you could do the exact same thing in fewer clicks with native tools, other free extensions, other applications or even your phone or pocket calculator.

With AI, the line between obvious spam submissions and an honest but failed attempt gets blurred. I don’t think the people making these extensions are deliberate spammers bogging down the reviewers on purpose. I think they are trying to build something cool but lack the knowledge and wisdom to do it.

It would be nice with a big sign asking people not to submit these slop extensions, but also it’s very hard to define what slop actually is and to enforce such rules. A few avant-gardes have created masterful slop by hand years before AI while others are using AI to help them create good quality content. AI usage in itself is not a criteria. We have specifically avoided doing a product review because of how hard it is to draw this line.

At the same time we want Extension Warehouse to be the place to share your extensions, for various reasons. Not the least to get a chance to prevent technical issues for our end users.

I appreciate everyone having input and trying to help, but I don’t think the lack of ideas is what’s holding us back. We are moving too fast, spread too thin and chasing changing requirements.