Your open source project can pay your bills: Here’s how

This talk discusses how open source projects can generate revenue, focusing on the experiences of the speakers from excite, a company that provides commercial support for Isarichs, a communication library for safety-critical systems. The speakers emphasize the importance of demonstrating both the technical and business value of an open source project to potential customers, particularly large companies. They share strategies for attracting clients, including building a community, writing informative blog posts, and leveraging conferences for exposure. The discussion also covers various business models like open core, dual licensing, and support and consulting services, as well as the challenges and pitfalls encountered in these approaches. Throughout the presentation, the speakers stress the need for clear communication and the development of a sustainable business model that aligns with customer needs while also advocating for mental health awareness among maintainers.

[music] >> Hello everybody. Welcome to our talk. Your open source project can pay your bills. >> [laughter] >> One second. So your open source project can pay your bills. My name is Jessica. This is Christian. And we are both from excite. We are located in Berlin and we are the company behind Kips Isarichs. We were founded to provide commercial support for Isarichs and also Isarichs 2. And

Isarichs is a communication library for safety critical systems. For example, autonomous driving, robotics, human robotics, and so on. We were founded 2 years ago. And so we will share with you some experiences we've made over the last 2 years. Some good decisions we made up front. Maybe some pitfalls we experienced and hopefully you can learn some of it. So let's start with an ugly truth. Companies will

not sponsor your open source project unless you make them do This sounds a little bit harsh, isn't it? But from our experience, this is quite Also big companies are somehow not willing to pay for your services or your project or at least not the efficient amount in comparison to what you put effort in it. So you have to give them you have to give them a good

reason for Just to make things clear, for whom is this talk? We are speaking to the maintainers, to the developers who believe in their open source project and want to be able to work full-time on it. So as I said, you have to give them, so potential customers, a good reason. Most of the time we see the technical value of an open source project. It's obvious, right?

This is what the project shows. to convince customers, you have to get a little deeper. You have to show also the business value, what companies actually care also about. And you have to communicate this business value really, really clear. So, as you can see for example, here are some business values. It depends what customer you are targeting and what your open source project is about. Maybe your

potential customer is uh caring about the security and reliability aspect of your project. Maybe they get market access to uh thanks to your open source project. It depends what you are offering and what is your target customer. So, just to be clear, the tech value is really reasonable. The features, the extensions, the tooling, everything about your open source project. But you have to have um a little

more explanation and shift the focus to what is the customer now able to do thanks to your open source project. Maybe the customer is now able to shorten his development cycle. Or they can differentiate on their market for their customers. It's all about communication and setting the right focus. So, now we get more into the details and Christian will tell you something about the technical stuff. Exactly.

So, the idea is we present here always both sides, let's say the business side and the technical side from a developer point of view, where we often do not take care too much into the considerations of business in the end. And here we want to bring both words together. The first thing is how we got customers. To make money you need customers first. And uh what kind

of experiences we made with these four different scenes in the end. Uh it began in the end with let's say community and fans. We open-sourced in 2019. We were at this that time employed by Bosch. It was a Bosch open-source And internally we had our internal customers which we collaborated with, but also the open-source we had already some customers from interesting uh let's say companies and areas

which we did not suspect before because we were targeting clearly automotive customers, but then high-frequency traders act somehow discovered us. And what we did is we worked together with the community. If there was a feature request or bug fix which which seemed urgently, we tried to fix it in a reasonable manner. And at some point they realized if I have a problem in this area, not especially

this project, but in this area, and I post here something, I get at least some kind of reasonable explanation what to do and so on. And therefore fans developed and these fans in companies required sometimes urgent help. And with this we had a support contract and then we can put a reference instance also go to long-term contracts and so on. So therefore this was one of the

first pillars we had to gain new customers. The other thing is whenever we create a new release, we write some blog articles, not only shining all the new features which were in there, but we also take uh look especially in the problems users will have or will observe and how in general they can be solved and also hint to our open-source library as one possible option for

