S01E05 Tauri - Daniel Thompson-Yvetot

Welcome to the NGI Zero podcast where we talk to the people who are building the Next Generation

Internet.

I'm Ronny Lam.

And I'm Tessel Renzenbrink.

We're both from NLnet, a foundation which supports people who are working on a free

and open internet.

Our guest today is Daniel Thompson-Yvetot.

He's the co-founder of Tauri Apps, CEO of CrabNebula and an NGI evangelist.

Daniel is involved in multiple projects that have received NGI Zero funding.

Tauri, a toolkit that helps developers make smaller, faster and more secure desktop applications.

And more recently he's been working on Servo and Verso.

Servo is a browser engine written in Rust and Verso is a new browser initiative built

on top of it.

Hi Daniel.

Nice to have you here.

Hi, yeah, thanks.

It's a pleasure to be speaking with you on the podcast.

I don't think we've seen each other since FOSDEM back in February.

Yes indeed, yeah.

Did we miss anything in our introduction of you?

Oh gosh, I mean, I think there's a lot to unpack there.

So I hope we have enough time to get to it all.

All right, so to introduce you even further, we have devised three short questions which

you can answer with short answers.

The first one is, are you programming rather in silence or with a background noise?

If you consider the background noise of a circulating fan to be useful, then I would.

Although I do have a collection of playlists that a producer friend of mine has been making

for the past 15 years and sometimes I'll go and listen to music as well.

But I find for very concentrated work that silence is the best.

I think a fan is sort of white noise, right?

That probably helps really well concentrating.

Okay, the next one is, we'll get back to that later, but just quickly.

Do you prefer a benevolent dictator for life or interrelatedness?

Interrelatedness every week.

And which web experience did you enjoy more, the one of the 2000s or today's web experience?

Oh gosh, no, I'm going to go back to the 80s.

I really loved feeling like I was in the future by putting our phone, our landline onto a

physical modem, connecting my Commodore 64 to a BBS.

For me, I felt like it was the space age.

I think it's gone downhill since then.

That's a very insightful answer.

Thank you for that.

So talking about your projects, what are the key issues you see with the state of the internet today?

It's not built for us.

I think the biggest issue and why I love NGI's mission so much is that we've kind of grandfathered

into an internet designed for autocrats and corporations such that we are products for them.

And I guess the biggest campaign I'm on today that kind of touches all of the projects I'm involved in

is working toward redefining what it means to have a digital identity.

I don't mean, you know, to log into your bank or to pay your Amazon with your credit card or to even vote if that were possible.

I think that today, more so than ever, we're spending so much of our lives online in forums,

communicating with each other, that our digital identity is almost like a digital presence.

And I don't feel that corporations like Alphabet, Meta, Apple, Microsoft, NVIDIA

are interested in providing us with tools that help us understand ourselves better.

And so I think that that is the biggest problem that we're facing today.

It's the problem of disenfranchisement. It's the problem of facing chilling effects when we speak out.

It's the problem of being doxed. It's the problem of being a customer before you're a person.

I mean, if you go to a government office, you take a number because you're a customer.

And I feel like the way in which the digital has evolved has been, unfortunately,

not what we were promised back in the 90s. I think what it's evolved into is a panopticon of fear and powerlessness.

And I know that open source can and should and must play a part in returning that power to the individual.

And we are even raising our kids into it.

Yeah, we are. I mean, before they know how to walk on the sidewalk, they're already playing video games on iPhones.

Yeah, I mean, well, this is a whole other discussion, I think. But the first word my son said was YouTube.

My daughter went back in 2002. She, well, I guess this was 2004.

One of her first words was Kika, which is the Kinderkanal in Germany.

And because they're on the remote control for the TV, there was a logo that was the logo of the children's channel that she loved watching.

I think that the children adapt very quickly to the surroundings they're given.

And I'm saddened by what's happened to the way in which the digital native generation is grown up understanding that, well, this is the way things are.

And this is how they've always been in my life. So that's what they have to be.

But taking it back to your projects, how does your project contribute to addressing those issues?

Well, I guess if we started with the Tauri project, Tauri began as an experiment to consider what it would mean to build apps, software that respected the individual's computing resources.

