[Maintainer Wanted] New Leadership Needed for opencode-mem

[tickernelz]

Hi open source developers,

I am currently seeking 1-2 new maintainers for the opencode-mem repository. Due to my increasingly busy work schedule, I haven't been as active in managing this project and believe it needs fresh leadership to keep growing and thriving.

What we are looking for:

• Commitment to being active (reviewing PRs, merging contributions, managing issues, and discussing project direction)
• Basic knowledge of opencode-mem or strong interest to learn
• Willingness to communicate openly on GitHub (issues, discussions, etc.)
• Genuine passion for open source and collaboration

How to apply:
Comment on this issue describing your background, why you're interested, your ideas for the project, and a brief overview of any technical experience (if applicable). All skill levels are welcome, as long as you are motivated and willing to grow!

Thank you for being part of this community and good luck to all future applicants!

[NaNomicon]

Hi! I’ve been working in software development for about 6 years, and I’ve been solo for the last 3. I use a lot of open-source software and generally prefer it over proprietary products because I want to avoid vendor lock-in and keep flexibility in how I work.

I do contribute back sometimes, usually when I run into bugs while using a project and end up fixing them for myself anyway. I just discovered this project yesterday, and it’s funny timing that it’s already looking for maintainers. Instead of continuing to search around for more projects, I’d rather start contributing to ones I find promising and useful in my own workflow.
I probably shouldn’t position myself as someone ready to fully take over the project right now, but I can help immediately with fixing #73, because that issue is directly affecting me at the moment.

I’ve tried a number of other memory-related projects, but they either push users into subscriptions, don’t fit my workflow, or run into the same kind of API/runtime mismatch problems as #73. That’s a big part of why I’m motivated to help here.

Full disclosure: I use AI heavily in development, but I still review the work myself before locking anything in. If that’s acceptable for this project, I’d be happy to help with debugging, reproducing issues, and contributing practical fixes where I can.

[tickernelz]

Hi! I’ve been working in software development for about 6 years, and I’ve been solo for the last 3. I use a lot of open-source software and generally prefer it over proprietary products because I want to avoid vendor lock-in and keep flexibility in how I work.

I do contribute back sometimes, usually when I run into bugs while using a project and end up fixing them for myself anyway. I just discovered this project yesterday, and it’s funny timing that it’s already looking for maintainers. Instead of continuing to search around for more projects, I’d rather start contributing to ones I find promising and useful in my own workflow. I probably shouldn’t position myself as someone ready to fully take over the project right now, but I can help immediately with fixing #73, because that issue is directly affecting me at the moment.

I’ve tried a number of other memory-related projects, but they either push users into subscriptions, don’t fit my workflow, or run into the same kind of API/runtime mismatch problems as #73. That’s a big part of why I’m motivated to help here.

Full disclosure: I use AI heavily in development, but I still review the work myself before locking anything in. If that’s acceptable for this project, I’d be happy to help with debugging, reproducing issues, and contributing practical fixes where I can.

Good, i already sent you an invitation

[NaNomicon]

Thanks, would you mind sharing some plans/general direction before handing off? It might help new maintainers understand and align the project more in the direction that you intended.

[tickernelz]

Thanks, would you mind sharing some plans/general direction before handing off? It might help new maintainers understand and align the project more in the direction that you intended.

actually i made this project just to help my works. and im not using it anymore, because im using simpler method, it's https://github.com/tickernelz/opencode-memory-md. you can do whatever you wantfor this opencode-mem. resolve all issue or do full refactor to make it better its up to you

[tickernelz]

STILL OPEN!

[GraDea]

Hi, I’m interested in helping maintain opencode-mem.

I use OpenCode heavily and I’m especially interested in long-term memory, local-first agent workflows, and making AI coding assistants more reliable across sessions.

I started by working on #134 and opened PR #136 to improve auto-capture failure visibility, retry behavior, and avoid silent/infinite failure loops.

My background is backend/platform engineering and engineering leadership. I can help with:

• issue triage and reproductions
• reliability fixes around auto-capture and session handling
• security/privacy hardening for the local web UI and stored memories
• documentation for real-world OpenCode memory workflows
• reviewing small PRs and helping shape a pragmatic roadmap