instance. And with this we got some traction on Reddit, some conversations started and then you have usually this oh I have this project, could I apply to this your project to my project? And they They the source code, played around with this, find it that this was a great project and then again we got some customers and some traction there. Also conferences were helpful, but not for

customers, but just to get the word out that we have an exciting project which solves communication problems and so on and then the word was out there and then we got some traction there, too. Another thing is uh the Eclipse project has also the STV area. It's a like meta open source project where multiple open source projects come together, work together on a common vision. Here the

problem is that uh one thing is lacking is the business case. Also especially for smaller companies, which is not there. This makes it hard to collaborate where the idea is everyone comes together, collaborates code, but the question is who pays the developers? How can you make a sustainable business out of it uh as a small company? And then you had also, let's say, political discussions in there

which cost a lot of time, but you do not earn anything. So therefore, it was hard to get in there and to create some kind of business value out of it. the first thing is if you want to create a business value out of it, you need some kind of business models which you can apply here. Um we apply the open core model. The idea here is

that the basic software is open source. I uh our idea is if you are a student or you want to just, let's say, create some kind of robot which does not have a safety critical use case, you can use our software out of the box, no strings attached. But if you require our software for instance to build a car, a plane, a train, or something like this,

you need to have safety critical extensions and so on. So therefore, this is something then where you have to come to us, work with us together, and we provide you tooling, documentation, and so on. So the idea is really you have a core available open source and then you can have extensions, plugins, and so on. Can provide advanced documentation and tooling. So the idea is for instance

for extensions, when you have a desktop application that can be plugins which uh add new functionality for instance which we have seen for example CR for instance with these AI additions. You can also provide support to new platforms. For instance, what we support is also platforms like QNX where you have a high license cost, but in the end if you go into a business relationship with us

we can maintain this. For our high frequency trader customers for instance, their performance goes over everything. So therefore it makes sense to have a plugin to let's say improve our latency in our library. Or let's say you go for language bindings and say okay, I want to also support Python, Go, and so on. This is something which we do not do about this also another let's say

option you can choose for. And the other thing is when you create libraries you often have the ability to create very complex systems out of it. And then a lack of developer tooling can be a real disadvantage. If you have the ability with your library to create a very complex distributed system and it fails at some point, it makes sense for instance to add some monitoring tooling,

introspection tooling, debugging tooling. If you have a library which creates graphs for instance, you maybe want to write an IDE plugin so that you have a preview to it and so on. Or if you can configure something in your library, create a configuration manager, something which helps the developer to improve their developer experience besides cool and nice API to just let's say use and write code with

your API and your library. The other idea is what we also pursue is enterprise subscriptions. First of all, why do we do this? The first thing is there is something like the Cyber Resilience Act. It's a EU regulations and in the end it forces the manufacturers to provide updates throughout the whole product life cycle. So therefore if you are a company creating a new product, you use

open source software and the open source first software has in the future bugs, security issues, and so on. You have to somehow ensure that the our product is maintained and also get these update delivered. And also if you go for let's say mission critical devices, you have to provide software certification. In the end, it's like a process or a framework where you have to prove that your

engineering and developer process was really rigorous so that you can ensure that the software is safe enough. And that you can create a safety case on top of this. And what you require for this is requirements traceability. You need to test your software. You need to document the software. You need design documents and so on. All of this. So, what we can take away from this, companies

have a need that their open source software is maintained over a longer term uh period of time. They are legally required to it. So, why not make a business case out of it? So, how it looks like, the idea is roughly you have your daily bug fixes and security patches. You always apply this to your latest OSS version. But your customer maybe will require an older version.

And here the idea is you create a closed source fork and whenever let's say as you heard here um issue arises which is also FA where the customer is affected, you can just backport the security issue to your closed source fork where your customer has access to it and provide this to the your customer. You can also add let's say features which he wants for a specific

