DEV Community: Ripon C Malo

OSSDrop — a curated, community-ranked directory of open-source tools

Ripon C Malo — Mon, 20 Jul 2026 03:16:53 +0000

Finding a good open-source tool is mostly luck. You catch it in a buried Hacker News thread, or a coworker mentions it, or you trip over a repo with 300 stars that does exactly what you needed six months ago. Meanwhile thousands of genuinely useful projects sit unseen because discovery is noisy and nobody's curating it.

We built OSSDrop to make that less random.

What OSSDrop is

OSSDrop is a curated, community-ranked directory of open-source tools, live at ossdrop.com. Every listing points to a real repository with a verified license and star count — no dead links, no vaporware. You can browse by category, upvote the tools you actually use, and submit your own project in a single step.

It runs across three places:

ossdrop.com — the ranked directory, plus a forum for the people building and using these tools.
OSSDrop/OSSDrop on GitHub — an open list you can add your tool to with a pull request.
r/OSSDrop — the subreddit for discussion and finds.

The list and the site share the same data, so anything on the GitHub list flows into the directory.

How the ranking works — and what doesn't buy you rank

This is the part we care most about getting right, so we made it public. There's a full How OSSDrop works page that spells out the ranking, but the short version:

Tools rank on community votes and recency. People upvote what they use; fresh, well-received tools rise. It's the same intuition as a link aggregator, applied to a directory.
Karma is earned, not handed out. You build it by posting and voting like a normal member. Admins can't gift it, and there's no way to buy it.
Boosts and promotion don't move ranking scores. If we ever offer paid visibility, it's clearly labeled placement — it will never quietly reorder the rankings. The vote-based order stays honest.

We wrote it down partly so you can hold us to it.

What you'll actually find on it

A good chunk of the early catalog is the kind of tool developers pass around by word of mouth. If you live in a terminal, a few that are already listed:

lazygit — a terminal UI for git that makes staging, branching, and rebasing genuinely fast.
ripgrep — recursive search that's absurdly quick and respects your .gitignore by default.
fzf — a fuzzy finder that plugs into your shell, history, and just about everything else.
bat — cat with syntax highlighting, line numbers, and git integration.
httpie — a human-friendly HTTP client for testing APIs without wrestling curl flags.

Beyond the terminal, the catalog spans everything from projects out of large labs to tools maintained by one person on weekends. Notable and verified projects carry a Curated badge so it's clear what's been checked.

Adding your tool takes about a minute

If you maintain something open source, submitting is one step: paste the repository URL and OSSDrop auto-fetches the name, description, license, and stars from the forge so you're not filling out a long form. If your tool is already on the list, you can claim it — that request goes to a human, and once it's verified you own the listing and can keep it up to date.

That's the whole point of the "drop" in the name: drop your open-source tool and let people find it.

Why it's built this way

OSSDrop is made by Matily, a nonprofit open-source studio. That shapes the rules: it's free, it's privacy-respecting, and it's neutral. We list other people's tools — including things that compete with each other, and things that compete with us — fairly. A directory is only worth anything if it isn't gatekept, and if you can trust that what's near the top got there honestly.

No fake metrics, no dark patterns, no "best tool ever." Just an accurate, community-ranked home for open-source work.

FAQ

Is OSSDrop free?
Yes. Browsing, voting, submitting, and claiming a tool are all free.

How is it different from Awesome lists or a GitHub topic?
Awesome lists are static and unranked, and topics are just tag pages. OSSDrop is ranked by the people using the tools, kept current, and it's a place to discuss them — not only a list.

Do I have to use GitHub?
You can sign in with GitHub or Google, and the GitHub list accepts pull requests. Support for tools hosted on other forges is on the roadmap.

Can I list a tool I didn't build?
Yes — the directory is meant to be generous. If you're the maintainer and want to manage the listing, use the claim flow to take ownership after a quick verification.

Have a tool you rely on that more people should know about? Add it, or upvote the ones already there: ossdrop.com.

Open-source Grammarly alternatives in 2026 — and why I built another one