It came at a time when, and I think to some extent this still exists, but it came at a time when the Silicon Valley tech bros and VCs and big startups and scale ups and venture funded projects felt like it's all free real estate.

The computer, that's ours to use, and that's how we're going to get customers. And again, it comes back to this notion of the person is the product.

And we felt that why doesn't application have to weigh in at 300, 400, 500 megabytes? Why are applications shipping an entire browser and runtime?

We can do better than that. And I think that the initial experiments are still vastly proven in the Tauri ecosystem because today a very basic application is four megabytes.

And it does everything that a more complicated or heavier weight application would do.

And I think the fallacy of scale that is promoted by large cloud companies and cloud computing in general is, hey, there's enough computing space for everybody.

We'll make more if you need it. You just have to pay us.

The thing is, if your app is only downloaded 100 times, nobody cares how big it is if they stay in the United States.

If your app is downloaded millions of times around the planet, you have to start considering things like people having poor connectivity or having to pay per megabyte.

And if your app is updated regularly, three or four times a month, like good developers want to do, that means that you're incurring an amazingly huge tech, transit, electricity, power, consumption that doesn't need to be there.

And I mean, just back of the envelope calculations show that reducing the download size of your app, if you're a popular application, can have massive impact on your bottom line and also the bottom line of the people using your app.

And I think that what this has led to, this notion of smaller is better, is also the discovery we made along the way that smaller is also more secure.

And more secure means that we are working toward promoting these universal human digital rights of sense and notion of privacy and security on your computing devices.

I think that what's come out of Tauri itself was in the first place, this desire.

And maybe for this one user that doesn't know what Tauri is, can you give a high level overview of Tauri?

Sure. So Tauri is a framework for building applications that use web technologies on the user interface and the Rust programming language on the backend or the core.

And this allows people to do is quickly make a beautiful, engaging interface using technologies they know, like React or Vue.js or Solid.js and create applications that are incredibly small and performant.

Obviously, there's a lot more detail in designing a mobile app, designing a desktop app and shipping those applications.

But we've worked on making the developer experience one that smart people can figure out and beginners can rapidly become proficient in.

So the technology that's used, though, is different on each platform.

And this is sort of the bridge to the Verso and Servo projects.

And that is the operating systems provide what's known as a web view.

You can think of it like a slimmed down web browser like Chrome or Edge or Firefox that allows applications to show web content.

And in Tauri's case, we deliver that web content generally.

The problem arises, though, once you start looking under the hood.

So on on Mac OS, we're using a web view that's based on the Safari browser that gets updated when you update Safari with all of the problems that brings. On Windows

it is the Edge browser's WebView 2 that similarly is controlled by Microsoft and Google to some extent.

And on Linux, we're using a project from Igalia and contributors called WebKit GTK.

And what we end up with is, even with the greatest of intentions, a fractured ecosystem.

Because each of these WebView vendors feels like they're doing what they need to do for their platform.

And we don't have parity.

So one of the first engagements with NGI was a collaboration between the Servo team and the Tauri team to look into what it would take to use Servo, the engine, as a provider of a WebView for Tauri.

Because, as you might know, Servo, the project started from Mozilla years ago, has a Rust basis for the most part.

And since Rust as a programming language is considered to be one of the more secure and memory safe programming languages out there, it just makes sense because, you know, Tauri is written that way, too.

It's it's all in the same context.

And the experiment was actually successful.

We were able to prove a concept and then things get sticky.

Making a WebView on a browser engine makes it hard to test that browser engine.

Technically, you want to have a browser and base the WebView on the browser.

So with the Verso project, we've started using the Servo engine and we are contributing to the Servo engine as well.

But we've started using the Servo engine to, on the one hand, build out the browser and the WebView so that we can own and support the entire stack of what's needed for Tauri Apps.

Right.

It's a massive undertaking, but we feel that the decisions we get to make while building a browser and its associated WebView help us align our community's vision toward what a browser should be without the involvement of corporate interests.

I think that keeping it in a community area, similar to what Ladybird is doing, is going to be important for the project going forward.

So do I understand correctly that if this project continues and reaches that point, which you would like to reach, that you can provide the apps on, say, a Mac or a Windows machine.

Without having to need their web kits.

Correct.

That's absolutely correct.

But that is quite revolutionary because then you get a part of that autonomy back that you discussed in the introduction that got lost.

