>"The model and pitch also came into clearer focus. Truly, it’s simple: if you’re betting your business on a critical open source technology, you
1. want it to be sustainably and predictably maintained; and
2. need occasional access to expertise that would be blisteringly expensive to acquire and retain.[5]
Getting maintainers on retainer
solves both problems for a fraction of the cost
of a fully-loaded full-time engineer. From the maintainers’ point of view, it’s steady income to keep doing what they do best, and to join one more Slack Connect channel to answer high-leverage questions. It’s a great deal for both sides."
I love it!
I love your business model!
More power to you, your company, and other future Open Source maintenance companies!
I'm really glad to see `bluemonday` in such company, but I'm also really happy to hand over the reigns to a group of engineers that can focus on OSS.
I am the author of https://github.com/microcosm-cc/bluemonday but being a maintainer is a journey, you make a tool for yourself, you realise others will benefit and open it up to others... time passes... and then you realise you are that tiny pillar in the XKCD comic about dependencies, and that when you make a casual update to the project that multiple security companies ping you to ask the impact and scope of the change, implications, and of course others ping you to say that it breaks their individual workflow.
I've known Filippo for almost as long as that library has existed, and I know it's in a safe pair of hands, and that Geomys is going to be a good home to all of the OSS projects that they have in their portfolio.
It's definitely a journey, how should these foundational elements be supported and funded? This is one answer to that question, and I'm glad it exists as my spare cycles were very few, I'm also really glad for Filippo being so key to it, if anyone will make this work and do a good thing it will be him and those who he surrounds himself with.
I still wish that there would be no liability until money changes hands between the parties.
According to your link, liability still may exist if the FOSS project is a "commercial beneficiary." Does this mean that there could be liability even if the third party doesn't pay for it, just because others do?
My understanding, tempered quite a bit from LWN comments on its coverage of the CRA, is that without money transferring for the parties involved, there is no liability.
I suspect you're in the US (I think I saw a US location in your Twitter bio before the login page replaced it), the rules for Europe are different and applying an American viewpoint on how business relationships occur gives an inaccurate perception of things.
I personally like Sentry's approach more, their program focused on supporting the breadth and depth of their dependency tree rather than just the critical components https://blog.sentry.io/we-just-gave-500-000-dollars-to-open-... Disclaimer: I work for thanks.dev
I got a DM from a maintainer asking to elaborate so here's my personal opinion "The Geomys model feels a lot like the Tidelift model but it doesn't really create an eco-system that's more inclusive & exciting to be a part of. We want to create a community where more maintainers are excited by contributing to open source instead of them saying ohh this is too hard lets pass it onto someone else with the resource. The other issue is that how do you determine if something is critical & if something isn't, it's really subjective."
This is pretty exciting to see. I'm not an OSS maintainer myself, mostly due to lack of focus/energy, but the prospect of working with a company such as Geomys is inspiring. And I've been wanting to learn Go anyway...
I wrote a bash script before anything existed for node.js to run a process on a server...people were just doing `node ./index.js` -- my script created and init.d/start-node.sh script and suprisingly its my most popular project even today -- that was back in 2010 I wrote that shit. SHortly after it got picked up by some js newsletters and HN I found nodemon and switched to that.
This is a fascinating idea. However, I wonder how it fits with the fact that the target type of project is still maintained by one person / project expert. Where is the redundancy for the proverbial maintainer-run-over-by-a-bus? While the three engineers necessary for maintaining a critical dependency is expensive, a company is unlikely to lose them all at once.
It would be interesting if Geomys promoted some form of cross-pollination among its associate maintainers, but it sounds like they're trying not to direct the work.
>"The model and pitch also came into clearer focus. Truly, it’s simple: if you’re betting your business on a critical open source technology, you
1. want it to be sustainably and predictably maintained; and
2. need occasional access to expertise that would be blisteringly expensive to acquire and retain.[5]
Getting maintainers on retainer
solves both problems for a fraction of the cost
of a fully-loaded full-time engineer. From the maintainers’ point of view, it’s steady income to keep doing what they do best, and to join one more Slack Connect channel to answer high-leverage questions. It’s a great deal for both sides."
I love it!
I love your business model!
More power to you, your company, and other future Open Source maintenance companies!
I'm really glad to see `bluemonday` in such company, but I'm also really happy to hand over the reigns to a group of engineers that can focus on OSS.
I am the author of https://github.com/microcosm-cc/bluemonday but being a maintainer is a journey, you make a tool for yourself, you realise others will benefit and open it up to others... time passes... and then you realise you are that tiny pillar in the XKCD comic about dependencies, and that when you make a casual update to the project that multiple security companies ping you to ask the impact and scope of the change, implications, and of course others ping you to say that it breaks their individual workflow.
I've known Filippo for almost as long as that library has existed, and I know it's in a safe pair of hands, and that Geomys is going to be a good home to all of the OSS projects that they have in their portfolio.
It's definitely a journey, how should these foundational elements be supported and funded? This is one answer to that question, and I'm glad it exists as my spare cycles were very few, I'm also really glad for Filippo being so key to it, if anyone will make this work and do a good thing it will be him and those who he surrounds himself with.
This is what I was envisioning when I wrote this: https://gavinhoward.com/2023/11/how-to-fund-foss-save-it-fro... .
Have the updates to the CRA since that post changed your opinion on it at all?
https://opensource.org/blog/the-european-regulators-listened...
Mostly.
I still wish that there would be no liability until money changes hands between the parties.
According to your link, liability still may exist if the FOSS project is a "commercial beneficiary." Does this mean that there could be liability even if the third party doesn't pay for it, just because others do?
My understanding, tempered quite a bit from LWN comments on its coverage of the CRA, is that without money transferring for the parties involved, there is no liability.
I suspect you're in the US (I think I saw a US location in your Twitter bio before the login page replaced it), the rules for Europe are different and applying an American viewpoint on how business relationships occur gives an inaccurate perception of things.
I personally like Sentry's approach more, their program focused on supporting the breadth and depth of their dependency tree rather than just the critical components https://blog.sentry.io/we-just-gave-500-000-dollars-to-open-... Disclaimer: I work for thanks.dev
I got a DM from a maintainer asking to elaborate so here's my personal opinion "The Geomys model feels a lot like the Tidelift model but it doesn't really create an eco-system that's more inclusive & exciting to be a part of. We want to create a community where more maintainers are excited by contributing to open source instead of them saying ohh this is too hard lets pass it onto someone else with the resource. The other issue is that how do you determine if something is critical & if something isn't, it's really subjective."
Did I misread something? I don't think Geomys is in the business of deciding what is or isn't critical.
This is pretty exciting to see. I'm not an OSS maintainer myself, mostly due to lack of focus/energy, but the prospect of working with a company such as Geomys is inspiring. And I've been wanting to learn Go anyway...
Very cool! I hope this will work out well and that we’ll see more companies like this launching.
I wrote a bash script before anything existed for node.js to run a process on a server...people were just doing `node ./index.js` -- my script created and init.d/start-node.sh script and suprisingly its my most popular project even today -- that was back in 2010 I wrote that shit. SHortly after it got picked up by some js newsletters and HN I found nodemon and switched to that.
For what its worth now I use systemd scripts.
This is a fascinating idea. However, I wonder how it fits with the fact that the target type of project is still maintained by one person / project expert. Where is the redundancy for the proverbial maintainer-run-over-by-a-bus? While the three engineers necessary for maintaining a critical dependency is expensive, a company is unlikely to lose them all at once.
It would be interesting if Geomys promoted some form of cross-pollination among its associate maintainers, but it sounds like they're trying not to direct the work.
I wonder if there is a way to sustainably fund individual contributors too, most FOSS funding mechanisms seem to focus on maintainers.
The team at frontend masters are doing that well https://frontendmasters.com/blog/how-were-supporting-open-so...
Thats still contributing to the maintainers of projects, not to the people writing pull requests etc.
Great idea and well thought out execution. I suspect this will be a successful business for a long time to come.