Ripon C Malo — Tue, 14 Jul 2026 16:44:22 +0000

If you search "Grammarly alternative," you get listicles full of freemium tools that are just smaller subscriptions. What I actually wanted was simpler: grammar checking in every text field of my browser, without a subscription and without my text being routed through a company's servers.

I went through the open-source options first. Here's the honest rundown — and then the tool I ended up building, which is also free and open source.

The open-source landscape, honestly

LanguageTool — the most mature open-source grammar checker (the core is open source and self-hostable via Docker). Rule-based, supports 40+ languages, solid browser extension. The catch: the hosted extension most people install is freemium with premium rules paywalled, and rule-based checking misses things an LLM catches easily — run-on sentences, agreement across clauses, awkward phrasing. Self-hosting fixes the privacy question but means running a Java server.

Harper — a modern grammar engine in Rust, compiled to WASM, running fully locally. Genuinely private (nothing leaves your machine) and fast. The trade-off is the flip side of being local and rule-based: English-focused, and it won't judge whether your whole sentence makes sense the way an LLM does.

Vale — not really a Grammarly alternative; it's a style linter for docs-as-code (enforcing style guides in CI). Great at what it does, different problem.

So the field splits into two camps: rule-based and private (Harper, self-hosted LanguageTool) or LLM-smart but subscription-and-server-based (Grammarly, QuillBot). I wanted the third quadrant: LLM-smart and private and free.

The trick that makes the third quadrant possible

The insight behind GemType is almost embarrassingly simple: Google's Gemini API has a genuinely usable free tier, and modern flash-tier models are more than good enough for grammar work. So instead of running a paid middleman server between the user and the model, the extension talks directly from the browser to Google's API using the user's own free key.

That single architectural decision cascades into everything people actually want:

Free — the user's free-tier key covers daily writing comfortably
Private — there is no vendor server; I never see anyone's text or key
Auditable — no backend means the entire data path is in the extension source
Any language — the model checks whatever language you write in, auto-detected

The parts that were actually hard to build

The LLM plumbing is the easy 10%. The hard 90% is the same thing that makes Grammarly's engineering interesting:

1. Underlines without touching the page's DOM. If you wrap flagged words in <span>s inside a React/ProseMirror editor, you corrupt its internal state (Grammarly abandoned exactly this approach years ago). GemType draws wavy underlines on a transparent overlay in a shadow root, positioned via Range.getClientRects() for rich editors and a hidden mirror element for plain <textarea>s.

2. Snippets, not offsets. LLMs are unreliable at reporting character offsets. Instead, Gemini returns structured JSON (responseSchema) with the exact erroneous snippet and its correction; the client locates snippets with substring search and re-anchors them live as you type.

3. Undo-safe fixes. Corrections are applied with document.execCommand('insertText'), which preserves the native undo stack and fires real input events — so frameworks treat the fix as a user edit.

4. Sentence re-checks. After every accepted fix, the surrounding sentence is automatically re-checked (scoped to that sentence, not the document — token-frugal). Word-level fixes stop leaving broken sentences behind.

5. The bug I'll remember: on Reddit everything worked — invisibly. Reddit ships CSS that hides unknown custom elements (visibility:hidden), which nuked my overlay host. Fix: every host style set inline with !important.

It's all vanilla JavaScript, Manifest V3, no build step. If you're building an extension that has to coexist with hostile editors, the source may save you some scars: github.com/riponcm/GemType.

Where each tool actually fits

Tool	Engine	Privacy	Languages	Cost
LanguageTool (self-hosted)	Rules	Local	40+	Free + your server
Harper	Rules (Rust/WASM)	Fully local	English-focused	Free
Vale	Style rules	Local/CI	n/a (style)	Free
Grammarly / QuillBot	LLM + rules	Vendor servers	English + few	Freemium → $12–30/mo
GemType	LLM (Gemini)	Direct to Google with your key; no vendor server	Any, auto-detected	Free (your free-tier key)

Honest trade-offs of GemType: you spend two clicks getting a free API key from Google AI Studio (no card), you need an internet connection, and Google Docs isn't supported (it renders to canvas and gates its annotation API to whitelisted vendors — the one place only Grammarly-tier companies can go).