version back to the specific version, bug fixes and so on and also let's see general support if something goes south on their hardware for instance that you say okay, we wrecked at a specific uh in a specific time. And besides that, you can also provide uh additional services like hey, you have access to our cool extensions and tooling here when you have a long-term service uh contract

with us or we have an internal CI when you have let's say um target a special embedded target which you care about that we say we deploy our CI to this target so that we always make sure that the whole stack your whole stack always runs on this particular target. So, what you also can do is you can get paid for open source development. But to get

paid for this, you have to clearly show the business value for your customer. What we do is for instance, we maintain a road map and say, "Okay, these are the features which we have in mind." we clearly state also what kind of feature requires funding. It's really written there in a section and say, "Okay, these features require funding. If you rely on them, you can either wait

and you get no guarantee that it will be implemented at all, maybe at some point in time." And if you require this, you can pay us for the implementation and then you have a specific due date, a specific deadline with a specific definition of done and you have let's say a feature which accelerates your development. And also, I would suggest that you do not add delivery dates

in your own road map because the first thing is that potential customers will not contact you because they say, "Okay, it's getting finished in March. I just wait until March." And the other thing is then they start to pinpoint you and say, "Okay, you said in your road map it's finished until March. It's not finished until March. Why is that?" And you have no customer relation with

them. It's a little bit annoying then. So, you can also pay get paid for closed source features. Let's see when you have an open core model and you have an extension and there's some kind of feature missing. Now, the customer has two options, implement the whole extension themselves and add this missing feature or they contact you, you implement the and they for instance reduce their lower in-house

their in-house development costs. They get faster to market and also you can play around then with software licenses. You can say for instance, there's a most favored nation clause that you can say, "Okay, you get all the benefits all other customers get and if you provide some kind of discount to a future customer, it will always apply to you as well." Or you find another license agreement

so that it's really beneficial for them to invest in the development of your closed source features and tooling. Another idea is is dual licensing. The rough idea is we have a copyleft license like GPL and that any derivative work must run under the same license terms and agreements. So, if you have a GPL license in your library or your product depends on this GPL license, then also

let's say the whole software stack must be GPL. >> [snorts] >> Uh this is great for an open source community and it's bad for companies which want to just create a closed source commercial product. And here the idea is we have a commercial license you can buy and then you can create your um commercial product out of it. One example is for instance Slint, it's a UI

framework from Rust. But the problem here is it's hard to enforce. Let's assume our use case for instance, we are a library for mission-critical devices. Let's assume we would have deployed this. How can we ever prove that a car is running with our library? We do not have access to all these different car windows. And even if we could prove this, we have to enforce this by

law. This can take years or even decades and it costs a lot of money. So, the question is should we really try this? And now with AI you have also the possibility for clean room implementations. The idea is you put all the source code into an AI and say, "Please rewrite this in Python, C++, Java, whatever." Here the question is for lawyers, is it a derivative work?

Is it still GPL? But this is something like let's assume someone does it. It's extremely hard to prove. So, therefore, I would restrain from a dual licensing model. You may consider it if you have let's say an end user application which can be extended with plugins and then you have a user which just wants to have some kind of customer branding and say, "Okay, this should not

run under the excite logo but under the Bosch logo for instance." Uh that you come up with this idea then, but still I would hesitate to apply this. So, now the business point of view. Another option would be support and consulting. So, basically the customer pays you for reliability and support of your open source software, which means you help the customer integrating or implementing your open source

software in their stack. Usually, this is done via service level agreements, and for sure you can offer different packages. Maybe your small package is 15 hours per month, your medium package is 30 hours per month including a short training or a a basic workshop. It depends also on your customer. Definitely is something um let's say a good foot uh a foot in the door. So, when you