So really amazing.

It gets deeper, though.

If you follow the W3C and the WTG, what you discover is that while standards are important, they only serve us as people to the extent with which manufacturers agree that a standard is helpful.

I can list dozens of cases of this, but I think the interesting one is to look at how the market adoption, the use of Chrome and Chromium in the industry means that the decision makers of the Chrome and Chromium projects are actually literally in a position to do things like turn off third party cookies.

You can agree with cookies or not, but making a decision for the ecosystem based on an approach that is valuable to a corporation thinks it's really scary.

I mean, in Chrome, did you know that they're already integrating Gemini, the LLM?

Can you opt out of it?

Well, maybe, but also maybe not.

And for how long?

And for how long?

And at what point is it so transparent and expected that the next generation of children, my daughter's children, are going to grow up expecting that there is an agent in every single piece of software that knows them intimately and they have no expectation of privacy?

Is that the kind of world that we want to have enshittyfied for us and for future generations?

I hope not.

And that's what we're working against.

Wow.

This gives me a reminder of the thought police.

But I don't know why.

Double goods, right?

Yeah.

The fact that Tauri is working together with Servo, and it shows that you are really with Tauri, you're really used to or doing a good job in reaching out to a wider ecosystem and collaborating successfully together.

But I get the impression that you, that Tauri, the Tauri team is more generally quite good at reaching out to a much wider ecosystem and collaborating on that.

Can you say some things?

Oh, I have thoughts.

So for the statistics, I don't know when this podcast is going to be presented, but at the time of recording, Tauri has something like 80,000 stars on GitHub, which puts it into the top 100 most starred projects on GitHub and the top 50 software projects on GitHub and number three in the Rust programming.

I think that the reason for this has a couple layers.

For one, we believe in agnosis.

We think that your stack is okay, and we want to help you make better software.

We also have a working group policy that tries really hard to not only stay inclusive, but also accountable.

And this is done through an organization I'm sure you're familiar with, with the Commons Conservancy.

So the Tauri program within the Commons Conservancy is an elected board of directors who exist to make sure that the moral stewardship of the open source project cannot be rug pulled.

The directors are elected by the working group to become a director.

You have to have been in the working group to join the working group.

You have to have committed some code and you have to ask to join.

I think the moment you join, you get right access to all of the repos on GitHub.

And that means as a contributor, you don't have to fork.

You can just branch, which enhances our trust.

However, we still have administrative policies in place such that every pull request needs a reviewer.

And just because it's on the main branch doesn't mean that a release gets cut.

So we have a multi-layered approach toward empowering individuals to participate in the project,

while we also maintain human review and control of the system in a way that is not like the Benevolent Dictator for Life model,

but more in line with a healthy ecosystem that recognizes that sometimes contributors need to take a break.

Sometimes they need to travel the world or get a job or become parents.

And it's the kind of resilience that our team has that actually makes this not only feasible,

but also quite possible for the contributors to join us.

And the topic that sort of grinds me a little bit though, is that I don't know who all is using Tauri.

I think that if we'd taken a slightly different path, if we'd taken the proprietary path,

the license this code based path, we would know exactly who the customers are.

But if you remember what I was saying earlier, I don't believe in open source customers.

I believe in participants. And I believe that it's every participant's right to come forward and say,

yes, we love Tauri, or we're using it this way.

If it's an open source project, then it's right there in the code.

You can go and look at the dependency tree and see that they're using Tauri or Tau or Wry

or any of the other hundred projects that we manage at Tauri organization.

But what grinds me is that for profit projects using Tauri aren't disclosing the fact that they're using Tauri

or in many cases, the hundreds, if not thousands of other open source projects that they are building their success on.

Now, I am not about to go out and start legal battles with people because I don't feel that any of that is productive.

However, this is also something that's going to kind of go away.

Once we have the Cyber Resilience Act, once we have the compliance requirements of maintaining a Software Bill of Materials,

once companies start to realize they need to actually work with the open source communities in order to make sure that the risk they're adopting with using the open source project is not just theirs alone.

I think that we're at a watershed moment for open source and I'm very excited about it.

I'm bullish about the raft of regulations in Europe and how they're actually going to support open source maintainers, creators and companies that make open source.

