I've been trying to standardize our team's Granola usage for about six months now, specifically leaning on the community plugin ecosystem to avoid writing everything from scratch. My overall impression is that the ecosystem is in a pretty rough state, and it's becoming a real operational risk.
Let's take the `granola-plugin-slack-notify` as a concrete example. The plugin itself is simple—it should post a formatted message to a Slack channel when a Granola run succeeds or fails. I forked it because we needed to add a custom field. Here's what I found in the main branch's GitHub Actions workflow:
```yaml
name: CI
on: [push]
jobs:
test:
runs-on: ubuntu-18.04
steps:
- uses: actions/checkout@v2
```
Ubuntu-18.04? `checkout@v2`? This image was deprecated over a year ago. The last commit to the actual plugin logic was 2 years ago. When I tried to use it with the latest Granola CLI, it failed silently because the internal API it calls had changed. There's no maintainer responding to issues or PRs.
This isn't an isolated case. I've audited about a dozen plugins we considered. The pattern is almost universal:
* **Last Updated:** Most show "last updated 1-2 years ago."
* **Compatibility:** They target older, sometimes unsupported, versions of the Granola core.
* **Documentation:** READMEs are sparse, often missing critical setup or auth steps.
* **Support:** Issue threads are filled with "any update?" and "does this still work?" with zero responses from the original author.
The practical consequence is that we're now in the business of maintaining our own forks. What was supposed to save us time is now creating a backlog of technical debt. We have to:
* Test every plugin against new Granola releases ourselves.
* Patch security vulnerabilities in the plugin's own dependencies (looking at you, old `requests` library in Python-based plugins).
* Write the missing documentation and sane error handling.
So my question is this: is anyone else running into this wall? Has your team adopted a different strategy? Are you:
* Biting the bullet and writing internal plugins from the start?
* Using the community plugins but with a heavy layer of wrapper scripts and monitoring?
* Just avoiding plugins altogether and sticking to the core features?
I'm trying to build a cost/benefit analysis for my engineering lead, and real-world data on how other teams are handling (or abandoning) the community ecosystem would be invaluable. The core tool is solid, but this plugin situation feels like walking through a minefield of future build failures.
Automate everything. Twice.