have already a contact to the customer, you're supporting him to make things going or maybe also troubleshooting, stakes are high that there will be a follow-up contract for another support package, or maybe there's an offer or a request for feature development. So, it's really a good entry point, but from our point of view, definitely it's hard to scale because the number of hours of support hours you

can you can promise is limited to you. When you are solely the only maintainer, it's limited up to you and also on the number of your employees. And another pitfall is also that you somehow compete with your own ecosystem. So, when your documentation is really really good, there's less um less um time or less part for support, and also for sure um potential customer could ask for

support um in the community. So, definitely it's somehow a good offering in one pillar, and you can sell your expertise to save the customer's time as a business value, but it could be just one part out of your whole offering range. We've also also made experience with public funding. As you can see here, this is really just a short overview. You can see here some funding possibilities,

some German ones focusing on small starting companies, and also some public public funding options just solely focusing on open source project, for example, NLnet or the Sovereign Tech Fund. From our experience, it is good to have a good strategy to apply for. The reason is there are ton out of different option And some of them will not match with you, and you will not fulfill the requirements.

Therefore, at first, get an overview and create a funding strategy, which means make clear what are the requirements, can you fulfill them, and what are the due dates. Some of the funding programs have due dates once a year, and when you miss them, you have to wait for further full 12 months. having consideration that the application process really takes time and effort. So, it is good to

have in mind that the effort you put in should somehow equal the money you will get out So, we can definitely recommend that you apply for the ones you fit best. In sum, from our experience, funding is a night at on, and it's great that these possibilities are out there. But definitely time goes by till there is a final decision. In our cases, it was up to

12 months. we also prepared for a no. Stakes are high that you get rejected. So, in sum, from all these offering possibilities, there's no single open source business model matching for all. Your open source project is individual, and so is your business model. It's always a combination of different value proposition and benefits you're offering the customer. And keep in mind, the real asset is the trust a

potential customer put in you as a maintainer and your open source So, now get to some tips and tricks to how to not get killed from a business Definitely, you have to have an eye on your income. The cash, so to say. As I said, do not rely solely on public funding. It's a nice add-on, and you will definitely have some happy moments when you when you

get accepted, but it's really just a nice add-on. We can recommend to go for monthly billing. So, deliver monthly milestones to the customer and rely on small deliveries, so you can invoice monthly because keep in mind till the cash is on your bank account for a further 30 days. And 30 days can be somehow long when you're really really waiting and are right on the edge. And

therefore, also it's recommendable to save some extra money. Definitely for bad times, because they will come. And maybe there are times when no customer inquiry is coming, or the signing will take much longer than you think. You need time for some innovation, to work on your technical roadmap, to work on your milestones. And definitely, you need time to network, to join some conferences like this, and to

cooperate with others. Also, keep in mind, you need some money for your infrastructure, servers, CI, website. There's always money out there. Also, from a technical project planning point of view, avoid hourly billing, which means when you sell a feature, just name a fixed price. Don't name the hours you would put in for the development and an hourly price tag because someone will always be cheaper than you,

even when this not in your field and suddenly you're discussing about your hourly price instead of the value you delivering. And this is a discussion you can upfront avoid. Therefore, sell the features with a fixed price and keep in mind um to define a clear outcome to keep the delivery dates between trustful and worthy and this is much much much better than discussing on pricey rates. And

this is also um a really really valuable point. Never start without a signed contract. I know it's tempting because you're in a discussion there of informal promises. And the signing will definitely come, but maybe not and maybe it takes longer. And to keep the pressure on the customer's side, do not A third pillar that would uh prevent you from get killed is legal support. It's boring, but

it's necessary. It could make sense that you create your own NDA. Because when you have different customers, also in different countries, you will receive the NDAs from each of the customers and maybe they are not in your favor. This is not by a bad intention, but maybe there are some pitfalls in it. And therefore it also makes sense that you have a lawyer specifically for contract design