I think that for too long, it's been this wild west of free real estate and I see those days coming to an end.

That's really interesting. Can you expand a bit on how the Cyber Resilience Act would help make open source more visible as one of the things that you would like to see, but also how it would help maintainers?

Oh gosh, yes. So the Cyber Resilience Act has the task or the goal of enforcing compliance on the manufacturers of products with digital elements that are placed on the European single market in the context of the Blue Guide.

The Blue Guide is basically this several hundred page document that explains what it means to be a manufacturer and create products and what kinds of things you're going to have to do in order to comply with the expectations of the regulator.

So that aside, what the Cyber Resilience Act and its associated Product Liability Directive do is for the first time, they literally classify software as a product, which sounds novel, but basically you have to understand that the Certification European, the CE mark that is placed on every physical object,

with digital elements like your, I don't know, your USB charger, your mouse, your keyboard, your laptop, they all have this little CE mark on there. Software is going to have to carry the same mark as well.

And it's not just software that you're downloading, it's also going to be SAAS offerings, many types of websites, Internet of Things, and the regime expects a couple things.

So the first is that a software product for its lifecycle maintains a Software Bill of Materials, it maintains a user handbook of what they can expect, how they should use the software, etc.

For a minimum of five years, potentially, in some cases, it could be longer if your product is designed to live longer.

And you also have to report to your local cybersecurity center, your NOC, if your software or your product, in this case your product,

successfully attacked by hackers, there's a very stringent reporting period and expectations that you not only tell the public, but that you also tell the regulator.

And this is what's going to happen. In the case of an event, the regulator is going to be, okay, thank you for the report, I want to see your Software Bill of Materials now.

And in the Software Bill of Materials, that doesn't have to be held publicly, but it will be kept transparent for the regulator, they're going to see all of the hundreds and, like I said before, thousands of third party software modules, the majority of which, let's be honest, are open source projects, the majority of those projects are run by small teams of,

I'll just call them maintainers, I'll get back to the term in a second.

And then the liability and risk equations start happening, because if it's not your fault that a third party library was hacked, then is it the third party library's fault?

And how do you mitigate that risk from the beginning? I mean, it's a common trope in the security industry that ain't nobody got time to read through a thousand third party modules, a third of which update themselves every week and stay on top of the security posture of every single third party dependency.

It's actually something that some companies offer as a service, and the utility of that to the side, before it comes to a cyber attack, companies are going to be looking at their risk portfolio and working toward mitigating it.

And one of the best ways to mitigate it is to support the maintainers, they're going to find out that calculation very quickly.

They've been freeloading on the maintenance of open source software for decades, and now they're finally going to have the opportunity to do the right thing, participate in corporate social responsibility, support the people whose work they're instrumentalizing, and doing it in a way that benefits their entity.

I think that that is going to happen. And now you might recognize, earlier I said, placing software or software components on the single market.

Technically, whether you sell it or not, if you're putting it on the market, if you're giving it away, you're still putting it on the market.

And the regulator was challenged by some amazing foundations out there. I'm not going to pick names, except for the Linux Foundation, who we're thankful for their diligence.

But there were others involved, I believe, even at NGI Labs, a friend spent a year in being involved in the discussions around the extent to which open source projects are going to have to comply with the Cyber Resilience Act.

And we got some amazing news. Basically, if you're a drive-by contributor, you just have an itch you want to scratch, and you contribute some kind of fix to some open source project, and you have no financial involvement in the project at all, you're fine.

You're not going to be implicated in any requirements of the Cyber Resilience Act.

Even if you're just a bunch of friends who make this as a side thing, and people aren't getting paid, it's a hobby, you're not going to be required to comply with the Cyber Resilience Act.

And even entities like the Linux Foundation are not going to have to comply with every single one of the requirements of the Cyber Resilience Act.

Because they're going to be classified as open source software stewards.

And a steward is going to be, I think there's a lot of work to be done,

but the expectation is that the steward reports to the regulator how their security posture is maintained, and they have to maintain a best effort.

And then you have commercial open source software companies.

And this is kind of where I think things get a little sticky.

So if you're a company and you make an open source software library available to the public, you are going to have to certify that library with the CE mark.

Which means you're going to have to maintain a register of all of your compliance documentation.

