Tldraw SDK 4.0(tldraw.dev)
tldraw.dev
Tldraw SDK 4.0
https://tldraw.dev/blog/tldraw-sdk-4-0
54 comments
Answering those two questions depends a bit on the "you" in the question. If "you" refers to the open source project/code, then both can be answered with a resounding "yes". If on the other hand "you" refers to you individually or as a company, then the first can be answered with a resounding "no" and the second a solid "maybe, that depends on how much you are willing to pay us for a 5 year support contract" (though you should probably word it a bit differently when talking with potential clients).
As far as working with source available components, suggestion one is to look for others int he community that you can cooperate with to maintain a fork, and option two, if you really can't get the community to support a fork, is to make it a plugin/optional component, preferably with an API so that other solutions can be integrated as options, or at least a fallback to the old version that was open source.
As far as working with source available components, suggestion one is to look for others int he community that you can cooperate with to maintain a fork, and option two, if you really can't get the community to support a fork, is to make it a plugin/optional component, preferably with an API so that other solutions can be integrated as options, or at least a fallback to the old version that was open source.
Seriously in this specific case I'd cut a final version with V3, then going forward include v4 in main with a note about the tldr licence in readme. The licences are affordable for anyone who wants to use your project, and if they can't they'll have to make do with that old unsupported version of your project.
How is $6000 per year (upfront) affordable? And that's the pricing for startups with <10 employees, surely large organisations / schools (which seem to be the audience of BigBlueButton) will pay much more. What about non-profits etc?
At this point tldraw v4 seems to offers no significant improvements over v3, which does everything I want from a whiteboard. I think most people who can live with the previous watermark will just stick with v3 permanently.
At this point tldraw v4 seems to offers no significant improvements over v3, which does everything I want from a whiteboard. I think most people who can live with the previous watermark will just stick with v3 permanently.
If you've got lets say a 6 person start up your wage bill would be ~$1 Million a year, $6000 feels quite reasonable. I agree that this seems pitched towards "we're making a saas" style startups and that for direct end users this is more difficult however if you can perswade tldraw to price this based on the IT staff your school has then if you've got a group of 5 schools each of 2000 kids, you probably have a IT team of 8-10, $500/month is $0.001c per child per day.
> We have growing by the traditional open source business model:
I know this is not relevant to the thread, but could I pick your brain on this model? I'm looking at launching a product soon and I've been struggling with how I might monetize it in a sane manner that works for customers and for the business.
I know this is not relevant to the thread, but could I pick your brain on this model? I'm looking at launching a product soon and I've been struggling with how I might monetize it in a sane manner that works for customers and for the business.
Here's a tip: when you want to ask somebody a question just ask the question. Do not ask if you can ask a question because you waste everybody's time
To be fair, I did ask a question. The question.
Really, that was your question? I think I can see how you got into a position where you are launching a new product soon and you don't know how you're going to monetize it
Sometimes a conversation is easier than a brain dump in a text only space. Which is why I said 'can I pick your brain' rather than write a massive wall of text of things I've considered, research I've done, product/market fit, etc.
You could do something in between like ask a specific question which is what my original comment was about
Why is tldraw getting more and more centralized/requiring a special license...
I like tldraw as a software but I used to see tldraw having multiple pages in the same canvas and that had helped me tremendously in the past which It seems is now a sign up feature...
I hope excalidraw can catch up too. The more options and the more truly foss options, the better...
I like tldraw as a software but I used to see tldraw having multiple pages in the same canvas and that had helped me tremendously in the past which It seems is now a sign up feature...
I hope excalidraw can catch up too. The more options and the more truly foss options, the better...
Sharing a link is also a sign up feature now. Didn't tldraw come up after Excalidraw was already quite popular? Seems like a missed opportunity for the latter since tldraw came up after and was able to figure out a business angle for a similar (same?) software.
Sorry for the logins around collaboration. I really liked the open collaboration feature too but we were getting some sketchy user behavior around it and my nerve broke. You can still join someone else’s board anonymously though. When you share a link to a board with a friend, they don’t need an account to join the board.
Excalidraw was already really established when I started tldraw, yeah. I was a contributor (the app uses my ink library perfect-freehand!) and still love the project. Excalidraw has done really well with their SaaS app Excalidraw+. I still think the bigger long term need / opportunity is for an SDK product, given that whiteboarding is becoming more of a commodity feature, like kanban boards or maps.
Excalidraw was already really established when I started tldraw, yeah. I was a contributor (the app uses my ink library perfect-freehand!) and still love the project. Excalidraw has done really well with their SaaS app Excalidraw+. I still think the bigger long term need / opportunity is for an SDK product, given that whiteboarding is becoming more of a commodity feature, like kanban boards or maps.
[deleted]
> Our 4.0 release includes a new license with changes to where tldraw can be used. Fate and capital both demand that tldraw be a sustainable project, so these changes are designed to help us commercialize the SDK without cutting off community adoption.
They realized the market is small so they are raising prices
HN irony never ceases to amaze. We’re on a forum hosted by a (the?) startup accelerator. Commercializing an open source project is fraught with challenges. The amount of dissatisfaction and dissent is disturbing. I also see a lot of supportive and nuanced takes. Most of us are here because we make money by making software. Shouldn’t we be rooting for people who are doing the same?
I was hopping between a few canvas tools recently. Primarily tldraw & excalidraw for some quick spec work. Was surprised to see that both don't have better support or even apps for iPad. Feels like a missed opportunity given how many people on iPad would want to use this sort of tool. I know the website still works but it's just a bit clunkier. Another feature request: shape detection.
We support iPad about as good as we can, with stylus pressure and some tricks to avoid slowdowns due to the high input rate. I actually did the ink in Excalidraw too, so it at least worked last time I touched it! But the difference between iPad Safari input latency and native latency is gigantic, really heart breaking to work on. Not sure if a native wrapper would improve things. If I did a native app, it would likely be a minimal drawing app for handwriting only. I recently started prototyping an Android app with the new low-latency jetpack ink APIs and they’re fantastic, beating perceived latency vs iPad even on a 60fps screen (Daylight).
That is a massive license fee here.
IMO A 100-day trial is too short to try it.
I would more likely to use tldraw if it had a monthly fee even at $100-$300/mo.
But $6K a year and getting only community support is a huge risk for some SMEs.
IMO A 100-day trial is too short to try it.
I would more likely to use tldraw if it had a monthly fee even at $100-$300/mo.
But $6K a year and getting only community support is a huge risk for some SMEs.
Small teams are so hard to price for. When we first launched we had a non-commercial license and I was spending forever negotiating these tiny deals with teams where that was already a huge expense. The watermark solution we brought on last year fixed that problem but then anchored our price low for bigger companies. I’m sure half this forum has been through this. It’s so hard!
I expect we’ll do extended trial licenses for teams that are serious but just getting started, or are pre-revenue pre-funding; and there’s a hobby license for non-commercial projects. Pricing… never ends.
I expect we’ll do extended trial licenses for teams that are serious but just getting started, or are pre-revenue pre-funding; and there’s a hobby license for non-commercial projects. Pricing… never ends.
isn’t this self-inflicted in that you’re making the purchase process a sales process for everyone, instead of being self-serve for the little guys? e.g: for teams under 10 people, let them sign up monthly with a per-team member fee. $50/month per team member feels like nothing compared to $6,000/year. I read $6,000/year as “we don’t want your business” because what startup is paying 1 year upfront for anything? They’ll probably be dead in 6 months.
There is a big difference between how startups buy and how enterprises buy, but it seems you’re treating them as equal in everything except budget.
Anyway, easy for me to say that, I have no stake. You know your customers… but as sales-aware observer, it seems very counterintuitive to make low budget people go through a sales process.
There is a big difference between how startups buy and how enterprises buy, but it seems you’re treating them as equal in everything except budget.
Anyway, easy for me to say that, I have no stake. You know your customers… but as sales-aware observer, it seems very counterintuitive to make low budget people go through a sales process.
I'd like to do self-serve pricing like that, maybe we will in the future, but I don't think there are as many teams as you think where the difference would be a deciding factor.
When I was doing pricing discovery and asking early adopters what they would pay for tldraw, almost all the teams I talked to either said "nothing because we don't have any money yet" or a number between $5,000 and $10,000, with a handful of outliers. In the end, my solution was just to put a price on the thing and then find ways to provide for everyone else, including PRPF commercial teams. In 3.x our solution was a watermark, which caused other problems for us; but this discussion made it pretty clear to me that we need to have a better answer for these teams in 4.x.
That said, we've at least got the startup sales _process_ as close to self-serve as we can. Someone still needs to validate the size of the company and send a Stripe link, but 20% of startup licensees were delivered in under 24 hours and more than half are done in under a week.
When I was doing pricing discovery and asking early adopters what they would pay for tldraw, almost all the teams I talked to either said "nothing because we don't have any money yet" or a number between $5,000 and $10,000, with a handful of outliers. In the end, my solution was just to put a price on the thing and then find ways to provide for everyone else, including PRPF commercial teams. In 3.x our solution was a watermark, which caused other problems for us; but this discussion made it pretty clear to me that we need to have a better answer for these teams in 4.x.
That said, we've at least got the startup sales _process_ as close to self-serve as we can. Someone still needs to validate the size of the company and send a Stripe link, but 20% of startup licensees were delivered in under 24 hours and more than half are done in under a week.
Thank you for the insight.
I think that your blindspot is that you are defining your pricing based on conversations with the subset of customers that are willing to enter into a sales process. Engineers being sales-averse has become a meme but it is rooted in truth: many engineers do not want to be sold to. And many product-defining choices are being made by engineers. The success of the bottom-up sales strategy for selling software shows that there is a lot of money to be made by making it easy for engineers to buy.
(My startup spends more than $6k/year on a number of valuable services but I would not have selected the services initially if they required a sales conversation and upfront commitment. Even today, knowing I will spend more than $6k on these services in the next 12 months, as I have in the last 12, I would not commit to paying them $6k today. From my own experience, I'd estimate that that 75% of B2B software subscriptions are monthly, even when an annual plan (with an aggressive discount) is available.)
Tldraw is the best product in the space by far, and an obvious choice for any company building a product that needs a canvas, but your current pricing is a big gift to Excalidraw (and others). Every engineer is going to be thinking about forking over $6k in cash before they decide to run `npm install tldraw`. And unless tldraw is a choice being dictated to them, $6k is going to seem like a very big number they are going to have to justify. During my time as an engineer-employee, I had no defined budget: asking for $6k to be spent on something upfront would be very daunting (even compared to asking for a subscription that would amount to $6k/year).
Tldraw is the canvas SDK but that could change quickly if Excalidraw capitalize on your pricing. If Excalidraw is free to use, and Tldraw is $6k upfront, Tldraw will become the product people try after being disappointed by Excalidraw and convince themselves that Tldraw's superiority is worth an additional $6k spend. You go from being the default to the expensive alternative. Being the default is a golden goose, being an expensive alternative is an uphill battle.
As engineers we feel that because we can, we should, and that's why we want to validate numbers, we want a system that does everything and requires zero trust. And I believe that is likely influencing your thinking about self-serve. Yes, some customers will lie when going through self-serve to keep their bill low, but once Tldraw is integrated into their product, you have leverage to get them paying the right amount. Schedule an account review for every self-serve customer after 6 months. If they look like they might be underpaying, reach out, and get them paying the right amount. When the alternative is ripping out Tldraw, paying thousands of dollars more per year is an obvious choice to make.
If I were commercializing Tldraw, I would be selling it self-serve at $100 per month per developer. I would do away with the trial, and emphasize that the open-source version is free to use in development. I would expect customers to purchase once they are ready to go live in production. I would let customers declare their team size when purchasing. Every 6 months I would review subscriptions, reaching out if the numbers look off.
I would probably drop the 10 team size limit too, and instead make the business subscription more valuable to larger teams. If I have a team of 10 developers working on a product containing Tldraw then I am spending millions of dollars per year on their time. If I can save 1% of that time by having access to support from Tldraw's team, my team can spend their time on the parts of the product that matter. An extra $150 per month per developer ($250/month/developer) would be an obvious choice if it could save each developer a couple of hours per month.
Your product is fantastic and worth far more than $6k per year but getting $6k per year for it requires finesse, not just a decision that $6k is the right number. Anyway, I am just a person writing 500 words for free on HN so caveat emptor.
I think that your blindspot is that you are defining your pricing based on conversations with the subset of customers that are willing to enter into a sales process. Engineers being sales-averse has become a meme but it is rooted in truth: many engineers do not want to be sold to. And many product-defining choices are being made by engineers. The success of the bottom-up sales strategy for selling software shows that there is a lot of money to be made by making it easy for engineers to buy.
(My startup spends more than $6k/year on a number of valuable services but I would not have selected the services initially if they required a sales conversation and upfront commitment. Even today, knowing I will spend more than $6k on these services in the next 12 months, as I have in the last 12, I would not commit to paying them $6k today. From my own experience, I'd estimate that that 75% of B2B software subscriptions are monthly, even when an annual plan (with an aggressive discount) is available.)
Tldraw is the best product in the space by far, and an obvious choice for any company building a product that needs a canvas, but your current pricing is a big gift to Excalidraw (and others). Every engineer is going to be thinking about forking over $6k in cash before they decide to run `npm install tldraw`. And unless tldraw is a choice being dictated to them, $6k is going to seem like a very big number they are going to have to justify. During my time as an engineer-employee, I had no defined budget: asking for $6k to be spent on something upfront would be very daunting (even compared to asking for a subscription that would amount to $6k/year).
Tldraw is the canvas SDK but that could change quickly if Excalidraw capitalize on your pricing. If Excalidraw is free to use, and Tldraw is $6k upfront, Tldraw will become the product people try after being disappointed by Excalidraw and convince themselves that Tldraw's superiority is worth an additional $6k spend. You go from being the default to the expensive alternative. Being the default is a golden goose, being an expensive alternative is an uphill battle.
As engineers we feel that because we can, we should, and that's why we want to validate numbers, we want a system that does everything and requires zero trust. And I believe that is likely influencing your thinking about self-serve. Yes, some customers will lie when going through self-serve to keep their bill low, but once Tldraw is integrated into their product, you have leverage to get them paying the right amount. Schedule an account review for every self-serve customer after 6 months. If they look like they might be underpaying, reach out, and get them paying the right amount. When the alternative is ripping out Tldraw, paying thousands of dollars more per year is an obvious choice to make.
If I were commercializing Tldraw, I would be selling it self-serve at $100 per month per developer. I would do away with the trial, and emphasize that the open-source version is free to use in development. I would expect customers to purchase once they are ready to go live in production. I would let customers declare their team size when purchasing. Every 6 months I would review subscriptions, reaching out if the numbers look off.
I would probably drop the 10 team size limit too, and instead make the business subscription more valuable to larger teams. If I have a team of 10 developers working on a product containing Tldraw then I am spending millions of dollars per year on their time. If I can save 1% of that time by having access to support from Tldraw's team, my team can spend their time on the parts of the product that matter. An extra $150 per month per developer ($250/month/developer) would be an obvious choice if it could save each developer a couple of hours per month.
Your product is fantastic and worth far more than $6k per year but getting $6k per year for it requires finesse, not just a decision that $6k is the right number. Anyway, I am just a person writing 500 words for free on HN so caveat emptor.
Completely agree. A manual sales process is a huge friction (per the CEO's comment above it takes more than 50% of startups over a week to buy tldraw!). And no visibility into scale pricing is a risk no company should take.
It's a great product - charge for it for sure - you need to be comercially viable. BUT, imho it's madness to make it so difficult to buy and have opaque pricing. It's a path to stagnant reliance on a handful of big customers while somebody innovates from under you and takes the market. Comfortable for a while, and then no business.
It's a great product - charge for it for sure - you need to be comercially viable. BUT, imho it's madness to make it so difficult to buy and have opaque pricing. It's a path to stagnant reliance on a handful of big customers while somebody innovates from under you and takes the market. Comfortable for a while, and then no business.
I agree $6k upfront for startups is a lot (especially if they're just riffing).
But the bigger issue is there's no clarity of what this will cost if the startup works out and grows. So you spend a bunch of dev time building something that uses TLdraw and then its completely unknown if you can keep using it in the future as the cost could be $1 or $1 billion.
Any startup would be crazy to depend on a service with unknown pricing.
Sure you can email them and get the pitch by a salesperson, and use a bunch of time to get some long legal agreement with pricing in it somewhere, but that's what you do for massive custom-built enterprise tools. Not for on SDK in your stack. I don't think the opaque pricing model is common or viable for this kind of SDK. Imagine if payments providers or authorization providers or hosting all just had blank pricing and a "talk to us" button.
But the bigger issue is there's no clarity of what this will cost if the startup works out and grows. So you spend a bunch of dev time building something that uses TLdraw and then its completely unknown if you can keep using it in the future as the cost could be $1 or $1 billion.
Any startup would be crazy to depend on a service with unknown pricing.
Sure you can email them and get the pitch by a salesperson, and use a bunch of time to get some long legal agreement with pricing in it somewhere, but that's what you do for massive custom-built enterprise tools. Not for on SDK in your stack. I don't think the opaque pricing model is common or viable for this kind of SDK. Imagine if payments providers or authorization providers or hosting all just had blank pricing and a "talk to us" button.
What will the cost be? I see it's $6,000 for a 10-person startup, but assuming a startup reaches scale, there's no information about what this will cost. Would be unwise to use this SDK as an integral feature without any kind of clarity on pricing. Some guidance would be helpful without needing to start setting up official calls with salespeople and going through some long discussion. Often, those sales pipelines don't even give pricing because the salesperson decides that the startup is not a good prospect. And thus back to the catch-22: we can't know the pricing until we're big.
If we want to stay in the older license?
Do we just do `npm i tldraw@3` and work from there?
You can stay on 3.x. The license on 3.x shows a watermark and a license key will hide it. New commercial licenses will still work for 3.x too, in case you’re unable to upgrade, though 4.x has only a few small breaking changes.
Wow, that is a pretty hefty license fee...
Peanuts if you build a business on top of the SDK.
When you have one already. How do you start building a business though?
Yeah, this is the current gap in the offering. Pricing is such whackamole. I expect we’ll offer extended free trials to teams that need longer to get off the ground.
1 year license for startups without funding
It might take years to get a business of the ground.
As a huge fan of the engineering wizardry that is tldraw... this is a really inflexible pricing model. But it’s not an easy solve, either.
If you charge by MAU, that’s the Unity licensing debacle all over again. If you charge by seat actively coding with tldraw - that might just be one seat at a massive funded company. If you offer monthly plans, that’s more BD/account management overhead to prevent churn.
But how do you keep the product usable by a broad community of hobbyists who still may want to commercialize to cover their costs and risks? Not everything can be bring-your-own-token, but if you’re merchant of record, you’re doing so as a commercial entity.
And on the monthly point - “hey boss I made a thing but you’ll have to allocate $6k upfront” is very different from “hey boss I made a thing and we can pay monthly until we validate the ROI.” (And someone might be wearing both hats!)
At minimum, a well-fleshed-out “pre-funding sub-X-revenue startup” program would go a long way towards continuing to build community confidence. Those are good leads to be getting, too!
If you charge by MAU, that’s the Unity licensing debacle all over again. If you charge by seat actively coding with tldraw - that might just be one seat at a massive funded company. If you offer monthly plans, that’s more BD/account management overhead to prevent churn.
But how do you keep the product usable by a broad community of hobbyists who still may want to commercialize to cover their costs and risks? Not everything can be bring-your-own-token, but if you’re merchant of record, you’re doing so as a commercial entity.
And on the monthly point - “hey boss I made a thing but you’ll have to allocate $6k upfront” is very different from “hey boss I made a thing and we can pay monthly until we validate the ROI.” (And someone might be wearing both hats!)
At minimum, a well-fleshed-out “pre-funding sub-X-revenue startup” program would go a long way towards continuing to build community confidence. Those are good leads to be getting, too!
It bugged me how this project was never fully open source but they promoted it like it was. It's good they are direct about it now.
I wonder what the imagined path to production for small projects is meant to be.
- for hobby projects: at what moment do you go from hobby to commercial license (and need $6k in cash)?
- for new businesses: you now either have a 90-day window to find product-market fit, or assume you'll have to burn $6k in the event of failure?
- for hobby projects: at what moment do you go from hobby to commercial license (and need $6k in cash)?
- for new businesses: you now either have a 90-day window to find product-market fit, or assume you'll have to burn $6k in the event of failure?
They aim at AI companies who currently are well funded and can easily carve out $500/m for an SDK.
[deleted]
I think we’ll do extended trials for small teams if they’re pre-revenue / pre-funding, and I can imagine setting up some relationships like that with incubators etc. A few other posters have asked the same question and it’s a good one, thanks.
Here to say that I have been working on a canvas-based app for a while now. Canvas apps are hard y'all!
I greatly appreciate tldraw and think the licensing changes are completely reasonable. The team is highly responsive on Discord, and looking forward to the company nailing down the nuances of pricing out this specific business model.
Pricing is difficult as it is, open source pricing double so, open source canvas library pricing has got to be one helluva hard problem to solve.
I would like to see more improvements to the sync portion, specifically more granular authorization controls.
I greatly appreciate tldraw and think the licensing changes are completely reasonable. The team is highly responsive on Discord, and looking forward to the company nailing down the nuances of pricing out this specific business model.
Pricing is difficult as it is, open source pricing double so, open source canvas library pricing has got to be one helluva hard problem to solve.
I would like to see more improvements to the sync portion, specifically more granular authorization controls.
Thanks! Granular permissions are a common feature request, especially in education, so there’s a good chance we work on that this quarter.
The $500/m plan seems pretty excessive. I expect an alternative to pop up soon and hope such greed won't capture those devs.
Glad I only just started using tldraw weeks ago, time to move away.
Glad I only just started using tldraw weeks ago, time to move away.
[deleted]
Great project!
If I may ask - how do you guys compare with React Flow?
BTW - licensing looks fair, hope the effort that has been put into this project pays off!
Hey, thanks! React Flow is more narrowly focused on flow charts and workflows. It’s also MIT licensed and much more popular (looking at NPM installs) and sells premium access to docs and examples, while we license the library directly. Our canvas is more broadly capable, with a default feature set closer to Excalidraw, except that we use React / DOM for the entire canvas, like React Flow does. We also have a very different way of managing the canvas data, closer to a game engine than a controlled React component. I should write some blog posts.
Two of the starter kits we released today are more flowcharty. It’s been possible to make this kind of thing with tldraw for about 18 months, since we made our bindings API, and a few teams have built graph UIs on tldraw already, but I wouldn’t say it’s an easy path. Hopefully these starter kits will make it easier to uh start.
Two of the starter kits we released today are more flowcharty. It’s been possible to make this kind of thing with tldraw for about 18 months, since we made our bindings API, and a few teams have built graph UIs on tldraw already, but I wouldn’t say it’s an easy path. Hopefully these starter kits will make it easier to uh start.
We use tldraw for playing D&D, yesterday it went down and locked our tldraw document forcing us to create an account, but when we made an account it just gave us an error. When I go to tldraw today and try and make a new document it still gives me "An unexpected error occoured".
Want to email me [email protected]? We're looking at an issue with new accounts today on tldraw.com but it sounds different from what you're describing.
For anyone who wants to write a best selling book:
"The OSS* Playbook: Turning Free Users into Engineers and back into Paying Users"
This now sounds like the best way to scale adoption heading into 2026.
Sidenote: Payload spending years setting themselves up for a Vercel acquisition only to be acquired by Figma is still my surprise OSS of the year.
"The OSS* Playbook: Turning Free Users into Engineers and back into Paying Users"
This now sounds like the best way to scale adoption heading into 2026.
Sidenote: Payload spending years setting themselves up for a Vercel acquisition only to be acquired by Figma is still my surprise OSS of the year.
[deleted]
I just signed up to the tldraw cloud and lost all the files from browser storage :'(
k thx bye. have fun with the money.
About three years ago, we integrated tldraw into BigBlueButton as our whiteboard. It’s been an excellent upgrade over our old, simple whiteboard — tldraw is a fantastic project.
I'm also the CEO of Blindside Networks, the commercial company behind BigBlueButton. We have growing by the traditional open source business model: we offer hosting, engineering services for acceleration of features, and support contracts.
I understand the motive behind tldraw's change of license. Open source projects often get asked two contradictory questions: 1. Can I use your work for free? 2. Can you guarantee that you’ll be around in 5 years?
You can’t answer (1) without a solid plan for (2). Licensing changes are one way projects try to answer both of these questions.
We are no stranger to license changes, we recently rewrote the entire back-end of BigBlueButton and moved away from mongoDB to PostgreSQL + Hasura.
For us, moving to tldraw 4.0 would mean:
- As Blindside (the company): buying a commercial license — that’s straightforward as we are also a commercial company. - As BigBlueButton (the open source project): it would require every organization running BigBlueButton to obtain its own license key to tldraw.
There are pros and cons here. We want a world-class whiteboard in tldraw based on a sustainable open source project, but we also want to keep BigBlueButton’s community deployment model simple.
Curious how others in the HN community have handled integrating source-available components into open source projects. How do you balance sustainability with accessibility?