A Maintainer's Advice on Contributing to Open Source in 2026
!Two people holding hands while surrounded by binary code.
The ideal contributor
As an open-source maintainer, you imagine the ideal contributor as an individual that is excited about your project, uses it and understands it, and wants to contribute to make it better for themselves, others, or because of an exciting technical problem.
You get to share ideas with them, learn from each other, maybe even get to know them a bit as a person in the process, and they inspire you to do better work. A profoundly human, intellectual interaction, inspiring and fulfilling, sometimes even resulting in a life-long relationship.
When that happens, it is an amazing experience, absolutely my favorite part of building open-source software.
<!-- truncate -->
I still remember when Craig, whom we didn't know yet then, came out of nowhere and shared his proposal for formal language grammar for Wasp, a proper Latex document: I had to take a week to refresh my knowledge of type inference and language grammars just to be able to respond. The whole team looked together at that document, not believing the work put into it. He ended up doing 3 summer internships in a row with us, implementing a big part of Wasp compiler and language server, and was a delight to work with.
Or, another, more recent situation, when I got somewhat stuck on pushing Windows support for Wasp forward, and @nodtem66 came in with investigation and experiments of his own, effectively unblocking me and becoming a brainstorming partner for driving the feature forward. I remember being impressed by the thoroughness of the work from his side, there was that level of rigor to it that took me back to the uni times, and it was quite an inspiration at the moment.
The reality
However, for every such interaction, there is probably 10x or more low-quality contributions.
And I don't mean low-quality because the contributor is missing technical knowledge, but low-quality because motivation was never right: no real interest for the project, focus instead being on merging the PRs for the sake of merging them, to pump up the author's GitHub account or CV with the proof of contributing to popular open-source repos, or to win some kind of award (e.g. during Hacktoberfest).
What I find most demotivating regarding such low-quality interactions is that when I see a new PR, I can't help but get excited: maybe this is a "good" one, the one where rich, inspiring interaction will happen. But what most likely follows is a dissapointment, and this is a part of what grinds the open-source maintainers down with time.
How AI made it worse
The main thing that changed for worse recently though, with the rise of AI, is that it became very easy to create open-source contributions that look good at first, but there is no real substance or quality behind them.
Before, one could quickly assess the PR for quality: if it looked complex and good, the person behind it for sure had to put the effort and obtain a certain level of understanding of the codebase and the subject matter.
Effort was put in, so you didn't feel bad putting effort from your side also, while reviewing it.
Now, you often just can't know till you dive in deeper.
Good example is Craig's contribution of a Latex document with the new formal grammar for Wasp that I mentioned above. When Craig submitted that in 2021, I didn't think twice about investing a whole week of my own time to be able to review that PR properly. I was brimming with excitement. Even though I knew nothing about Craig.
Today, if I received such a contribution, my first assumption would be that it was AI generated, with no deep understanding of the matter by the author. I wouldn't dare invest a week, or even a day of my own time, to evaluate it.
And to be clear, it's not even about purely evaluating the correctness of the submitted work: maybe it is correct, maybe it works well, maybe it is even well designed. The problem is, I can't rely on the person behind it. I can't hope that there will be a rich, fulfilling cooperation coming out of this, resulting in new ideas, in growing together, creating something together. And if so, if the whole contribution is indeed primarily AI driven, then what is the point? If I wanted to tackle it myself like that, I will prompt my own AI, likely with a better prompt and better context.
This sucks. It sucks that my first assumption these days on seeing a contribution is that it is AI generated, and I wish it wasn't so, but that is how it is at the moment. It sucks for the maintainers, and it also sucks for the honest contributors that are putting in the real work.
What can one do then, as a new contributor to an open-source project, to surpass this?
I thought about this recently, and I believe it comes down to a single thing: building trust.
How to build trust as a new open-source contributor
Before, that was relatively easy: a well-crafted, quality PR would get you a long way.
Today, more is needed, and I will give some ideas below on how to do this, that would do it for me as an open-source maintainer.
Be sincere, be human
Be an honest human and treat others as such.
This is it really. It was always important, but now it is crucial. Everything else stems from it.
Don't treat the project and people behind it as resources or means to an end, e.g. just for getting a notch for your CV. Instead find a project for which you have an honest interest, and it will immediately show.
Also don't be shy to engage in conversation. Maintainers are also humans and will appreciate sincere interaction.
Coommunicate your motivation
Communicate why you are excited about the project, what you have used it for so far, why you want to contribute. You might think it is obvious, but it's often not. It helps maintainers "place you", figure out how to best direct you, what they can expect from you.
Don't use AI for writing (e.g. PR descriptions)
Don't let the AI write for you, or even enhance your writing. This goes for any text others will have to read really. Better to have it not be perfect, than to make others doubt if there is a human behind that text or not. Even if you are not native speaker and are just using AI to "fix" your text: either prompt it to only fix the most minor grammar issues, or use something else like Grammarly, to ensure it doesn't change your tone.
Own the contribution
Check the specific project's contributing guidelines, but most projects won't mind you using AI, as long as you own the contribution: you should own and stand behind every line of code and every decision in your PR, exactly as if no AI was involved. That means you've read it, run it, understood it, and you can explain and defend it under review.
Start with easier, smaller issues
Pick issues that are not demanding on maintainers to review, so they can get to know you and your work before having to invest a lot of time. Make it as easy as possible to review, and explain your reasoning and approach.
Agree with maintainers on what to work on before you start
Learn which issues would maintainers be happy with you taking on. Old issues might have become irrelevant, issues requiring a lot of "taste" for the project or issues touching core parts of the project might be quite mentally taxing to review, etc.
That said, just asking "what are good issues for a beginner" might not be enough. Some repos might have those organized and ready, but many don't, and it also depends on your skills and interests.
What is better is to come already with some suggestions of your own and ask if any of these would be right to start with. While also explaining why each of these is interesting to you and why you would like to tackle it. Even if none of those are a good starting issue, maintainers will now have a much better idea of what you are looking for and will be able to more easily suggest some other issue.
Use the project
Ideally, this would be the reason why you want to contribute: you are a user that wants to give back, make it better for themselves and others.
But even if this is not the case and you want to contribute for some other reason, e.g. because you really like the tech stack and want to gain some experience with it, you should take some time to use the project and learn about it, understand it better.
This will also help with coming up with the ideas for the issues you want to contribute to: you will identify parts of the project you think could be better, and can start from there.
Final thoughts
While it is harder to establish trust as an open-source contributor these days than it was before due to AI, there is a silver lining to it: solution is to be more human and more mindful, which was always the right way to do it.
9 reactions · 1 comment
After 5 years, Wasp 1.0 is coming: a 6-month plan for our full-stack JS framework
!Wasp 1.0 is coming
The time has come: Wasp 1.0 is now officially in the works! ETA: ~6 months.
Even though still young in framework-years, Wasp has been around for some time now (>5y), with over 100 releases, user stories ranging from startups to Fortune 500 companies, $5M raised in funding so far, and a team of currently 8 people and growing behind it plus all the awesome people from our community (waspeteers).
And yet, for years now, we kept Wasp in Beta. Read on to learn why, what changed, and what you can expect from 1.0.
_Want an email when Wasp 1.0 lands? Subscribe here._
The freedom of Beta
For a long time, we didn't have an exact set of features in mind that would allow us to say Wasp is now 1.0.
We always knew what we wanted though, and believed we would recognize it when we got there: the "fullstackiest", managed experience of building web apps there is.
The experience of writing only the code you care about, at the level of detail you want, and the rest being taken care of for you.
All expressed purely in code, flexible, free and easy to deploy anywhere.
That led us to some unconventional choices when designing Wasp:
- We designed our own custom declarative language for describing a web app at a high level (the "Spec") and its own custom compiler.
(psst, that was a bit of a mistake though).
- Our definition of "full-stack" is broader than usual for JS frameworks, fully capturing frontend, backend, database, and deployment, and really everything that falls in between.
- Even though it is currently based on React + Node + Prisma, the underlying machinery has always been designed to allow adding support for other stacks in the future, in large part thanks to the aforementioned Spec and compiler.
Being in Beta gave us the freedom to explore all these concepts unhindered by the weight and responsibility of maintaining a >=1.0 version of a framework (although we did end up following a lot of "production" practices already in Beta: looking at you, brave people who couldn't be stopped from deploying to production).
Ready for 1.0
What makes Wasp ready for 1.0 now? After all this time, I dare say the picture crystallized into something much clearer.
- We found the right shape for the "Spec" (went from our custom language to TypeScript) without giving up on our vision (this was a big one!).
- We developed an intuition for how to balance managed experience with flexibility.
- We collected a lot of feedback on all the major features of Wasp (Auth, RPC, Jobs, Routing, API, Entities, Deployment, etc) and know what people care about and how to get there.
- We are now fully committed to bringing the Full Stack Modules to life, the crown of the "fullstackiest" experience we are aiming for.
We can now see the exact road, paved with GitHub issues, to Wasp 1.0, and it feels right.
The roadmap
You can check the exact roadmap on GitHub.
It consists of epics, and each of those further develops into sub-epics and specific issues.
Roughly, we can break down the epics in the roadmap into:
- General polish (DX).
- Rework of core features (Routing, Auth, RPC, etc).
- Production readiness work (core deps policy, perf/scaling docs, native Win support, etc).
- Novel features (Full Stack Modules, RBAC, etc).
General polish (DX)
While in Beta, we focused a lot on innovating and testing different ideas, and often prioritized those over the rough edges.
However, when accumulated, rough edges become annoying, so one big class of tasks for 1.0 is a lot of smaller, targeted improvements, mostly DX focused.
Some of these are: making Wasp work better with agent orchestrators, nicer output in the terminal, nicer docs, faster npm install, etc.
Check Epic #2884 for more details.
Rework of core features
We never lacked ideas on how to make each of the core Wasp features better (Auth, RPC, Jobs, Email Sender, WebSockets, API, Deployment, etc), but for many of these it was hard to prioritize them while working on bigger framework-spanning improvements (e.g. Spec).
For 1.0, we will bring each of these to a new level! Most of the ideas are already written down in a lot of detail in related GitHub issues, and while some features will require only a smaller touch-up, some will go through a major rework.
For example, Auth will move away from Lucia and add highly requested features like account merging, 2FA, magic links, passkeys, etc. Also, as it currently stands, we will almost certainly reshape it into a more modular implementation that will, next to Wasp Auth, allow using BetterAuth, Clerk, WorkOS or any other auth provider that can implement our auth interface.
Another big one is Deployment: we are looking to simplify wasp build to produce a single server, which will unlock many other things. We are also exploring the smoothest option out there for free hosting of Wasp apps and will be adding it as one of the options in our one-command deploy: wasp deploy <provider>, while also making the current options (Fly, Railway) more robust.
For a full list, see the major features planned for 1.0 in our roadmap.”
Production readiness work
These are non-feature-specific tasks related to bringing Wasp to the level we expect from a >=1.0 framework.
A big one is the core deps policy: from 1.0 onwards we will have a strict policy on how current we keep our core deps (e.g. never more than 6 months behind the latest, which keeps us up to date while avoiding bleeding-edge hiccups).
Then there are docs on performance and scaling: while a lot of this just comes down to the underlying stack (React, Node, Prisma), some of it is also Wasp specific, and we want to make it very clear and easy to understand what you can expect from Wasp in this regard.
And also native Windows support! Wasp works on WSL on Windows, but having it run directly on Windows is something you would expect from a 1.0 framework, right?
Check Epic #2888 for more details.
Novel features
And finally, we are not giving up on innovating just because we are closing in on 1.0.
The star here is FSMs (Full Stack Modules): the ability to define and distribute modular, vertical slices of your web app, e.g. Stripe payments, file upload, AI chat, etc. Imagine libraries, but frontend + backend + database + Spec + even deployment in the future, all type-safe and configurable. It's something we are extremely excited about and have been slowly preparing for quite some time now. We wrote more about the idea in JavaScript still can't ship a full-stack module.
FSMs might not sound like a 1.0 thing right off the bat, but we see them becoming so integral to how Wasp apps will be built that we want to have them, and their effects on Wasp's API, in place before 1.0.
By the way, we are open to ideas for a better name since LLMs keep thinking we are talking about Finite State Machines.
And then we have some more exciting ideas (well, popular requests really) like RBAC (Role-Based Access Control), a modular database layer that would allow support for Drizzle, Wasp Studio (visual representation of your codebase + Wasp dev tooling), etc.
These are more of a stretch goal and might or might not yet be fully stable in 1.0, but we would love to at least have them as experimental features by then.
You can find these under the Ideas column.
See you there
We won't be waiting to ship all of these improvements as one big release; instead, we will constantly be releasing as we merge them, so you will be hearing from us quite a bit as we go and will be able to benefit from them immediately. Once we complete all of them, we will declare Wasp 1.0.
If you have any additional ideas on what you would love to see in Wasp 1.0, let us know on our Discord or on GitHub!
That's it, the destination is locked in: next stop, Wasp 1.0! See you there!
1 reaction
SaaS Boilerplate: 79/100 under method 1.0. Dated method score, not production readiness.
apptension/saas-boilerplate
Open SaaS: 77.3/100 under method 1.0. Joint score with Saas UI. Dated method score, not production readiness.
wasp-lang/open-saas
1 like
Mentions
A Maintainer's Advice on Contributing to Open Source in 2026 !Two people holding hands while surrounded by binary code. The ideal contributor As an open-source maintainer, you imagine the ideal contributor as an individual that is excited about your project, uses it and understands it, and wants to contribute to make it better for themselves, others, or because of an exciting technical problem. You get to share ideas with them, learn from each other, maybe even get to know them a bit as a person in the process, and they inspire you to do better work. A profoundly human, intellectual interaction, inspiring and fulfilling, sometimes even resulting in a life-long relationship. When that happens, it is an amazing experience, absolutely my favorite part of building open-source software. <!-- truncate --> I still remember when Craig, whom we didn't know yet then, came out of nowhere and shared his proposal for formal language grammar for Wasp, a proper Latex document: I had to take a week to refresh my knowledge of type inference and language grammars just to be able to respond. The whole team looked together at that document, not believing the work put into it. He ended up doing 3 summer internships in a row with us, implementing a big part of Wasp compiler and language server, and was a delight to work with. Or, another, more recent situation, when I got somewhat stuck on pushing Windows support for Wasp forward, and @nodtem66 came in with investigation and experiments of his own, effectively unblocking me and becoming a brainstorming partner for driving the feature forward. I remember being impressed by the thoroughness of the work from his side, there was that level of rigor to it that took me back to the uni times, and it was quite an inspiration at the moment. The reality However, for every such interaction, there is probably 10x or more low-quality contributions. And I don't mean low-quality because the contributor is missing technical knowledge, but low-quality because motivation was never right: no real interest for the project, focus instead being on merging the PRs for the sake of merging them, to pump up the author's GitHub account or CV with the proof of contributing to popular open-source repos, or to win some kind of award (e.g. during Hacktoberfest). What I find most demotivating regarding such low-quality interactions is that when I see a new PR, I can't help but get excited: maybe this is a "good" one, the one where rich, inspiring interaction will happen. But what most likely follows is a dissapointment, and this is a part of what grinds the open-source maintainers down with time. How AI made it worse The main thing that changed for worse recently though, with the rise of AI, is that it became very easy to create open-source contributions that look good at first, but there is no real substance or quality behind them. Before, one could quickly assess the PR for quality: if it looked complex and good, the person behind it for sure had to put the effort and obtain a certain level of understanding of the codebase and the subject matter. Effort was put in, so you didn't feel bad putting effort from your side also, while reviewing it. Now, you often just can't know till you dive in deeper. Good example is Craig's contribution of a Latex document with the new formal grammar for Wasp that I mentioned above. When Craig submitted that in 2021, I didn't think twice about investing a whole week of my own time to be able to review that PR properly. I was brimming with excitement. Even though I knew nothing about Craig. Today, if I received such a contribution, my first assumption would be that it was AI generated, with no deep understanding of the matter by the author. I wouldn't dare invest a week, or even a day of my own time, to evaluate it. And to be clear, it's not even about purely evaluating the correctness of the submitted work: maybe it is correct, maybe it works well, maybe it is even well designed. The problem is, I can't rely on the person behind it. I can't hope that there will be a rich, fulfilling cooperation coming out of this, resulting in new ideas, in growing together, creating something together. And if so, if the whole contribution is indeed primarily AI driven, then what is the point? If I wanted to tackle it myself like that, I will prompt my own AI, likely with a better prompt and better context. This sucks. It sucks that my first assumption these days on seeing a contribution is that it is AI generated, and I wish it wasn't so, but that is how it is at the moment. It sucks for the maintainers, and it also sucks for the honest contributors that are putting in the real work. What can one do then, as a new contributor to an open-source project, to surpass this? I thought about this recently, and I believe it comes down to a single thing: building trust. How to build trust as a new open-source contributor Before, that was relatively easy: a well-crafted, quality PR would get you a long way. Today, more is needed, and I will give some ideas below on how to do this, that would do it for me as an open-source maintainer. Be sincere, be human Be an honest human and treat others as such. This is it really. It was always important, but now it is crucial. Everything else stems from it. Don't treat the project and people behind it as resources or means to an end, e.g. just for getting a notch for your CV. Instead find a project for which you have an honest interest, and it will immediately show. Also don't be shy to engage in conversation. Maintainers are also humans and will appreciate sincere interaction. Coommunicate your motivation Communicate why you are excited about the project, what you have used it for so far, why you want to contribute. You might think it is obvious, but it's often not. It helps maintainers "place you", figure out how to best direct you, what they can expect from you. Don't use AI for writing (e.g. PR descriptions) Don't let the AI write for you, or even enhance your writing. This goes for any text others will have to read really. Better to have it not be perfect, than to make others doubt if there is a human behind that text or not. Even if you are not native speaker and are just using AI to "fix" your text: either prompt it to only fix the most minor grammar issues, or use something else like Grammarly, to ensure it doesn't change your tone. Own the contribution Check the specific project's contributing guidelines, but most projects won't mind you using AI, as long as you own the contribution: you should own and stand behind every line of code and every decision in your PR, exactly as if no AI was involved. That means you've read it, run it, understood it, and you can explain and defend it under review. Start with easier, smaller issues Pick issues that are not demanding on maintainers to review, so they can get to know you and your work before having to invest a lot of time. Make it as easy as possible to review, and explain your reasoning and approach. Agree with maintainers on what to work on before you start Learn which issues would maintainers be happy with you taking on. Old issues might have become irrelevant, issues requiring a lot of "taste" for the project or issues touching core parts of the project might be quite mentally taxing to review, etc. That said, just asking "what are good issues for a beginner" might not be enough. Some repos might have those organized and ready, but many don't, and it also depends on your skills and interests. What is better is to come already with some suggestions of your own and ask if any of these would be right to start with. While also explaining why each of these is interesting to you and why you would like to tackle it. Even if none of those are a good starting issue, maintainers will now have a much better idea of what you are looking for and will be able to more easily suggest some other issue. Use the project Ideally, this would be the reason why you want to contribute: you are a user that wants to give back, make it better for themselves and others. But even if this is not the case and you want to contribute for some other reason, e.g. because you really like the tech stack and want to gain some experience with it, you should take some time to use the project and learn about it, understand it better. This will also help with coming up with the ideas for the issues you want to contribute to: you will identify parts of the project you think could be better, and can start from there. Final thoughts While it is harder to establish trust as an open-source contributor these days than it was before due to AI, there is a silver lining to it: solution is to be more human and more mindful, which was always the right way to do it.
After 5 years, Wasp 1.0 is coming: a 6-month plan for our full-stack JS framework !Wasp 1.0 is coming The time has come: Wasp 1.0 is now officially in the works! ETA: ~6 months. Even though still young in framework-years, Wasp has been around for some time now (>5y), with over 100 releases, user stories ranging from startups to Fortune 500 companies, $5M raised in funding so far, and a team of currently 8 people and growing behind it plus all the awesome people from our community (waspeteers). And yet, for years now, we kept Wasp in Beta. Read on to learn why, what changed, and what you can expect from 1.0. _Want an email when Wasp 1.0 lands? Subscribe here._ The freedom of Beta For a long time, we didn't have an exact set of features in mind that would allow us to say Wasp is now 1.0. We always knew what we wanted though, and believed we would recognize it when we got there: the "fullstackiest", managed experience of building web apps there is. The experience of writing only the code you care about, at the level of detail you want, and the rest being taken care of for you. All expressed purely in code, flexible, free and easy to deploy anywhere. That led us to some unconventional choices when designing Wasp: - We designed our own custom declarative language for describing a web app at a high level (the "Spec") and its own custom compiler. (psst, that was a bit of a mistake though). - Our definition of "full-stack" is broader than usual for JS frameworks, fully capturing frontend, backend, database, and deployment, and really everything that falls in between. - Even though it is currently based on React + Node + Prisma, the underlying machinery has always been designed to allow adding support for other stacks in the future, in large part thanks to the aforementioned Spec and compiler. Being in Beta gave us the freedom to explore all these concepts unhindered by the weight and responsibility of maintaining a >=1.0 version of a framework (although we did end up following a lot of "production" practices already in Beta: looking at you, brave people who couldn't be stopped from deploying to production). Ready for 1.0 What makes Wasp ready for 1.0 now? After all this time, I dare say the picture crystallized into something much clearer. - We found the right shape for the "Spec" (went from our custom language to TypeScript) without giving up on our vision (this was a big one!). - We developed an intuition for how to balance managed experience with flexibility. - We collected a lot of feedback on all the major features of Wasp (Auth, RPC, Jobs, Routing, API, Entities, Deployment, etc) and know what people care about and how to get there. - We are now fully committed to bringing the Full Stack Modules to life, the crown of the "fullstackiest" experience we are aiming for. We can now see the exact road, paved with GitHub issues, to Wasp 1.0, and it feels right. The roadmap You can check the exact roadmap on GitHub. It consists of epics, and each of those further develops into sub-epics and specific issues. Roughly, we can break down the epics in the roadmap into: - General polish (DX). - Rework of core features (Routing, Auth, RPC, etc). - Production readiness work (core deps policy, perf/scaling docs, native Win support, etc). - Novel features (Full Stack Modules, RBAC, etc). General polish (DX) While in Beta, we focused a lot on innovating and testing different ideas, and often prioritized those over the rough edges. However, when accumulated, rough edges become annoying, so one big class of tasks for 1.0 is a lot of smaller, targeted improvements, mostly DX focused. Some of these are: making Wasp work better with agent orchestrators, nicer output in the terminal, nicer docs, faster npm install, etc. Check Epic #2884 for more details. Rework of core features We never lacked ideas on how to make each of the core Wasp features better (Auth, RPC, Jobs, Email Sender, WebSockets, API, Deployment, etc), but for many of these it was hard to prioritize them while working on bigger framework-spanning improvements (e.g. Spec). For 1.0, we will bring each of these to a new level! Most of the ideas are already written down in a lot of detail in related GitHub issues, and while some features will require only a smaller touch-up, some will go through a major rework. For example, Auth will move away from Lucia and add highly requested features like account merging, 2FA, magic links, passkeys, etc. Also, as it currently stands, we will almost certainly reshape it into a more modular implementation that will, next to Wasp Auth, allow using BetterAuth, Clerk, WorkOS or any other auth provider that can implement our auth interface. Another big one is Deployment: we are looking to simplify wasp build to produce a single server, which will unlock many other things. We are also exploring the smoothest option out there for free hosting of Wasp apps and will be adding it as one of the options in our one-command deploy: wasp deploy <provider>, while also making the current options (Fly, Railway) more robust. For a full list, see the major features planned for 1.0 in our roadmap.” Production readiness work These are non-feature-specific tasks related to bringing Wasp to the level we expect from a >=1.0 framework. A big one is the core deps policy: from 1.0 onwards we will have a strict policy on how current we keep our core deps (e.g. never more than 6 months behind the latest, which keeps us up to date while avoiding bleeding-edge hiccups). Then there are docs on performance and scaling: while a lot of this just comes down to the underlying stack (React, Node, Prisma), some of it is also Wasp specific, and we want to make it very clear and easy to understand what you can expect from Wasp in this regard. And also native Windows support! Wasp works on WSL on Windows, but having it run directly on Windows is something you would expect from a 1.0 framework, right? Check Epic #2888 for more details. Novel features And finally, we are not giving up on innovating just because we are closing in on 1.0. The star here is FSMs (Full Stack Modules): the ability to define and distribute modular, vertical slices of your web app, e.g. Stripe payments, file upload, AI chat, etc. Imagine libraries, but frontend + backend + database + Spec + even deployment in the future, all type-safe and configurable. It's something we are extremely excited about and have been slowly preparing for quite some time now. We wrote more about the idea in JavaScript still can't ship a full-stack module. FSMs might not sound like a 1.0 thing right off the bat, but we see them becoming so integral to how Wasp apps will be built that we want to have them, and their effects on Wasp's API, in place before 1.0. By the way, we are open to ideas for a better name since LLMs keep thinking we are talking about Finite State Machines. And then we have some more exciting ideas (well, popular requests really) like RBAC (Role-Based Access Control), a modular database layer that would allow support for Drizzle, Wasp Studio (visual representation of your codebase + Wasp dev tooling), etc. These are more of a stretch goal and might or might not yet be fully stable in 1.0, but we would love to at least have them as experimental features by then. You can find these under the Ideas column. See you there We won't be waiting to ship all of these improvements as one big release; instead, we will constantly be releasing as we merge them, so you will be hearing from us quite a bit as we go and will be able to benefit from them immediately. Once we complete all of them, we will declare Wasp 1.0. If you have any additional ideas on what you would love to see in Wasp 1.0, let us know on our Discord or on GitHub! That's it, the destination is locked in: next stop, Wasp 1.0! See you there!
SaaS Boilerplate: 79/100 under method 1.0. Dated method score, not production readiness. apptension/saas-boilerplate Open SaaS: 77.3/100 under method 1.0. Joint score with Saas UI. Dated method score, not production readiness. wasp-lang/open-saas