Pocketbase lost its funding from FLOSS fund

Source: Hacker News

Unfortunate update

FLOSS/fund reached out to me again, but due to unforeseen regulatory constraints their partnership with GitHub didn’t work out. Instead they want to issue a wire transfer from India, requiring several cross‑jurisdictional paperwork. I don’t feel comfortable doing that because I don’t trust them—or the Indian government—with processing and storing personal sensitive data (especially over an insecure shared‑mail inbox channel).

So in the end I had to withdraw my FLOSS/fund application and decline the funding.

I made a mistake by not researching more carefully and by not waiting for the disbursal before making big announcements and decisions, but it is what it is.

Nevertheless the main goal remains and I’ll try to publish a stable PocketBase version this year (no hard promises though; the majority of the new UI functionality is already implemented, but I’ll need to look for something else before making more elaborate plans for the remaining tasks).

There will be a new announcement once I have more clarity and readiness to request community feedback.

I’ll lock this discussion to avoid further spamming the participants and repository watchers.

---

Good news

I am happy to announce that yesterday FLOSS/fund contacted me about their decision to sponsor PocketBase as part of their second funding tranche. You can find more details and the other cool projects they’ve chosen to support at:

Note: FLOSS/fund and Zerodha are planning to continue the program next year, so if you are looking for a no‑strings‑attached sponsorship for your open‑source project, I encourage you to apply at .

With this funding, starting from December I’ll be able to work solely on PocketBase for at least one year, with the general goal of delivering a stable PocketBase release by the end of next year. My short‑term focus for now will be on rewriting the UI.

UI Rewrite

One of the biggest limitations of PocketBase right now is the lack of dashboard customization.

While you can create server‑side plugins using the existing app event hooks (e.g., the JS pb_hooks are implemented here; see also a recent community project posted in #7273), there is no mechanism at the moment to extend the UI for things like:

• Adding custom options to existing fields
• Registering new fields
• Customizing the settings and what is shown in “production” mode
• Registering new OAuth2 providers
• Registering new system sections (see #7232)

Usually this shouldn’t be a difficult task, considering that the dashboard runs entirely in the browser and loading HTML/JS/CSS dynamically is what browsers excel at. However, the goal is not to just inject extra assets on the page, because that wouldn’t solve many of the issues above, nor would it suit the UI plugins I plan to build.

Ideally we should be able to interact with the SPA router and the various reactivity states of the dashboard from an external script. This is very hard to achieve when using a compiled framework like Svelte, because it would force everyone to add an extra UI Node.js build step when extending PocketBase—something I want to avoid.

I’ve explored other runtime‑friendly frameworks (Vue, Preact, Lit, Solid, Alpine, Mithril). Any of them could do the job, though Vue or Lit would be my preference. Their own DSLs often clash with other frameworks, and I’m not confident I could maintain them if they undergo a major refactor, change direction, or are abandoned.

My main goal with PocketBase is that once we hit a stable release, I’ll mark the project as “complete.” New changes or features will be added very rarely and will likely follow the bi‑annual Go release cycle—the fewer dependencies we have, the better.

Experimenting with a minimal framework

With that in mind, I’ve been experimenting over the last couple of weekends with a new frontend framework designed around the minimal functionality required for PocketBase.

It’s called Shablon – . It has 0 dependencies and is written in plain JavaScript. I’ll keep it as simple as possible, avoiding a component concept; everything will ideally be plain DOM elements with optional reactivity. A “component” can simply be a function that returns a DOM element, whether created via the t.[tag](attrs, …children) helper or document.createElement(tag).

Shablon isn’t as ergonomic or pretty as Svelte, but I believe it’s better suited for our purpose. If it turns out to be too ugly or inefficient, I’ll revert to Vue or Lit, but for now I’ll continue experimenting with it.

I’ve also started working on a new PocketBase UI kit for reusable elements such as fields, buttons, popups, dropdowns, alerts, etc.

What’s next?

Most likely sometime next week (or the following week) there will be another announcement about an eventual minimal breaking change with the experimental relation‑filter resolution as subqueries. Apart from that, the project will enter a temporary “feature freeze” until I have something more concrete to show regarding the UI. I want to take my time and not rush this, so please be patient.

Thanks once again to FLOSS/fund and @zerodha for supporting the project!