Try it

Website / live demo: gemtype.matily.org
Chrome: Chrome Web Store
Edge: Edge Add-ons
Firefox: Firefox Add-ons
Source (Apache-2.0): github.com/riponcm/GemType
2-minute tutorial:

One more thing that only an open-source tool can offer: don't trust my privacy claims — paste the repo into ChatGPT/Claude/Gemini and ask it to audit where your text and key are sent. The answer should be "generativelanguage.googleapis.com and nowhere else."

It's a solo project under my studio, Matily. Issues and PRs welcome — editor-compatibility reports are gold. And if it's useful, a GitHub star genuinely helps people find it.

Disclosure: I'm the author of GemType. It's an independent project, not affiliated with or endorsed by Grammarly, QuillBot, LanguageTool, or Google. "Grammarly" is a trademark of Grammarly, Inc.

🚀 Solo dev, months of work, launching today on Product Hunt. projectmem — local memory + judgment layer for AI coding agents. Open source. MIT. Free forever. 5 seconds of support means the world 🙏 https://producthunt.com/products/projectmem

Ripon C Malo — Thu, 21 May 2026 16:28:06 +0000

producthunt.com

How I built projectmem — an MCP server that gives Claude, Cursor, and Codex persistent memory

Ripon C Malo — Thu, 21 May 2026 02:30:29 +0000

Few months back, my AI coding agent confidently suggested this fix:

.header-preview {
    contain: layout;
}

I'd tried that exact thing the previous Friday. It didn't work. The agent had no memory of the failure — different chat, fresh context, same dead-end.

This happens every Monday. Across Claude, Cursor, Codex, Antigravity — agents are stateless between sessions. Each new conversation pays 5,000–20,000 tokens to rebuild context that existed yesterday. The model isn't broken; the architecture is.

So I built projectmem. This post walks through what it actually does — five killer features, a four-view D3 dashboard, the architecture, and the conda/venv hook bug that nearly shipped v0.1.3 broken. It's open source, MIT, runs 100% local, ships as a single pip install.

What projectmem is, in 60 seconds

A small Python package that does three things:

Captures development events — bugs, fix attempts, fixes, decisions, gotchas — into plain-text JSONL inside your repo (.projectmem/events.jsonl). You commit it. You can git diff it.
Exposes 14 MCP tools so any MCP-capable AI client (Claude Desktop, Claude Code, Cursor, Antigravity, Codex) reads and writes that memory directly. One config block per client, works in all of them.
Runs git hooks that warn you at commit time before you repeat a logged failed approach.

pip install projectmem
pjm init

That's the install. pjm init writes the memory directory, drops a CLAUDE.md bridge file, installs the git hooks, pre-populates PROJECT_MAP.md from your stack manifests, and prints a ready-to-paste MCP client config block. No cloud, no daemon, no telemetry.

The five killer features

1. Pre-commit warnings (the differentiator)

The git pre-commit hook checks your staged file against memory. If there's a logged failed approach on that file, it warns you before the commit lands.

projectmem: Pre-Commit Check
────────────────────────────────────────────────────────────

  styles.css
    WARN  1 failed attempt on this file
           Last failure: tried contain: layout — preview still jumps
             (3 days ago)

────────────────────────────────────────────────────────────
1 warning(s). Review before committing.

Most "AI memory" tools are retrieval engines — they store conversations and surface them when asked. projectmem is a judgment layer — it captures events with explicit outcomes (worked / failed / partial) and uses git context to interrupt you before you waste another afternoon. The pre-commit hook is the unlock.

2. Cross-project memory

Lessons in one repo automatically surface in others on the same stack. Library gotchas, framework decisions, patterns you only had to learn once.

~/.projectmem/global/
├── library_gotchas.jsonl
├── patterns.jsonl
└── .promotable.json    ← self-curating cache

When you pjm init a new project, projectmem detects your stack from pyproject.toml / package.json / Cargo.toml / go.mod and injects relevant cross-project gotchas into AI_INSTRUCTIONS.md. Stack-aware filtering, so a vite project's mention of "next" doesn't pollute Next.js gotchas in your actual Next.js repos.