I would prefer to build trust gradually rather than ask for full access immediately. If useful, I’m happy to continue with profile-memory reliability (#115) or security hardening (#135) next.

[tickernelz]

Hi, I’m interested in helping maintain opencode-mem.

I use OpenCode heavily and I’m especially interested in long-term memory, local-first agent workflows, and making AI coding assistants more reliable across sessions.

I started by working on #134 and opened PR #136 to improve auto-capture failure visibility, retry behavior, and avoid silent/infinite failure loops.

My background is backend/platform engineering and engineering leadership. I can help with:

• issue triage and reproductions
• reliability fixes around auto-capture and session handling
• security/privacy hardening for the local web UI and stored memories
• documentation for real-world OpenCode memory workflows
• reviewing small PRs and helping shape a pragmatic roadmap

I would prefer to build trust gradually rather than ask for full access immediately. If useful, I’m happy to continue with profile-memory reliability (#115) or security hardening (#135) next.

Invited

[x-Spartacus]

Hi, I’d like to help maintain the project over time. I started with a Windows build/test-suite compatibility PR here: #139

I’m using Windows and can help with Windows compatibility, docs, issue triage, and smaller bug fixes first. I’ll keep contributions scoped and follow maintainer direction.

[tickernelz]

Hi, I’d like to help maintain the project over time. I started with a Windows build/test-suite compatibility PR here: #139

I’m using Windows and can help with Windows compatibility, docs, issue triage, and smaller bug fixes first. I’ll keep contributions scoped and follow maintainer direction.

done, invited

[lovewave02]

Hi, I'd like to help maintain opencode-mem over time. I started by tracing #170
to repeated delivery of the same session message being stored as separate
prompt rows, and opened #171 with focused regression coverage.

My practical focus is TypeScript/Node tooling and reliability-oriented bug
fixes. I can help with issue triage, reproductions, small tested fixes, and
reviewing straightforward PRs. A useful first area would be the prompt and
profile-learning reliability queue, especially behavior that can trigger
unexpected model calls.

I use Codex during development, but I review the diff and run the project's
checks before submitting. I'd prefer to earn trust through this patch before
asking for broader access. If this direction is useful, I'm happy to keep
working through related issues.

[lovewave02]

Thanks for merging #171 and including it in v2.20.0. I'm still interested in helping with the prompt/profile reliability area.

Would you be comfortable with me taking that lane for the next few weeks: triaging related issues, reviewing small PRs, and sending focused fixes? If you'd rather start with one assigned issue or a narrower scope, that's completely fine.

[EyJunge1]

Hi @tickernelz,

I'd like to apply as a maintainer for opencode-mem.

I'm mostly a backend person (Go/Python, APIs, microservices). I've been working on the project in my fork already: https://github.com/EyJunge1/opencode-mem fixed a bunch of upstream issues there, opened a PR to move the DB to Turso, and I'm currently rewriting the Memory Explorer UI in Svelte + Vite (feat/svelte-gui).

I'd be happy to help with reviews, issue triage, and keeping things moving.

Thanks for opening this up.

[tickernelz]

Hi @tickernelz,

I'd like to apply as a maintainer for opencode-mem.

I'm mostly a backend person (Go/Python, APIs, microservices). I've been working on the project in my fork already: EyJunge1/opencode-mem fixed a bunch of upstream issues there, opened a PR to move the DB to Turso, and I'm currently rewriting the Memory Explorer UI in Svelte + Vite (feat/svelte-gui).

I'd be happy to help with reviews, issue triage, and keeping things moving.

Thanks for opening this up.

invited

[edygry]

Do you like the md files vs this? I just ran into that bug the other day where opencode mem would take subagent instructions and act on them. Did that ever get fixed? I was literally on my way to get a PR up but i was busy. I think opencode mem is really cool albeit a little over-engineered and unruly. When i started using it though i was telling some coworkers who use cline to get into the long term memory thing and cline uses md files. Even though that seems fine, i really do see the potential in something like this. let me know if you are still looking for anybody to hop on.