by your hand because you will receive a lot of papers and when it's not your field, it's crazy crazy to understand it. So, it's really um it's really better to have someone on your hand. And if it's possible in your country, in Germany it is, you can set up an insurance for legal disputes. So, when really really it's hits hits the bad moment, you have an insurance

and has a less risk for the costs. And from a technical side, it's Christian's. Okay. So, the things I think we identified as main risk for our project was AI, the mental health of the maintainers, commercial free riders, and lack of innovation. And I want to just shine light on all of these aspects. We start with public documentation. Every good software requires public documentation. So, the idea

here is for a good open source project, you provide examples, you provide documentation why code is written like it is, so that the users also get some insights in your idiomatic ideas, how to use your software correctly and efficiently, and then also you want to provide design docs, so that any contributors from the community can ramp up easily, or if they want to specialize something and contribute

something. So, it all has benefits, but with AI, you have the problem that they parse all of this, and then you have a user going to the AI and say, "I have this problem. Can you please generate code to fix this particular problem?" And now two things can happen. You generate the code, the user knows that your library is used, has no idea that this documentation comes

from your company or is somehow linked to your company, and just takes it for granted. Problem is more or less solved in the beginning, but therefore he does not do the connection from you from the say from this code snippet to your company. One prominent example is Tailwind. Uh they had an source available framework or have it, and they do exactly this, and their problem is that

the AI provides all the help they need, so therefore they struggle really to provide or sell support to the Another thing is also you say, "Okay, I have this problem." The problem is solved by the AI, and the developer does not even know that your product is already your library is used here. It's just solved. Don't care. Go for the next problem. The problem with AI is

uh AI does not understand. It's just a probabilistic machine. And here the thing is the 80% are done quickly. So, therefore, everything is running. The 20% all the edge cases where 90% of the time is spent are not solved at all. here the problem comes that the people solve the which solve the problem with the AI have to realize that now these problems are originating from their

faulty design. Understand that your library can be maybe here a solution. And this is something which is this is a challenge. And also the other thing is when the AI parses your documentation and you have there a business message and say, "Okay, take a look at this example. If you want to get more information, just contact us." This most likely get completely lost in the area of

AI. So, what to do? You can say, "Okay, I just get rid of all the examples documentation and design docs." But this is not a real solution because you want to have a good software product or a good open source software project there. So, the idea is publish everything very structured. Have the user documentation there, also the computer reader documentation, but also add all the documentation for

your closed source extensions, how to use them, what problems they solve in detail with code examples. And now a user comes and says, "Okay, I have the following problem. AI, can you solve this for me?" You get generated code. It does not compile. And now they have to contact you because you have the commercial extension or the commercial tooling for it. Now AI is somehow forced to

deliver your business message. this is our strategy which we're currently doing. We have written, for instance, an Icefaces 2 book which has both aspects, the public API and our closed source extensions. You can find this via AI. AI helps you also to realize the closed source extensions, but if you want to have them, you have to contact us. The other thing is commercial free riding. This is

also something which we let's say encounter regularly. We have a some kind of user or maybe a company a company which is very curious of certain aspects of of the code in the end. They never contributed anything. They just say, "Okay, how did you implement this and that?" And then you realize, "Ah, it seems they want to certify this code for this kind of vehicle for instance

or product." This is completely legal for them, but the problem is these detailed questions cost a lot of time. You get nothing back in return. It's just like reading issues, open discussions, and no feedback at all. It's even it goes time sometimes so far that they have bug fixes which you do not make open source because it's their IP and they are it's a business benefit for

us. Well, therefore, when you have customers behaving like this, be skeptical. And often also these customers contact you not via GitHub or an open source issue, they write you directly an email. So, therefore, create a clear boundary. If you want to have open source support, everything is public. If you need confidentiality, you need a contract. If you need a due date for a feature, you need a

contract. You need a bug fix at some point, you need a contract. Even if a bug is urgent, it's an open source community. We cannot guarantee you anything when it's fixed. We try to be as fast as possible, but it's still a try. If you need due dates, you need a contract. So, when you will see some kind of one-sided commercial interest, be cautious. And one thing