100% local — ~/.projectmem/global/ stays on your machine. No cloud sync, no account, no telemetry. A gin gotcha you log in proj-go shows up in your next Go repo. A vite gotcha in proj-react shows up in your next React repo.

3. Provable ROI (`pjm score`)

An A+ → F letter grade backed by concrete numbers. The first AI memory tool with metrics a CTO can verify.

$ pjm score

projectmem Prevention Score: A- (87/100)
  Failed approaches on record: 8
  Decisions documented: 14
  Fixes with context: 12
  Debugging hours saved: ~12h
  Tokens saved: 47,500
  Estimated USD saved: $4.75

Output as terminal, JSON for CI (pjm score --format json), or a shields.io badge for your README. Lets you put a number on the value the memory layer is actually producing — instead of a marketing claim.

4. Smart context injection (`pjm wrap`)

Launches your AI agent with a token-budgeted context block already loaded — so the agent starts with your project memory inherited, instead of blank.

$ pjm wrap claude --tokens 2000
# launches Claude with a 2000-token context block of:
# - your project summary
# - recent decisions
# - relevant cross-project gotchas
# - any failed approaches on files you'll likely touch

Works with Claude Code, Cursor (writes to .cursorrules), Aider, and clipboard-paste for everything else. The AI session begins experienced, not from zero.

5. Real-time file watcher (`pjm watch`)

Auto-starts on pjm init in interactive terminals. Detects rapid edits to the same file (debugging sessions) and logs churn events automatically. Battery-aware, gitignore-aware. Catches what AI silently misses — the between-commits iteration where most actual debugging happens.

$ pjm watch --status
projectmem watcher: active (PID 47891)
  Watching: /Users/me/repos/your-project
  Events captured today: 12 churn, 3 commit
  Battery: AC power (full speed)

The visualization: four D3 dashboards from one command

This is the part I think most projects skip and shouldn't.

$ pjm visualize
# opens localhost:8765 in your browser

You get an interactive D3 dashboard with four views, all auto-generated from your memory — zero extra AI tokens.

Story Map

The complete narrative of your project — every decision, milestone, and failure visualized as an interactive force-directed graph. Failed files glow red in the heatmap. Drag nodes around. Zoom into problem areas. Your AI reads this to understand not just what your project is, but how it got here.

ROI Dashboard

Live visualization of how much projectmem actually saves you. Animated counters for tokens prevented and USD protected. Capture-source donut showing manual vs auto-captured events. File churn heatmap surfacing your most-debugged files. Cumulative savings area chart over time.

Architecture Map

Toggle between a horizontal dendrogram (clean, hierarchical) and a force-directed graph (relationships, churn). Both auto-generated from PROJECT_MAP.md. Zoom, pan, color-coded by folder.

Event Timeline

Every event in your memory rendered chronologically — with AUTO badges distinguishing auto-captured events from manual ones. Filter by Manual / Auto-captured / event type. Activity bar chart shows the rhythm of your project.

The whole thing is one HTTP server, vanilla D3.js, no React, no framework. Loads instantly. The view your AI agent reads in summary.md is the same view you can scrub through interactively when you open the dashboard.

The architecture (for the engineers in the room)

Stack:

Python 3.10+, ~600 LOC core
Dependencies: mcp, typer, watchdog. That's it. No frameworks, no daemon, no port.
Storage: append-only JSONL inside the repo, distilled into Markdown.
Transport: stdio MCP. The AI client spawns the server as a subprocess; no network, no localhost binding, no process to babysit.

The 14 tools:

get_instructions     get_summary        get_project_map
get_context          get_score          get_global_gotchas
get_issue            search_events      precheck_file
log_issue            record_attempt     record_fix
add_decision         add_note

Every parameter has a Pydantic Field(description=…) annotation, and where it matters, a schema-level constraint:

