Hi everybody. Welcome to the new folks in the room. So really, really pleased to welcome
back Georg Kevin and Johan, who presented last year and are back today to present on early
insights in the learning force and funders. And when you start to be helpful, you just
explain the format when you do questions. And otherwise, take it away.
Awesome. Thank you for the introduction. Hi everyone. Thank you for having us back here.
It was so much fun last year. When we shared our research findings that we decided this
gives us energy to do another research project. And we are back here to share again
what we learned. Last year, what we left was with the question about the funders that
are working in funding open source and the project and that intersection specifically. And so
we really wanted to hear from the funders and dig in on how they are doing their decisions
on what to fund, how do they evaluate that, how do they report on the impact. And we used
that because we also want to then help bridge that with the open source communities and
project, when they understand how funding works, then they can better plug into that funding.
So that's kind of the premise that we started with. And we did a run of interviews and we
are sharing some insights from that. And we are also, we also hosted a workshop this morning
where we brought together several funders from the open source space and already discussed
our research findings. And it's amazing how much we learned just from our conversation this
morning. So we'll also share some really new hot off the press insights that we have yet
to read digest. So you're the first ones we are talking this through with. If it's a little bit
raw, I hope you enjoy the process that research is sometimes it's not polished and messy
along the way. We are Johan Kevin and Georg, you see it on the slides. Johan is at the
research institute in Sweden. Kevin is at the Creighton University in Omaha, Nebraska.
And I am an open source strategist and director of sales at Petirja. And so I'm going to pass this
on to Kevin to talk about the or start talking about the details. And then at the end when we
get back to me, I have a bonus if he still have time for you. Kevin. Thank you, Georg. So I
don't select the point out all three of us are also members of the chaos project. And then
so structurally, this presentation we're going to present a slide that has some kind of key
insight or key takeaways from our interviews with representatives from 20 funding organizations.
And then we're going to do a follow-up slide where we have tried to capture some feedback and
capture some ideas that we received during the workshop where we presented these same key ideas.
At a high level, I'll start with what we learned from funders about vision, strategy and their
impact logic. And the first thing I'd like to point out is that the way we talk about metrics
is not neutral. So the way we talk about impact shapes what gets funded, what gets measured,
and ultimately the way that work is valued. The funder's vision shapes everything,
including what counts as impacts related to what I just said. And generally the funders that we've
interviewed have described how they create logic chains and impact is measured directly through
those logic chains, which means that there's no such thing as neutral outcomes. So funding
impact is related directly to these logic chains. When we presented this work at our workshop,
we had a lot of interesting discussions. One of the interesting things that came up during those
discussions was around how most of our funders kind of work under this trust model,
where they aim to explicitly donate to people that they trust to do the work. I would like to point
out that the funders that were represented in our interviews were not from government agencies.
That particular group is missing from our data. The trust model was very common with the funders
that we've talked to. But they also told us that the model is fragile. So when trust is
personal rather than institutional, organizations can become vulnerable when people leave that
organization. When people retire or when relationships should break down. We were also told
that one of the ways that funders build these logic chains is through the goal signal metric model,
which I'm sure you've already probably heard of, to some degree. The goal signal metric model
can be used to create impact logic, breaking down goals into questions, to ask signals to look
for, and then metrics that can be used to measure those signals. Around upper-age it,
the, I'll just say, upper-age operationalizing impact. I'm not going to be able to say it at
this point. So it's, it's, we're too far in. So if someone wants to shout it out, please do, thank you.
So what we heard in our interviews is that short-term deliverables dominate how impact is
operationalized. Sustainability work is often undervalued because success often looks like nothing
happened. And it's really hard to measure sustainability. Interestingly, around sustainability,
a lot of the folks we talked to often talked about sustainability in terms of risk mitigation.
Funding structures themselves, bias, what can be measured. For example, grants kind of lead to
short-term impact measurements, right? Strategic flexibility is needed, but it's hard to reconcile
that flexibility with stakeholder accountability. From the workshop,
we discussed further the scaling limits of trust-based models. So reliance on personal trust
becomes a bottleneck that often pushes us towards systems that more directly near kind of grant
writing situations and performative reporting. There are shifting definitions of success. Many of our
funders describe kind of a movement towards the hot topic of the day. So two or three years ago,
security was all the rage and now everything is AI, right? And then continuity problems in funding,
administrative turnover and policy shifts undermine the long-term continuity and reinforce those
short-term framing situations. Hello. So looking at the impact logic from the vision,
from the signals that you're looking for and then breaking down to the metrics. So from the
funders that we talked to, what signals were they looking for, what types of impact were they looking
for? We boiled that down into four main categories, one being the financial ROI return on investments,
which is really highlighted as key for the funders to report back to their institutional
backers to motivate that the money that comes in has an impact when it comes out. So
this is very problematic. It's very difficult to put financial numbers on these kinds of things,
but we need to talk about this. There has been studies now that on a macro level shows
what kind of impact open source has on GDP and economic growth. We need to find some way to
boil that, for example, one interview is said, okay, but people ask if I increase your funding
by 20% what will that imply in terms of security or sustainability. If you look at road maintenance,
if you say to the transport authority, you'll get 20% more funding and they will be able to
provide me with a number on how many more kilometers of road will be maintained, how many more
pad holes will be fixed. It will be very difficult to run there and possible to provide that maybe
in the open source space, but we need to somehow try and motivate and you research in this space.
Security and sustainability was also very hard topic. I mean, this can also be a concern with the
funders that we talked to many of them has the main vision about security, a big security focus
and related sustainability, but it's really what they're trying to improve to mitigate
potential vulnerabilities and communicating the impact of a vulnerability that hasn't emerged,
or hasn't realized. How do you do that? Putting a number on something that hasn't happened yet,
it could happen. Downstream use and adoption, how the adoption looks was also really indicated
if the mitigation of vulnerability is only to a product used by 10 people, then maybe the
impact isn't as big as for say curl, which is using basically everything, but we can also talk
about more innovation metrics and also like just having this software released as open source
that can be an impact metric as well depending on where you're coming from. And I'm looking
from the workshop reflections, they really highlighted adoption as a key metric and also as a multiplier
on whatever higher level impact that you're looking for in terms of security. If you mitigated
this vulnerability, how does that quantify? So it's really key, but it's also important to know
what kind of target groups or what you're considering when you're looking at adoption. And the
discussions with a highlighted that niche products may still weren't funding because they are
very critical in this subfield. So everything, if you don't have a 100,000 user community,
but you're more niche, there should still be a need for funding in those cases.
While this may, there was a lot of discussion back and forth here, so this is the topic that may
need further elaboration and discussion. And then also securities, yeah, as I said, quantifying
or describing something that hasn't happened, something that you mitigate is difficult, but it's
really key here. One funder talked about how they do rapid security reviews, taking a starting point,
they do an audit and it's okay, how is the security possible right now? How many
vulnerabilities are there or CVs or issues? And what's the response time and so on and so forth?
And then they do another audit in a year, and then see, okay, do we have a trend here? Is it
heading in a positive direction? And then they do another audit, and then see, is the secured
positive? Increasingly, improving, then we can talk about an impact. And there was also talks about
how security can also be a proxy for other things like maintainer health is very difficult to
quantify. Maybe easier on a very single product level, but done at scale, it's very difficult.
So you need different kinds of proxies. So security related signals can be a proxy for this,
which could warrant further investigation.
So the measurement approach that we see with a lot of funders. So most of the funders we talk to,
talk to us about how a lot of their reporting, a lot of their impact,
is done through qualitative narratives, right? So telling stories.
However, they do believe that quantitative metrics are needed to provide credibility.
Additionally, when measuring impact, establishing a baseline,
is considered critical for demonstrating progress. And then there was also a discussion about
kind of overly generalized frameworks, right? So overly generalized frameworks for, for
measuring impact, risk erasing or losing important forms of impact. However, if we're all going
to have conversations about funding, especially in an ecosystem, we kind of have, we need to have
some common structure to aggregate results, right? So, and then the last part, infrastructure
impact is easier to measure than human sustainability, right? So from a measurement standpoint,
the metrics are easy to grab, human sustainability is a little bit harder. And as Johann mentioned
on the on the previous slide, there was also some discussion that some of these metrics
could be proxies for for human sustainability metrics. The very least,
give us a signpost or a signal that tells us we need to look into these things a little bit further.
For the workshop reflections, most of the funders we talk to believe that maintainer health is a
critical blind spot. Burnout capacity constraints and leadership continuity issues often precede
security and sustainability failures building on what we just talked about. And there was a suggestion
on a way to handle that. Possibly similar to a surveys that they have in health, a maintainer
burnout survey, which could run as a basically as part of a security audit. For impact reporting,
long-term impact is acknowledged. But most of the funders we talk to are not capturing it or
expressed difficulty in reporting it. Reporting formats, privilege, short-term success over
ecosystem reporting. And most of the impact on reporting is audience specific, right? So these reports
are written towards certain stakeholders. And then lastly, for a lot of our funders,
impact reporting is often about establishing credibility or legitimacy in their funding.
From the workshop reflections portion, the feedback that we got is that impact often
merges too late for funding cycles. And you'll budget cycles make long-term impact hard to
demonstrate. Impact needs to be defined upfront, but often it's maybe missing.
And then reporting must be proportional. Heavy reporting burdens discourage projects from
applying funders need clear upfront expectations. And when they are reporting to their stakeholders,
they'd really like some feedback on what they can report and what stakeholders would like to hear.
So we have shared many different things that we've heard and learned along the way.
One thing that we are also looking at is what can we do to help improve the space?
Last year, when we were here, you can look at the recording we talked about the needs that
open source projects have that maintainers shared with us. This is the kind of support and
help that we need. This year, we dug into the funder side on how that other side is
helping open source projects, how they decide on things. And ways that we can collaborate on improving
that back and forth. This is from the funder perspective is the idea that when we have open source
projects and they are close to burnout where there's a single maintainer or small team that's
been doing it for a really long time, how do we sense early enough that there is a risk of burnout
to jump in and help when the time is needed to do that. And the story that we heard was from
the caregiving side. So when someone takes care of a family member and they go into the medical
institution for the regular checkup, it's not just the person that needs the care that gets checked
up on the doctors and nurses also check in with the person that does the caregiving and there's
a questionnaire on how are you doing, what's working, what's not working, what kind of support do you
need. And if we have that something along that line in open source, maybe we can build that out
together, then the projects and the funders can have these checkpoints on how is the project doing,
how the people in the project doing. We also see a need for the types of measurement. We just
heard that there is a lot of variety in the types of projects in the way that funding works
and they're all different snowflakes. They're all unique in their own way and that's great.
We love diversity, we love that. But maybe there is some standard common way that we can
talk about measurement and impact. That's kind of the work that we're working on right now.
Also, how do we set expectations with donors and the ones that provide the money?
Up front, here's what you will get for giving the funds and then also
downstream, how do you talk to the projects and make sure that when funds are given
expectations are set from the beginning so that when we have impact, there's certain impact,
we have certainty around, we know what the measurements are going to be, and there's no surprises
next year on, hey, we need these numbers to renew the funding. We want to be able to sustain
the funding long-term. So with that, I've got the time we have 10 minutes. I first want to, of
course, thank our institutions for funding this research and I want to hear from you now because
I brought a bonus that is separate from the research project that we're doing. It's a project
that I work on in my own time, the paid open source model. I'm happy to show how in Web 3,
combining open source way of collaborating. Web 3, we can build a sustainable system, hopefully,
the idea. We're still in the middle of building this out. Or do you want some time to ask questions
right now? Now, I'm going to ask you to signal by knocking on the desk in front of you.
Two options. One, do you want to ask questions? Knock now.
All right, we have a few. Who is interested in the bonus? Knock now.
All right, I heard more knocking. So I'll do that first, keep it short, so we still have time for questions.
The, when we look at open source ecosystem, I'll just start there. We have the development of software,
something is created that provides functionality that can be used inside of products,
which then commercial entities can build services around. That is the open source model from
creation to creating something that has users, a community, and hopefully financial inflow.
If we do this in a Web 3 environment, and the open source projects are tools in the Web 3 tool chain,
then on the blockchain, there are transaction fees. Every time someone uses the open source
software, now there is a transaction fee to actually make something happen on the blockchain,
and that can be a fee on that that goes into the treasury, and we can use that to fund the open source
development again. So we can have a positive reinforcing cycle, because now when we have money flowing
into open source and developing high quality software, people trust it more to build new tools,
build more products, which then has more uses, which then has more transactions,
and more transaction fees, and not bigger treasury, and there's a positive cycle where we hopefully
get empowered community that is funded. We reduce the risk of maintaining a burnout. We have
a global adoption, people trust in the security. There is money available for those kinds of things,
and it creates sustainable funding, because there's a direct link between growing users,
more transactions, more transaction fees in the pot. So right now we are in the middle of building
this out at intersect for the Cardano space, and I'll just briefly, high level walk this through
and give you the resource where you can dig into this more. When we take this software delivery
lifecycle here on the left, there are different phases along that, and we have different programs,
whether it's the maintainer, retainer program, or we fund community maintainers to take care of
the day-to-day work in the community, not just work on the software itself, but also
triaging bugs, being their answering questions. So there's funding for that. Code for us,
where during the we need a new tool phase, we have grants that we can give out and say,
please help us develop this. People are paid to do that. The project support services, the projects
themselves may not have the knowledge, the insights to look at what is my community doing,
how can I improve their support available that is paid for to do this, also strategic partnerships
and so on. That then creates the libraries, the products which are feeding into a whole
ecosystem of things. So I want to pause here, stop here, these are the resources if you're interested
in imagining what a different world we could be living in when we combine web three,
blockchain, and open source and hopefully create a funding mechanism and model that is sustainable.
With that, we are now opening up for questions. Since some of you had questions and I believe
there was a microphone that is going to be passed around and then I'm going to take this off again,
because Johan or Kevin might be more qualified to answer some of your questions.
What are your questions? Who knows?
The one question would be for example, sorry. If you have a project that is not commercial,
you have a commercial in there. You have a lot of maintenance put in there, small team,
everybody spends half a day on maintenance. You can't put it into numbers, what comes out
with maintenance, but what comes out, if half of the team says, I'm exhausted, I have to give up.
It's a project that's going well, down, because it's not really maintenance. Where can you
reach out to to say we would need some funding to go on, even if it's a small continuous funding
of the purpose? So there is an effort that I want to plug in. Emma Irwin is
beheading an effort right now called the Open Source Visualist, where maintenance or projects
can say, here's actually what we need and define it in a standard format so that aggregators
like the ecosystem's data set that is collecting from all the package managers, the packages,
we can pull that data in and see at scale, okay, what are the projects that, and I'm speaking
from the user perspective right now. As a user, I can go through what are all of the packages
that I depend on, what are the maintainers and communities telling me they need so that I can
hopefully support them. From a project perspective, they're then just pointed out in the previous
talk. There are a lot of different programs, really difficult to keep a list of these are the
project programs available right now because they open, they close, they change all the time.
Yeah, as a maintainer, there's a lot and how do you communicate that? So check out the
wish list that might be, yeah, thank you, there's another one back there.
Hi, I was going to ask a question about being a small maintainer but you said the word block chain
and so now I'm completely distracted by this terrible idea and I just, this is new to me,
I have a feeling you've probably gotten this question before but I want to ask it so that everyone
else can hear the answer that I hope to hear too, which is if you take the word block chain out of
this, this just sounds like you're commercializing the open source software. Why, what, how is this
not just commercializing the software, this sounds like paper use, which is not what
free software is about? So when we look at the open source software that we have right now,
there are commercial companies that built on top of them and they extract value in a sense
and they offer services that they could build more quickly, more cheaply than if they have
to do everything themselves because they're building on the existing building blocks that we
in the open source community developed. That is the, the model here and there's no flow back.
In the blockchain context we have is there are transaction fees for every blockchain
transaction like a tax. So if you were to go and say every software user has to pay a tax or
every company that is using open source pays a tax and now there is a treasury that has money
available that can reinvest into that open source software. That's what's different here because
we have that feedback loop and a mechanism for capturing some value that we can now reintroduce
into that early open source development. Thank you. We can chat more afterwards, certainly.
Thank you. Here's another question. Yeah, so it's four small questions.
So which kind of funders have you been talking to? Which kind of initiatives have been funding?
Do you have examples and it's very reported you'll study which we can read somewhere?
Do you want to talk to that? I don't think we want to
name specific funders right now, but I'm happy to talk off line when we're not recording.
We, I would say we've talked to both large corporations.
American large corporations doing funding in this space. We've talked to
collaborations between large companies doing joint funding.
We've talked to foundations doing and receiving funding. We've talked to
government institutions both doing different kinds of funding.
Both towards maintenance and other types. So I would say we've covered up quite broad field
of various funders. So both government, private, more nonprofit and philanthropic as well.
Yeah, that's what we're going to. So again, we've just finished the interviews and we just did a
workshop on this this morning. So the report will be out definitely soon.
We're meeting on Tuesday at a Wednesday, I think, to decide where we're going to publish.
So this is all still in the works.
There's another question back there. Yes. Hi. So this is regarding the
maintainer burnout that you said and I just want to ask from your survey. Did you not find this
point that the amount it takes for a new contribution to make it into the
the upstream, right? That is a big indication how much load is on the maintainer.
If there are a lot of patches, merge requests, whatever is open, vulnerability fixes that are not
getting in or takes a lot of time to get in, right? Maybe the there is a bottleneck at this level
for people to review it and get it. This I did not find maybe it's covered in your research later.
Yes, you're absolutely right. There are proxy metrics or indicators that when burnout occurs,
certain symptoms show up in the community that we can look at. And the the funders that we
talk to there are aware of this. The funders that we talked to by the way are really
deeply ingrained in open source. All of them understand the problem. It's an institutional
and system level problem often where they have demands from the donors or structurally or
budgetary because it's only year to year. So the breakdown that we see are in the system
more so than in the people. That's where the insight that it's relationship based comes out.
Because a lot of them we've heard, hey, I sometimes just look the maintainer in the eye to
understand where they're at and I can just see the burnout sometimes. So yes, thank you.
I see time is up. Thank you so much everyone for being here, joining us today and being part
of this journey as we learn and I hope you learned something as well.