to identify this is if you just start, "Okay, we can start small, just have a little let's say consulting contract for 1,000 euro and so on." So, that you just get into their database. And when you then suddenly get a push back and say, "Oh, no, it's too complex." And "Ah, it's not like we work like this this way." Then you know exactly what to expect from

these guys and say, "Okay, you can do this in the open source realm." But if they are contacting you on let's say private emails and so on, you can just say push back, "No." It's not like I work. So, and this is a slide slide specially for big companies. Because there are big companies which which say, "We support this open source project." And all supporting means we

use it. It does not support anything at all. Another thing is, "Okay, we get also bug reports and also we have feature requests and so on. This is our support." No, it's not support in the end. Yes, it brings the technical side of the project further, but it increases the maintainers workload massively, especially with AI. And then there are also, let's say, companies who say, "Okay, we

created this feature uh request for this feature. We implemented this on our side. Please review it, these 10,000 lines of code in the next 2 days." And you say, "Okay." and this again increases the workload. You have to maintain it, you have to review it, and if there are some changes or some bugs, it's all on your side. The company is out and said, "Okay, I delivered

this feature once." So, how to support an open source project actually? First of thing a thing is direct financial support. Let's say, create a com- commercial contract with them. Get support commercial support from them. Or provide infrastructure and engineering resources. Or as a very rough rule of thumb, do anything which decreases the workload of the maintainer measurably. Can be, for instance, you see a bug or discover

the bug, fix the bug. Be part of the review process, for instance, also for features which does not affect you directly. yeah, let's see how far the message goes. The other thing is, protect your mental health. When you build up a open source company, it's a tough business. First of all, you need some kind of sustainable income. Uh then you have to manage your community, which can

be sometimes demanding because maybe a developer has an urgent feature that needs to be fixed as soon as possible. You do not have the capacity, you have to somehow mitigate Uh at the same time that you're trying to fix or let's say get a sustainable income, you have to focus on technical problems and innovation. and sometimes if you are under stress because you do not have a

sustainable income, you just are blocked for innovation because here needs some kind of calm state of mind and this is a particular challenge. And in Germany particularly, bureaucracy. Germans love bureaucracy. And what I can recommend is these links. Just click on them, read them. Uh what the main reason is that maintainers burn out and what why they for instance lost sudden interest in open source projects. And

from my point of view, I co-founded excite together with a good friend. We are both maintainers of Asterisk 2. And this helped a lot. To have someone on your side when you are stressed out who just says, "Calm down. Everything will be all right." Take a look at the good side and so on. And also that you can at least split the work that someone when you

are going insane for bureaucracy or some other thing will say, "Okay, I take over. Have some fun with some innovation and so on." This is, yeah, great to have. The other thing is um working in open source is extremely rewarding. This is also something which really uplifts your mental health. When you see people working on products and you make a significant change in their product thanks to

your library for and they thank you via Twitter or via Reddit, which happens rarely but it happens sometime. This is great. For instance, which you have you have to see the guys here. It's always when we have a release note where they will say, "Okay, Asterisk 2 is here." And they yeah, we have to create a Ceno gateway. And then they create a Ceno gateway and then

awesome and look what we have built here. This is something which is I have no idea. I never had it when I was working at Bosch in a commercial, yeah, huge company and then I never got this feedback. And also seeing your software being used in real systems, um helping to make the world a little bit better. This is great. And also when you have the ability

to create an open and friendly and welcoming community where everyone helps each other. This is also something when you are blocked and you are under stress and then someone says from a completely different part of the world, "Oh, I take over. No problem." This is something which is really what for me open source is about. And the other thing is it's also like the little engineer in