def record_attempt(
    summary: Annotated[str, Field(description="One-line description of what you tried.")],
    outcome: Annotated[str, Field(
        description="Result of the attempt.",
        pattern="^(worked|failed|partial)$",
    )] = "failed",
    ...
)

The schema literally rejects outcome="maybe" before the tool body runs. Cleanest way I've found to add real guardrails to LLM-generated tool calls.

Why stdio, not HTTP

agentmemory (the most-starred competitor) runs a Node daemon on three ports (3111 / 3112 / 3113) with a separate iii-engine binary and ~21,800 LOC. Excellent retrieval. Heavy install.

projectmem stays stdio-only on purpose:

No port to babysit
No daemon to remember to start
No conflict with existing infra
The AI client manages the subprocess lifecycle for free

Tradeoff: no cross-process state. For single-developer-per-project workflows, that's not a real tradeoff — every benefit goes to "one less thing to debug."

The privacy guardrail

projectmem stores event text verbatim in your repo. That's the whole point — the memory is plain text you can git diff. The downside: a careless paste in an AI chat — "the bug repros when I set OPENAI_API_KEY=sk-..." — would otherwise land that key on disk.

v0.1.3 closes that hole. Before any event hits disk, storage.append_event runs a conservative pattern scrubber across the user-supplied text fields. Matches against high-confidence patterns get replaced with [REDACTED:<kind>]:

Patterns: OpenAI sk-, GitHub PAT, AWS AKIA, Google AIza,
          Slack tokens, Stripe live/test keys, JWTs (eyJ...),
          Bearer tokens, PEM private-key blocks.

Patterns are intentionally narrow. Ordinary debugging prose — "tried contain: layout", "forgot password reset flow" — is never touched. 29 unit tests pin both true-positive and false-positive behavior.

Default-on. PROJECTMEM_NO_REDACT=1 opts out for the rare contexts where you genuinely want the raw text.

Either it's there from day one or users learn not to trust the tool. v0.1.3 makes it day one.

How to try it

pip install projectmem
cd your-project
pjm init

pjm init ends by printing a ready-to-paste MCP config block (absolute sys.executable baked in to dodge the Claude-Desktop / Cursor PATH-inheritance gotcha). Paste it into your client's config file:

Claude Desktop: ~/Library/Application Support/Claude/claude_desktop_config.json
Cursor: ~/.cursor/mcp.json
Antigravity legacy IDE: ~/.gemini/antigravity/mcp_config.json
Codex (TOML, not JSON): ~/.codex/config.toml

Cold-start your client and the 14 projectmem tools appear in the MCP panel.

Links:

Repo: https://github.com/riponcm/projectmem
60-second demo: https://youtu.be/YCqfJ8-XVqY
Step-by-step tutorial: https://github.com/riponcm/projectmem/blob/main/TUTORIAL.md
PyPI: https://pypi.org/project/projectmem
Official MCP Registry: https://registry.modelcontextprotocol.io (search projectmem)

What's next

The v0.2 roadmap:

Stale-memory detection — flag, never delete. Cross-reference each decision's referenced file against recent git activity; surface decisions that predate heavy churn as "possibly stale, confirm or supersede."
Explicit --supersedes on add_decision — the honest version of memory decay. Old decision retired with a back-reference; nothing destroyed; full audit trail.
Semantic search as an opt-in extra (sentence-transformers + sqlite-vec). Default install stays dependency-light.

Honest about the rough edges

Search is exact substring today, not semantic
API may still shift before 1.0
The precheck heuristics are simple right now (file-name match → surface failed attempts)
Recall benchmarks are unpublished (the equivalent for "judgment accuracy" hasn't been defined yet)

But: 58 unit tests, end-to-end verified across Claude Desktop / Claude Code / Cursor / Antigravity / Codex, the conda gotcha properly fixed, the privacy guardrail real and tested, the visualization dashboard genuinely useful.

If you build with AI coding agents every day, try it once on a real project. The pre-commit hook usually catches its first real failure within the first week.

What's the worst "I already told you this last week" moment you've had with your AI agent? Reply below — that's exactly the pattern the precheck heuristics need to learn from.

Thanks for reading.

— Ripon