And in some cases, you might even be expected to get a third party auditor to come in to verify compliance.

And that, I think, is the larger risk that I see in the Cyber Resilience Act for open source.

And it might be a double edged sword, because there are many recent examples of corporations changing the license of their key product right before doing a funding round or going public as a way to bolster their valuation.

And I think that companies who have that strategy in mind or are not taking it off the table early on are going to quickly find out that the liability they're going to owe to other people using that software is going to be literally too much for them to manage.

And we're going to see less innovation from corporate contributors to open source.

That was a lot.

Yeah, it was a lot.

And well, I hear two things in what you say.

One is it sounds like you are very happy with the CRA.

But the question I also have is, isn't it hard to be in open source now?

I don't think it's ever been easy.

I think open source attracts a very unique type of person who believes in collaboration,

who believes in the greater good, and who is also in some sense altruistic.

I think that altruists or purported altruists get a bad rap because I think in the modern world, if you don't have healthy self-interest,

it's easy for you to be taken advantage of.

And I think that in the space of open source contributors, there is a tendency for people to land on one side or the other of neurodivergence.

And when you are on that spectrum, it's easy for you to participate in a very, I guess it's not very rare, but it's a type of involvement in open source where you try to keep up with the things that other people are doing and you burn yourself out.

I think the biggest risk to open source maintainership isn't the lack of funding.

I know people are going to yell at me for saying this, but funding is not going to solve the mental health crisis in software engineering.

The only thing that's going to solve that is more compassion, more collaboration, more attention to the people that you spend time with.

Because when you work remotely

on open source

you might not ever

even see

the person

in the real world.

Ever.

The only thing we have to go on are these signals and cues.

And being compassionate is the reason why I think we deserve a chance as humanity.

I think

we can be

compassionate.

I think we can find ways to resolve conflicts.

I'm not saying I'm a pacifist, but I'm also not a warmonger.

And I know this isn't exactly

the answer to the question you were asking.

But there's never been a better time

to get into open source.

There's never been a better time to learn more about people and customs and countries and languages.

I think that if we have a chance as humanity to figure out what this crazy world is doing to us,

then it's by direct engagement.

And I see more directly engaged people in the open source communities than I do in the corporate boards.

Well, yeah, these are all beautiful words.

I think it's really, really nice also for other open source developers to hear this, you know,

that compassion is important, but also that they're really contributing to the world.

So I think it's a really good speech that you just gave.

And I'm still wondering about that one question I asked earlier,

because you say justly that the corporate world has been freeloading on the backs of open source for a really long time.

And you say that you think that we are now at a point where this might change,

where they have to start to acknowledge open source.

And what do you think that will look like?

What will change for open source developers?

I think there's two ways to look at this.

So from the corporate side, your goal is to at all costs reduce risk.

Liability is the worst thing, especially because sometimes it's incalculable.

You might know it exists, but you don't know exactly what the damage it is that it can cause.

And so today, under today's model, if you're a company that's not open source,

if you're a company that's using open source software and you get hacked,

then maybe it was the fault of an improperly coded third party node module,

but it's still your fault. You did not do your due diligence.

You did not. I'm just going to throw this out there.

Ninety nine times out of a hundred. You did not engage with the open source community.

Your dev probably just did a quick Google search or what's hot on Twitter,

and then NPM installed it and went from there.

And there's never been an honest code review inside your product because nobody has time for that.

No time has been made for that.

And so from that perspective, from the perspective of the corporate interest,

what we're going to have to see is an increased cyber resilience budget

where teams are going to be created to analyze and verify continuously, if need be,

the security posture of the company, including its third party modules.

And that is a Herculean task.

And so in order to offload the risk, what those entities can do is they can pay people to take on the risk.

They could pay people to take on the risk.

They could pay an open source team to say, hey, you know, here's a bunch of money.

Please make sure that your code is updated, that your dependencies are up to date,

or they could pay for third party audits of the really integral stuff.

This is going to have an impact on the security industry.

This is going to require the education and training of hundreds of thousands of people to do this.

And yes, of course, there are LLMs for that.

But still, we need a human in the loop to make sure that the LLM did its job right.

I don't think we're going to get out of this quick and dirty by paying a company to investigate our vulnerabilities.

It's something that we still are going to have to do at least for the next five, six years.