me is when you have a library or product, you solve a very specific technical problem and create some kind of value for someone. But often it's like the the technical problem evolves. There are new problems on the horizon and so on. So therefore, you have to constantly innovate and then you can really shift the state of the art and can say, "Look at what I did, how

fast I am, how good I am and so on, how efficient I am." No one else is there. So therefore, you use that here the state of the art and this is also something which is awesome, especially when it's acknowledged from others. And the final thing is lack of As we seen, you have to invest a lot of time in a sustainable income. You have to get

a handle the community. You have maybe customers which just want to have support. It has roughly something on the surface to do something with your library, but you are invested more and more into customer projects and let's say get some funding and so on. And let's say you have still challenges on the horizon, problems which your library does not fix and people need an answer for this.

And if you wait long enough, an answer will come either from your project or a new project arises which solves exactly the problem. So therefore, you have to really reserve time and money to constantly innovate on your side. And with this, we come to the conclusion. So as we said, it's a hard business it can be a tough business, but it's worthy and rewarding. This is definitely

our experience from the last 2 years and also before. But here are some final conclusions also. Definitely when you are a maintainer, maybe you have a small open source project, you're working for a small or big company, and you're thinking, "Can I do a side hustle as a first start with my open source project?" So, just as a start, find out um who is using your open

source project. In which other projects they are. Who is uh Who is the user? Where are the stars coming from? And are there some potential customers willing to pay? And based on this basic information, you can define your strategy up front. Which target domain you can go through. What could be your offer like? And what value proposition I can offer to them. So, you can just work

maybe in a side hustle. And then you keep going. Definitely write cool code, work on your project, and definitely talk about it. You could have the coolest project when but when nobody is aware of it, you have to talk about it. Conferences like this are the one of the best options for it. And then for sure, there's the last step, the implementing step. Translate this all this

all this information into offers. Define the features, define your road map, and be clear about what you are ready to offer and when and to who. And this is definitely something what we can show. So, thank you all for our attention, and we are here for your questions. So, first of all, thank you very much. I think um you know, great presentation. You raised the right point.

And for me, more than a question, it's I think a a call to the community. Because I've raised this point several times, open source is a common good. And we are in danger of the tragedy of commons. So, I think for everyone in this room, well, it's not the big room anymore. But we have the responsibility of supporting company that do open source. And let me share

a small story, right? In my previous In my previous company, you know, this very big company was commercial software, paying tons of money, and they contact us, "Hey, we switched to your software, works much better, and we are saving tons of money." We got zero out of it. Because it works, that's the other problem. If it works, why bother? And um I mean, I think that's very

short-sighted perspective, because I mean, it's very strategic for you. Uh you should support, you should nurture this company, because it's usually this company like you and many other company in this in this very niche domain, small company, that innovate. And so, I think it's a common responsibility, and I urge everyone in their company to take the role to make sure that this company gets funded. It's a

common good. We all have to take care of of it. So, thank you again. I think you spoke in on behalf of many of us. So, thank you, and let's keep the battle, because I think it's it's worth the game. Thank you. Maybe just let me add here, um from my personal point of view, I saw a ton of talks like how valuable open source is, that

companies have to fund it, and so on, and in different ways, and also, let's say, really naming them. There's curl is one of these uh let's say, typical examples. We say, "Okay, all these car OEMs using curl, no one is funding it at first instance." And this talk showed engage them and say, "Okay, you should accept the sad truth, they will not fund it. And just say,

we have to force them by providing business value to this additionally. So, therefore, we have to adapt, and say not we hope now for the best, that they really accepted that this brings value, but we have to find different strategies like open core, or commercial tooling extensions, something. Uh there's a wild pool out of of ideas out there and say, we can get this for free, but

then you support us out. If you need some kind of commercial closed source support and so on, you have to contact us. If you need tooling, you need to contact us, and so on. And this is I hope how it works. It works for us. But let's say when we go for sponsor us and so on, yeah, we get maybe a coffee a year. Thank you. >>

[applause]