Call for Proposals. July 2026 Survey
Greetings folks!
Clojurists Together is pleased to announce that we are opening our Q3 2026 funding round for Clojure Open Source Projects. Applications will be accepted through the 24th of August 2026 (midnight Pacific Time). We are looking forward to reviewing your proposals! More information and the application can be found here.
We will be awarding up to $29,000 USD for a total of 4-5 projects. The $2k funding tier is for experimental projects or smaller proposals, whereas the $9k tier is for those that are more established. Projects generally run 3 months, however, the $9K projects can run between 3 and 12 months as needed. We expect projects to start around mid-September 2026.
A BIG THANKS to all our members for your continued support. We also want to encourage you to reach out to your colleagues and companies to join Clojurists Together so that we can fund EVEN MORE great projects throughout the year.
And Now the Survey…
We surveyed members in July to find out what what issues were top of mind and the types of initiatives they would like us to focus on for this round of funding. While our goal for the survey is to surface the broadest, most consistently-raised themes, it is not meant to be prescriptive, as we are always interested in nurturing new ideas and approaches. As always, there was a lot of great input and we hope it will be useful in informing your project proposals.
Select Themes:
Demonstrated Impact of Past Funding Roughly three-quarters of respondents draw on CJT-funded work on a near-daily to weekly basis, with the remainder spread across occasional, project-dependent, or passive-interest use. This is strong evidence that past funding has produced tools and libraries with real, sustained utilization — which is why we exist!
Adoption and Growth of Clojure Continue to be of Concern. This theme is closely linked to employment challenges cited. These themes require broader or more strategic solutions that may be best addressed by the Core Team. However, Clojurists Together can support smaller and more focused efforts. Some ideas include:
- Facilitating discovery of existing tools and documentation currently residing in disparate spaces so that both new and seasoned users can quickly reference new and updated content.
- Support for developers willing to present the Clojure story to their professional or tech-adjacent communities.
- In addition to the mentoring already underway, development of self-directed training that is easy and cost-effective to scale.
About 88% of Members Surveyed are Using AI tools in some capacity - with members calling out the need for Clojure-specific support.
Developer Experience Tools are Respondents' Top Priority for Clojure and ClojureScript with Error Messaging identified in the top 4 for both. There is plenty of work that needs to get done in these categories. The good news is that the Clojure core team along with the CLI Task Force is actively working on improving the user experience of the command-line tooling. More to come in the few months….
July 2026 Survey Summary:
This summary includes a selection of member comments.
1. Who We Heard From: Respondent Profile & Platform Usage
Before weighing the themes below, it’s worth noting who answered this survey. The respondent base skews heavily toward long-tenured Clojure developers, and server-side JVM use dominates how members actually deploy Clojure.
Tenure
Of 41 respondents, the overwhelming majority have used Clojure for a long time:
| Tenure | Share of respondents |
|---|---|
| 6 years or more | ≈87.8% |
| 1–5 years (combined) | ≈10.7% |
| Less than 1 year | ≈1.5% |
*87.8% reported 6 years or more of Clojure experience, with only a small remainder spread across 1–5 years and under 1 year combined. This is an important caveat for every other theme in this report: the feedback is disproportionately the voice of veteran users, not newcomers.
Mentoring vs. beginner status
Respondents identified overwhelmingly as mentors rather than newcomers. Combined with the tenure data above, this confirms the survey sample is dominated by experienced members who are already invested in growing the community.
Platforms targeted (41 respondents, select-many)
| Platform | Responses | % of respondents |
|---|---|---|
| Clojure – JVM server | 40 | 97.6% |
| ClojureScript – Browser | 28 | 68.3% |
| Clojure – JVM client application | 8 | 19.5% |
| ClojureScript – Node server | 5 | 12.2% |
| ClojureScript – Mobile platform | 5 | 12.2% |
| ClojureScript – Desktop application | 3 | 7.3% |
| ClojureDart | 2 | 4.9% |
| Clojure – Mobile platforms | 1 | 2.4% |
| Babashka / Node.js / Scittle (write-ins, ~1 each) | 1 each | 2.4% each |
| Clojure CLR – Server | 0 | 0.0% |
| Clojure CLR – Client | 0 | 0.0% |
*Clojure on the JVM server remains the dominant deployment target by far (97.6%), with ClojureScript in the browser a strong secondary use case (68.3%). Notably, ClojureDart shows minimal current usage (4.9%) despite being repeatedly and enthusiastically flagged in the open-ended “magic wand” and ecosystem-support answers (Section 8) — a gap between current adoption and member enthusiasm worth factoring into funding decisions.
2. Quantitative Priorities: Areas for Improvement
Members were asked which areas of Clojure and ClojureScript most need improvement (select-many). Developer Experience Tools ranked #1 in both languages, and data/error-handling concerns dominate the Clojure-specific results.
Clojure (35 respondents)
| Rank | Area | Responses | % of respondents |
|---|---|---|---|
| 1 | Developer Experience Tools | 16 | 45.7% |
| 2 (tie) | Data Analysis / Processing Frameworks | 14 | 40.0% |
| 2 (tie) | Error Messages | 14 | 40.0% |
| 4 (tie) | IDE Support | 8 | 22.9% |
| 4 (tie) | Debuggers | 8 | 22.9% |
| 6 (tie) | Documentation | 7 | 20.0% |
| 6 (tie) | Test Tooling | 7 | 20.0% |
| 8 (tie) | Build Tooling | 6 | 17.1% |
| 8 (tie) | Profilers | 6 | 17.1% |
| 10 (tie) | Linters | 5 | 14.3% |
| 10 (tie) | Code Coverage | 5 | 14.3% |
| 12 | Online Services | 3 | 8.6% |
| 13 (tie) | Backend framework (write-in) | 1 | 2.9% |
| 13 (tie) | Performance (write-in) | 1 | 2.9% |
| 13 (tie) | AI-supported development (write-in) | 1 | 2.9% |
ClojureScript (26 respondents)
| Rank | Area | Responses | % of respondents |
|---|---|---|---|
| 1 | Developer Experience Tools | 11 | 42.3% |
| 2 | Build Tooling | 7 | 26.9% |
| 3 | Documentation | 6 | 23.1% |
| 4 | Error Messages | 5 | 19.2% |
| 5 (tie) | IDE Support | 4 | 15.4% |
| 5 (tie) | Debuggers | 4 | 15.4% |
| 5 (tie) | Code Coverage | 4 | 15.4% |
| 8 | Test Tooling | 3 | 11.5% |
| 9 (tie) | Linters | 1 | 3.8% |
| 9 (tie) | Data Analysis / Processing Frameworks | 1 | 3.8% |
| 9 (tie) | Profilers | 1 | 3.8% |
| — | Online Services | 0 | 0.0% |
Write-in responses (ClojureScript, 1 mention / 3.8% each): reduced or near-zero NPM dependency, ability to do full-stack development without a separate backend, less reliance on NPM generally, AI-supported development, and “N/A, I don’t use ClojureScript."
3. Theme: Developer Experience Is the Top Tooling Priority
“Developer Experience Tools” was the single highest-ranked improvement area for both Clojure (45.7%) and ClojureScript (42.3%), and it recurs throughout the open-ended answers as well. For Clojure specifically, error messages and data analysis/processing frameworks tied for second place (40% each) — well ahead of documentation, IDE support, and debuggers. For ClojureScript, build tooling (26.9%) and documentation (23.1%) stand out as the next-biggest gaps after developer experience, suggesting the ClojureScript toolchain still feels heavier to maintain than the Clojure one.
4. Theme: 88% of member respondents use AI tools — but Clojure-Specific Support Is Lagging
Claude Code was named most often in the open-ended answers, alongside Cursor, Copilot, Gemini, Aider, ECA, bhauman’s MCP Server, Amazon Kiro (via CP in IntelliJ), Several members pointed specifically to REPL-driven, Clojure-aware tooling (e.g., clojure-mcp / clj-nrepl-eval integrations) as the feature that makes AI genuinely useful for Clojure — but also noted that generic AI tools frequently mishandle Clojure’s syntax (parentheses/brackets) and that few tools understand Clojure idioms well.
What members use AI for (38 respondents, select-many)
| Task | Responses | % of respondents |
|---|---|---|
| Debugging | 26 | 68.4% |
| Code Completion | 25 | 65.8% |
| Learning | 25 | 65.8% |
| Testing | 24 | 63.2% |
| Documentation | 22 | 57.9% |
| Other (write-in) | 10 | 26.3% |
- One respondent noted that we should include ‘Security Reviews’ and ‘Agentic Coding’ as an option in future surveys.
Sub-themes:
- Concern that in an increasingly AI-generated-code world, Clojure loses its traditional advantages (conciseness, expressiveness) if hiring/tooling decisions default to more “mainstream” languages the models are best trained on.
- Mixed sentiment: alongside enthusiastic adopters, a vocal minority is skeptical of or opposed to AI-driven development altogether.
Supporting comments:
“clj-nrepl-eval from bhauman/clojure-mcp-light is central. REPL is the killer feature for AI assisted Clojure dev compared to other languages.”
“I wish ECA would work well with local AI models using Ollama. I dont want to use big tech companies… I dont trust them.”
“Each client provides a chatbot, which might be inside the IDE but I have no idea how to make it work with Clojure and not mess up the brackets.”
“The sad truth is in an ever increasing LLM driven development world there is less incentive to use Clojure than something like Rust. All the downsides in making that switch are alleviated if LLMs are doing the coding for you.”
“I like to use free models and run them locally, if there is a large amount of repeatable and we’ll defined work to do it can be good, like a refactor. Sometimes it’s good to use to test an idea or prototype I would not have time to do otherwise. I generally take it that if an llm agent can do something then it’s likely not that hard to do. If the llm struggles on something that should be simple it’s interesting to find out why.”
“I rarely write code “by hand” anymore. My workflow is primarily prompting various coding agents (Claude code, codex, open code using models via open router) and reviewing their output, but rarely dropping into the editor myself.”
“LLMs are a scourge upon the human race with no actual profitability, and I hope every day to see this bubble finally pop.” “It has basically taking over everything. Agent harnesses.”
“While our company doesn’t forbid the usage of (generative) AI tooling, it doesn’t encourage it either. It is up to each individual developer to use it or not. But the agreed contract is that whatever code a developer produces using AI tooling must meet the same established conventions (e.g., code style, idioms to be used, code and architecture estructure, etc) and quality levels of code produced by human developers. And that the code pushed by that developer must be owned by him/her, and that it is his/her own responsability to maintain, and fix if needed.”
5. Theme: Perception, Advocacy & the “Is Clojure Dying?” Narrative
The single most repeated theme in response to “the biggest challenge facing Clojure developers” was one of perception rather than technology: Clojure is widely seen — inside and outside the community — as niche, shrinking, or even dead, which makes it harder to justify on new projects, hire for, or pitch to business leadership and investors.
Supporting comments:
“It is a challenge using it on new projects and justifying it over mainstream alternatives. The biggest complaint I always hear is ‘how will we find developers’. " I think this is more of a perception challenge, the easiest way to reply would be to just point to success stories, or a very visible app or product.”
“Outreach. Many people think language is dead”
“In the world of startups Clojure is generally seen as a niche language and therefore a hindrance to selling a company and maybe even also just to getting funding (sometimes). A friend of mine is the CTO of a startup that was in talks for an acquisition, and the company backed out of the deal because Clojure was used.”
Members suggested amplifying success stories and visible production use cases, supporting community “influencers” and advocates, and funding outreach/evangelism efforts aimed at both developers and business decision-makers.
6. Theme: Jobs & Commercial Adoption
Closely tied to the perception theme is a concrete, recurring concern about the Clojure job market: too few open positions, hiring managers who default to languages with larger corporate backing, and no “gateway” framework (comparable to Rails or ML Frameworks) that pulls new developers into the language the way it once did.
Supporting comments:
“Lack of job opportunities. Big companies are quite skeptical about non-mainstream languages.”
“The people that make hiring decisions view developers as fungible goods, which then leads them to choose languages based on which one they believe will have the lowest salary/hourly cost which tend to be the languages with large corporate backers, and Clojure is not one of those languages.”
7. Theme: Library, Framework & Supply-Chain Health
Members flagged specific maintenance gaps in the ecosystem: unmaintained libraries with no clear owner, documentation gaps in widely-used projects. Support for projects, tools and platforms cited: (5) CIDER; (4) Malli; (3) ClojureDart, re-frame, Pathom, Babashka, Jank; (2) reagent, Reitit, Shadow-CLJS, Scicloj; (1) HugSQL, clj-kondo, duct, nrepl, datalevin, datahike, Fulcro, Datascript, Glojure, Grain, eca, Telemere, rama, replicant, http-kit, Clojure Civitas, Clay, Datastar, calva, ring, figwheel-main.
Supporting comments:
“Clojurists Together could act as a broker for finding maintainers for out-of-support libraries.”
“Some great projects could use better documentation; two examples of amazing libraries that could use better documentation being Malli and Specter.”
“Port all major libraries to tools.deps”
- Development of a Clojure language spec given the number of Clojure-like languages now emerging.
8. Theme: Community Health, Governance & Connection
The strength, generosity, and openness of the community is seen as a core strength - along with its engineering rigor. Members feedback included a desire for stronger central coordination, more inclusive and welcoming spaces, and a return to in-person connection.
Supporting comments:
“Clojure’s culture of engineering rigour is unmatched in the industry. I think clojurists’ attention to detail and care for their craft is a huge advantage right now in this age of slop and endless downtime. Also the community is warm, welcoming, and friendly, which is not the case anywhere else I “hang out” online”.
“Once people start using Clojure, they usually love it. REPL is great, Clojure is very fast, well designed language, also JVM interop has improved.”
“Resilience of Clojure communities and their support structures seems to be a challenge… In community spaces, some divide and disagreement often appear, and not everybody feels at home and supported.”
“I would create a Clojure foundation that would lead central decision-making for the continued growth and development of the language.” “Community in one digital place, a Clojure language spec.”
“There would be in-person meetups again!”, “That everyone and all events we’re in the same country :) I miss not being able to go everywhere!”
“I don’t know if this counts or not, but my favorite part of the ecosystem is how stable it is. I love that library updates rarely, if ever, break existing code. Having dealt with the churn and instability of the JS and Rails ecosystems, the fact that updates so rarely force me to do tedious work is a godsend.”
9. Theme: Growth, Outreach & Training
When asked directly what areas of the ecosystem need support, “advocacy,” “outreach,” “evangelism,” “mentoring,” and “community and growth” were named repeatedly and independently — more often than any single technical gap — reinforcing that members see growing and renewing the community as at least as urgent as improving the tools themselves.
What is going on?