I don't think that this is going to change any sooner than that.

And that kind of describes then the position that an open source project is in.

So if we take the model of Tauri, Tauri is a program within the Commons Conservancy that doesn't take money.

We have a donation channel over at the Open Collective where people could donate money.

But we take donations in the strict definition of the term that you don't get anything for a donation.

Which means, conversely, you can't hire the so-called Tauri team to verify the security of your implementation of it.

This has a couple roll-on effects.

Now, because the Tauri project is within a Dutch foundation,

that means that Tauri will be seen, or the organization, will be seen as a steward with limited responsibilities,

but also not the ability to place a CE mark on the Tauri code base.

That means everyone who's doing it is doing it, A, either on good faith, or B, blindly.

And I guess those two are kind of the same.

Unless they, and here's the hook, and this is maybe why I'm excited with this model,

unless there's a company, like in Tauri's case, CrabNebula, that is able to say,

You know what? We actually perform security audits on every pull request leading into a minor release.

We manage the third-party audit at major release.

We even file CWEs and GHSAs when required, because it's in our DNA.

As a company, we support the open source project that way,

and since we do that, we actually could sell you the risk.

We could put a CE mark on Tauri and say,

If you want to have us absorb your risk, well, pay us for the work that we're doing to support Tauri.

And I think that that's kind of the interesting niche, open source collaboration between a foundation

and a for-profit entity that is going to make a lot of sense for companies out there

that are looking to reduce their risk.

Because if the Tauri app gets hacked, the regulator is going to dig through and figure out,

Okay, who is responsible for this?

And if it was Tauri, then it's Tauri's job to fix it.

It's not your job as a consumer.

If you play with this Cyber Resilience Act, I don't know.

I hope I answered your question.

I think that the risks and challenges and opportunities are out there.

I'm kind of content with the way we designed and grew and nurtured our open source community

and built a company to support that community because it seems to me right now

that the way in which the CRA and the PLD are conceived,

they're conceived by morally well-founded companies trying to do the right thing

for the right reasons in the right way.

And I'm not trying to claim this from my perspective.

This is what I'm hearing from our consumers, from the users of Tauri,

from our customers at CrabNebula.

And that is they're proud of us.

And they see us as a role model.

And again, if you're listening to this podcast out there,

I really welcome you to reach out to me.

I'm always happy to learn about open source projects,

whether or not they're using Tauri or Servo or anything.

I just love helping people get off on the right foot or solve tricky problems.

So I'm there for you.

That's amazing.

Yeah.

This is a nice bridge into another subject that we want to touch.

What does it take to make a software company

or an open source product sustainable?

Because, yeah, I mean, once in a while we see nice products,

but then they don't get maintained or, well, whatever.

And hearing from you, it sounds like you have a model to make this sustainable.

I think it, like everything in life, really depends.

So when we built Tauri in the beginning,

we were trying to solve our own problem.

As time went on, we recognized that people consistently bumped into similar problems.

And that is how we designed the niche for CrabNebula.

And that is through the cloud distribution

and managed compliance parts of the things that people hate to do.

Nobody wants to go and get a code signing certificate.

Nobody wants to spend 12 hours debugging CI, 12 hours if you're lucky, sometimes weeks.

And so by reducing the barrier to entry,

we are offering a value added service that many people in the community can,

will and do enjoy such that we are ultimately complementing the vision of Tauri,

which is to make software more accessible and better and more cost efficient

and more energy efficient.

Being able to have a corporate vision that aligns with the open source project is absolutely essential.

I think we were also lucky to raise money as a company

before the interest rates in the US rose to the extent that they have and are stuck at.

I have also an entire talk that I gave at the Merge Conference in Berlin

about designing open source for resilience.

And in the context of that, starting a company isn't something everybody is cut out to do.

Sometimes it's good enough when this is something you just build for a couple friends.

And I guess the thing you have to do is know yourself.

If you don't know who you are as a person, then don't start a company.

Just don't.

If you don't know what open source means, join a project and find out.

If you are in a position to think about your life,

apply for an NGI grant, get some funding, work on a project that's meaningful to you,

and you can always decide later that you want to start a company or not.

I wouldn't ever rush into building a company on the back of open source software.

I think that's a decision that, first of all, you should never take alone.

And second of all, one that needs to have you in the right headspace.

So you're saying the company is more the result of the project rather than the starting point?

Yeah, it really is.

I think if you were to go to the Tauri community and say,

hey, Tauri community, can somebody build me a plugin for Tauri mobile?

The Tauri community would be like, well, how?

We can't write invoices.

We can take donations, but we can't charge you for something.

And furthermore, how do you guarantee the availability of a volunteer?

Like, none of that stuff makes any sense.

And if there is a desire for things like corporate services,

maybe someone in that working group of that open source project should get a tax ID

and freelance and see if there's really a market there.

And I think that a common, actually more common than a lot of us would like to admit,

a common thing is that companies will send an engineer to the Tauri Discord and ask questions,

but then they can't show the code because it's proprietary.

And in that moment where you have an entity like in our case, CrabNebula,

or someone in the working group who's willing to sign NDAs,

you can actually sign an NDA and give a corporate customer the ability to talk to you.

And I just can't emphasize it enough, like getting a bug report

and then not being able to replicate it because OP said,

this is corporate, it's proprietary, I can't share it with you.

That is probably the most demotivating conversation ever,

because someone from the community wants to help someone else from the community,

but that other person from the community who needs the help

isn't in a position to explain what their problem is.

So what you end up doing is you kind of guess and you poke around

and it just wastes everybody's time.

So I think that for engagement with other businesses,

if that's what your path takes you on, then set up a company.

If you're a true and pure altruist who really only wants to do something good,

then quit your job after you get a successful grant through the NGI program

and try that out for a while, see how that feels.

See how it feels to actually, and it's not great for everybody,

but see how it feels for you to take money as a donation

for being a member of the open community.

And then maybe you'll know more about what you want to do with the project afterwards.

Well, this sounds like amazing advice and also this NGI funding

is really helpful to start in becoming an open source developer

and trying to finding out if it is for you indeed.

What advice would you give to people who consider applying for an NGI fund?

You know, last, gosh, I think it was November.

There was an NGI event held in Brussels and we had a workshop at the end of the day

and somebody spoke up and said, how can we tell Europe what's important to us?

And my response, you know, I'm sorry that you folks at NLnet have to hear this

and go through this, but my response is, on the one hand,

my response is apply for more money.

Spend all of their money as fast as possible so that we can prove

that there is a need for open source in Europe, in the world,

that we can show that Europe is a guiding light for community building

and contributing to the commons.

And I guess my advice is to go to the NGI.eu website

and look at the various programs that exist,

be prepared for an application to flow quite easily

as compared to other Horizon projects.

I can confirm that the work involved in applying for a cascade type NGI grant

is much, much lower than a lot of the other grant applications

you might have heard of.

Nevertheless, be prepared for it to last three, four, five months

until you get confirmation of the grant happening.

And whatever you do, don't make decisions for your life

based on the potentiality of getting a grant.

This is coming back to my advice to everybody to maintain your mental health.

Don't think just because you applied for a grant

that you're going to get the grant.

Sometimes you have to do follow-up.

Sometimes you have to be prepared to hear no.

And I think as a final word, this is something that is true

no matter what you're doing.

Imagine that the person reading your application for a grant,

just like reading your application for a CFP at a conference,

just like somebody looking at your CV for a job,

give them as much information as you can.

Make it clear what you want to do, what the impact is,

who you're going to be working with,

how much time you think it's going to take,

what you expect to happen as a follow-on step,

what other communities and organizations

and even funding you'll be working with.

That is some great advice.

And for me, that's the end of the questions.

I don't know about you, Ronny.

It was amazing.

We had a great conversation.

This really was insightful into the Tauri project,

into Servo, and into open source and companies.

I would like to thank you very much for this.

It was my pleasure. Thanks for having me.

Is there anything you would still like to add that we missed maybe?

Don't be afraid to reach out to people in open source.

I think the easiest way to start contributing to open source

is to look at projects you like,

give them a star and help out in the documentation

and get to realize that there's real people behind these projects.

And just remember to be friendly.

I think that's the best advice I can give.

That's good advice to just about anybody.

Remember to be friendly.

Thank you, Daniel, for taking the time to talk to us.

It was really insightful.

It was my pleasure.

Thank you.