Hello, everyone. Hello, hello, hello. It looks like it is time for me to begin. So if you
are here for this topic, you know, you're in the right place. That's awesome. Who am
I? I am Matt Yakovic. I am the head of open source strategy at Scarf or the Haas for short.
You may have heard me or seen talks from me before. Multiple ways to connect with me.
Podcasts, different things that I do. If you don't know what Scarf does, what we do is we help
projects and maintainers grow their open source adoption, help track it, help analyze it, help
you understand who's downloading and using your open source software. We also do a hacking open
source business podcast. And so that is up to 14 episodes, I think are recorded now. So if you're
interested in understanding from others on what is working in the open source business space,
okay, it seems like I need to hold it a little closer, then that would be a good place to check
out. We're also launching a new website that has all of the information from these slides,
as well as a whole bunch of other details on how to measure your open source businesses.
And we have it under opensourcemetrics.org. If you're interested, there's links to the podcast
and various things on running an open source business and measuring it. So how many people
here know open source is different, right? Unlike other businesses, obviously you are competing
with free, which changes the mindset quite a bit. Let me give you an example. It's a very easy
example and people will pick it apart, but let me just get through it real quick. If you're selling
a car nowadays, if you're a car manufacturer, you have the ability to set your price for the car,
people can walk away from the car. If they don't buy a car or a vehicle, then they would have to
choose some other alternative modes of transportation. If you use a car that's in the open source space,
you can still set the price for the car, but you don't actually have to pay for it. So someone can
come get the car for free, drive it around, and do whatever they want with it. So consumers can
choose to buy your car or someone else. And that boggles the mind of many traditional business
folks because it's giving something away for free. And one of the key things that people misunderstand
about open source is it's great if it's free and people can use it, but in order for people not
to choose the free version and pay for something that's in the commercial space, it has to give
you more value than what you're going to get in that free space. You have to figure out some way
to connect with those folks, and you have to make sure that they are finding value in what you have.
Now, some of you, and I'm interested to know, how many people are more on the tech space in here?
Can you raise your right hands? Okay, how many people on the business space? Raise your left foot.
Okay, so a few. Well, so many on the tech space consider this type of a talk when we talk about
revenue and money, evil. So I'm going to go ahead and put on my other hat, which is my super evil
villain hat, you know, for this talk. And that doesn't necessarily mean that this is wrong,
or that it is super evil or villainous, but it's hard for tech folks, especially founders,
to talk about revenue and money. This is outside of the wheelhouse, right? From a technical standpoint,
when we talk about growing, you know, your business, that's not something that is naturally inherent.
So people seek out different advisors, they look for who's done it before, what sort of things
have worked, and then they try to repeat that process. So I want to start by giving some
baselines. There's a lot of common open source business models out there. There's there's several,
but I'm going to talk about the three primary ones. And that's open core, a SAS model, or is,
and as a service model, it could be infrastructure, platform as a service,
just consider all those the same, or services themselves. Now, from an open core perspective,
okay, and excuse all the graphics in this, I'm not a graphics designer, so, you know,
they're they're they're a little hokey, but open core, how many people have heard of open core
before? Oh, the vast majority, but not everyone. Okay, so open core is when you have an open source
version of your project that's freely available for everyone. But then you have an enterprise
version, the enterprise version reserves some set of features. And then if someone wants those
features, typically more enterprise features like maybe higher security integration with partner
products, things like that, then people will then have the ability to purchase that from you,
and then they'll pay a regular ongoing fee. A lot of companies have dual licenses in this case.
So their open source is, you know, let's say GPL, and then there's some enterprise license for their,
you know, enterprise version. Okay, now this is dwindling a little bit in popularity,
as the cloud has taken over much of the tech industry. And that's where a lot of new businesses,
especially in the open source space, are looking. And that's in this SAS or this cloud model. Okay,
you can download the software, but if you really want to run it, then, you know, you should use
our SAS thing will make it easier. This provides a higher level of quote unquote stickiness. Now,
if you are a manager, director, executive at a company that has, you know, venture funding or
that you're, you know, has executives who are, you know, kind of in been in the industry for a while,
I guarantee that they have had at least 10 conversations about stickiness in open source
in a calendar year. And what stickiness is, is the ability for someone to start to use your open
source software, and then continue to use it. So how do we make it sticky? How do we retain them?
In many companies, this is a model that provides a higher level of stickiness. Because once you
get into a cloud service, it's often really, really difficult to migrate away. Because you're
relying on that cloud service to be your sys admins, your DBAs, your, you know, DevOps folks,
they're handling all those functions. And so to replace that, you either have to go to another
cloud service, or you need to find someone who can do those functions for you. And that's often
a really difficult prospect to do. But there are some issues with this model. This model is
disruptible, because other people can run that exact same as a service. What we've been seeing
in the space of the SAS lately, is a lot of open source companies have changed their licenses to
prevent that. And they've gone from open to not open. So you might have heard of SSPL, you might
have heard of the BSL, other things. These licenses are kind of sort of open. But that means that,
you know, as you get into the cloud space, you're restricted from competing with them. So it's more
of a preservation of their revenue stream, if you will. And then there's the services model,
which is really the original kind of OG, the old, you know, model for open source software.
And that model is definitely something that we have seen be very popular and very successful in
a lot of different companies. This is a viable pathway for a lot of companies to start. It's an
easier pathway to revenue. But it is hard to grow beyond a certain limit. So, you know, you might
be able to get a handful of customers working with you from a support perspective, from a
consulting perspective. But you're really bound on the number of people. Because you have to have
people to deliver those services. And if you don't have people to deliver those services, that
becomes quite an issue. And if you compare the three models, I'll, you know, you can compare them.
You know, you've got that open core, which is a proven model, but it is getting disrupted
and eroded by the cloud a little bit. And, you know, there's still some success in that space,
because a lot of companies, especially when you listen to, like, some of the sovereign cloud, the
cloud native, they're looking at enterprise versions or open core versions. They want to run
their operators. They want to build their own private clouds. So, there is still some play in
that space. X is a service or software is a service. You know, that is still a very popular model.
But the question is, if you are releasing features that are only available in a SaaS version, and
only a minimal open source version, is SaaS, the SaaS model, is it still open source? Or is it not?
And that's a question that we really haven't answered yet, especially as companies start to
reserve features and software specifically just for their SaaS customers. And then there's the
service model, which is definitely the easiest to get started if you're a small company. It, you
know, has the most likelihood that you'll get some revenue in the door really quickly without
a huge buy-in cost. Now, part of this model, okay, if you, whether you choose whichever model you
choose, is how do you get people to move from being open source users to actually paying customers?
Okay. And, you know, this is probably the most stressful thing in open source maintainer, founder,
someone in the open source space has. Because ultimately, you're looking at this open source
adoption, and let's say you're tracking 100 million downloads, but nobody wants to pay for
anything. That's actually a use case that happens quite a bit. How do you, how do you, how do you
figure that out? How do you, how do you turn that 100 million downloads? How do you turn that, you
know, 5,000 people who are tweeting about you into something that is actually commercially viable?
And when we go look at the classic sort of marketing funnel, and anybody here in marketing,
I'm just curious, no one will, one person, two people want to admit it. Hey, three people. Okay.
Oh, look at that. All right. So you might be familiar with this if you are in marketing, right?
So this is just this very simple marketing funnel where you've got, you know, people who are hitting
your website, and they turn into a contact or a lead, if you will, where they become a known user,
and then they turn into a marketing qualified lead after they do a certain number of things.
So let's say you're there on your website, they sign up for a webinar, maybe they downloaded
your software, maybe they did a few other things, they get a certain number of points,
and when they reach the point value, then all of a sudden it's like, whoo-hoo,
you are now qualified, so then sales can talk to you. And then you have a, you know, sales
accepted lead. So sales goes, ooh, that looks pretty good. And then you have a sales qualified
lead when they start to say, hmm, I think I could sell something. All right. This is the classic
marketing funnel, but it doesn't work in an open source space. There is a similar way to think
about this. Okay. Because the open source model kind of flips this on its head. There is this model
where we've got the interest phase, which is the people who are discovering what your product
can do, how it can behave, what it can do differently. And you want them to actually try your software,
okay? You want them to install your software or use your containers or use your library in,
you know, their product. And only a subset of those who are actually interested, a subset of
those who will visit your project's web page, visit your web pages, visit your assets,
there, only that small subset is going to actually try. And of those who try, only a subset will
continue to use it in production. And then only a subset will become a customer. So that model
is very important because as we look at this phase, you've got to realize that if you have a million
people on your website and you have 100,000 downloads, that's great. But there might only
be 10,000 who use it in production and that might only have like 1,000 people who would be willing
to pay for it. Now some of you who are familiar with the product space might say, well, we don't
follow the funnel, we follow the, you know, product flywheel, the product growth flywheel.
So anybody familiar with the product growth flywheel? All right, one, okay. So the idea is,
it's funny because they actually stole a lot of this from the open source movement.
When you look at the product flywheel, and this is all the hotness in all the product
companies, right? So when we're talking about a product led company, a product, you know,
product led growth, what they're talking about is people start off in this center, this core,
and it's like, oh, how do we track and engage with people? How do we delight them? How do we make
them really excited about things? Okay. And then we can take those strangers, turn them into prospects,
which then turns them into customers, which then turns them into fans, and then they will start
to become the people who will preach to the other people, to tell other people how awesome
our software is and get them into the community. There's an open source version of this, and again,
excuse my crappy little, you know, diagrams here, if someone wants to contribute these,
better versions, that's awesome. But the idea here is, it's very similar, similar phases,
but if you look at the differences, the differences are we have a download and try,
we have that build and deploy into production, and then we have, oh, they're running it into
prod, and then it kind of goes into, hey, do I need something more? That's when I'd be willing to pay.
And then you'll evaluate a paid option and become that paying customer. It's a very similar cycle,
both are the same, but there's a few differences. I like to clarify this a little bit more in the
open source space because it makes sense, because really what you're talking about here is someone
who's trying your open source software, they're getting used to it, they're like, wow, that's
pretty cool. But if it only did this next thing, and then you're like, oh, well, I have that,
it's in the enterprise version, right? If it only did, you know, you know, integration with this
other product, and so that's where, oh, I need something more, and then you get them to evaluate
it. And that becomes a way to build external evangelists. So there's also this idea of
evangelism or evangelists, a way to foster people who are in your community, who become fans of your
product, who then actually go out and contribute to that flywheel, right? So the goal here is
you want someone who can start off telling people, wow, I was really successful with this application,
and then they'll tell their followers and people who like them and people who are like-minded,
and then those people will watch that content, and then those people will go ahead and try it. And
it's similar when you add DevRel, evangelism, this is all part of that product flywheel,
where you want more people to understand it and then eventually try it, and then eventually you
want those people to create or help foster new people into the community where there are new
evangelists who can go out there and talk about your product. So let's talk specifically about
driving open source adoption, okay? And there's only three things you need to do. Yeah, I'm going
to sound like one of those shill salesmen on the late night, you know, TV commercials where it's
like, you know, these three things, if you buy into my system, you'll be awesome. You know,
this will be the best thing ever for you. And so there's actually three requirements that we'll dig
into a little bit, and as much as we can in the time remaining, for driving open source adoption
and growing your open source adoption. And those secrets to the success are a kiss ass product.
Okay, it all starts with the product. If you don't have a product that people want, it doesn't
matter what else you do, they're not going to, you know, listen to you, they're not going to try
it out. It needs to be rock solid. We need people to know who you are. Okay, a lot of open source
projects that are out there have awesome technology behind them, but nobody knows who they are. Has
anybody run into a product like and said like, how did I not know about that like three years ago?
Right, that happens. And why is that? Because however, you know, whoever's running these projects,
they're not really sure how to bring awareness to everyone else. And then you need to make it
easier than all the alternatives out there in the space. Okay, obvious, right? All these are obvious,
that it's not like it's like anything that's just crazy. All these should be obvious and easy as well.
Now, I can't go into a deep dive for all of these, but briefly, I want to touch on each one,
and we'll go through each one separately. So how do you build a kick ass open source project?
Now, I can tell you, like, you know, all the technical jargon, but I'm going to stick with
from a business perspective, what this looks like. First, I want to talk about the biggest
mistake we all make when we're building a project. At a certain point, we have to realize that, you
know, when we want when we are building a project, we're often starting it, building it for what we
want. And that works for maybe like a little bit of time, and you might even make a successful
company, but you're going to limit your growth if you are building for people who you think
are the exact same people as you, right? It's that, oh, I assume everyone is like me. I know
people who follow this, and they're like, well, I assume that everyone's going to install on the
command line. I assume everyone will install from source. And so that's just the way that they think.
That's not necessarily how everyone else in the community thinks. So make sure that you avoid that.
And that's why the first key, in my opinion, is understanding, right? Understand the product
and its value, right? What can your product do better than anyone else? Okay, are people willing
to even pay for that? You should ask yourself that question. Can you answer that question?
What do you do over the alternative? Right? So is there an alternative to this? Is there some other
piece of software, something else that other people are doing? What do you consider success? Now,
this one is really interesting. I've talked to a lot of founders. I've talked to a lot of CEOs,
executives. And, you know, they'll talk to me about, oh, we want to accelerate our growth, our
adoption. And I'll say, well, what's your goal? And they'll be like, well, we want to, you know,
sell the company, or we want 10x evaluation, or we want, like, you know, fill in the blank. It's
like, no, no, no, what do you really want? What do you want in the next year? What do you really,
really want? And a lot of times it's like, oh, well, really what we want is people to sign up for
our new beta. I've actually had that conversation where it's like, we just want like 1,000 people
to try it and then give us feedback. Oh, it's a very different sort of product that you're building
and sort, and also marketing activities or community activities that you're doing. And so
that's something to consider. Who's going to use it? Are you building this for, you know,
devs? Are you building this for business folks? Who's the end user? Who's going to benefit from
this the most? And who would pay for that product if they're in that space? And where are those
users most likely to be? You know, are these users going to be at Faustin? Are they going to be at,
like, you know, Open Source Summit? Are they going to be at KubeCon? I mean, like, where will you see
these people pop up? And how do you ensure that you know where they are and what sort of things
that they like and what sort of things that they need? And so you want to understand that really
early on, even if you're not trying to monetize or commercialize the Open Source yet, you know,
you want to keep that in the back of your mind and start to funnel things in that right direction.
Now, the next key is to listen and ask questions. Now, remember, I said a big mistake people make
is the founder builds the software specifically for themselves, and they don't necessarily take
into account other people in the ecosystem. And this is where product success is really determined
based on your users and your potential users and listening to their needs. If you're not listening
to their needs, you're going to be missing out on a lot of opportunity for growth. And that's where
that mistake comes in. So avoid that if you can. The other one is you have to set a goal and focus
on it. Be really good at a few things, not really okay at a lot of things, because there's a lot
of other software you might be competing with. There's a lot of other people who are potentially
solving the same issues. And it's really easy to get distracted by shiny object syndrome. Anybody
get distracted by shiny object syndrome? I'm like that all the time. Yeah, I see hands waving all
the time, right? And that is so easy to do. In fact, I was just talking with Avi, our CEO over here,
and we're like talking about, you know, tracking web page stuff. And I'm like, oh, we could do that
in our product. Oh, but we're like, wait a minute, we that's not our core product. Why would we go
down that hole, right? But people do that a lot. And when you do that, it might be cool. And you
might learn that there's a new subset and there might be a time for expanding your product.
But until your core product has that established base, you don't want to do that.
So don't deviate too often. Okay, stick to that original purpose. And if you do that, you will
eventually find that you become better known on the market. People are willing to talk about you,
use you, and then share additional contributions to maybe make your project a little better.
Okay, this one's a big one. All right, has to meet or exceed expectations. Now, this totally
seems obvious, right? But let's assume that I build a cell phone. And my cell phone has the
awesomest speakers, the awesomest music system, and it is the best gaming platform ever, but it
can't take calls. Is it still a cell phone? If I market it as a cell phone, if I sell it as a
cell phone, if I say, oh, this is my cell phone, it doesn't matter. It's not. So if I'm trying to
build a cell phone, but it is great at just music and gaming, but it can't take a call, I have not
met the expectations of that. And that's where you need to figure out what are the table stakes for
your project? What are the key ingredients? Whatever those are, that's where you have to focus.
And that means do the job that it was originally intended to do, and meet some minimum standards.
And there are minimum standards that we all have from an open source perspective. Okay,
what are some of those minimum standards? Hey, you know what? It has to be secure, right? Like,
who wants an insecure piece of software nowadays? Well, we have too many of them. Let's not add
anymore. But it has to protect from data loss. I don't want leaky data. You know how many times
my personal data has been leaked? My daughter's going to inherit free credit monitoring for the
rest of her life, because I've had so many data leaks. I mean, I think there's several Matt Yankov
it's running around right now, maybe even at this conference. So, you know, you know, it also has to
be as bug free as possible. Now, while we strive, I'll strive for bug free software, we know it's
not a viable thing. But shipping with known critical bugs is bad. And I know some companies who do it
just to meet deadlines. It's not good. Next up is UI UX. Who's anybody any UI UX guys,
any people on here? Okay, awesome. Yes, many, many. All right. Well, so it's like this. If your
product is designed like this elevator, that's really confusing. Isn't it? I mean, UI UX is
probably one of the most important things to get right. The user experience can ruin an awesome
technical project. You can have the best technology out there. And if the user interface sucks, people
won't use it. Or they'll use it once, which is even worse. So a bad user experience can ruin any
benefits that you provide. GitHub is littered with projects like this, by the way. So of the
millions and millions of projects that are out there, many of them fall victim to this,
even if they are really solid. And if you want to grow your community and grow adoption, easy.
Remember, easy was my point number three. You know, you need users who can be advanced if they
want to and get into the weeds. But most of the users won't. And again, that gets back to that
assumption that we build things for ourselves. A lot of CTOs, a lot of co founders, a lot of people
in this space, what they think is, I'm super technical. And they are, they're building a company.
Those out there in the space who are founders, you know, at that executive level, maybe they're,
you know, maintainers of projects, you, you are all brilliant. And that means that your
brilliance probably exceeds your average user's brilliance. That's okay. But keep that in mind.
So make it easy for folks. And my product key number six is community. Okay. Open source
projects need community. And we need to bake that in to the beginning. Okay. And that means
including plans for fostering that strong community up front. Now I brought this up. I was previewing
my slides and someone, you know, said, well, wait a minute, what about curl? Does curl really have
a strong community of contributors? Right. And this is what I say is we have to look beyond code.
This isn't just about code. You want people who will use your product. And if you search for curl,
for instance, um, you know, your favorite search engine, you're going to find thousands of examples
of how to use curl, right? You will. You can do it right now if you want tutorials, examples,
cool things, hacks, whatever, that's community, even if it's not code contributions. And that's
what you need to continue that product growth. All right. Moving on. Now we're talking about
how do we super charge the awareness? Alrighty. So let's talk specifically about community. How
anybody here in the community space? Oh, a few people. Oh, yeah. Okay. Great. So, um, this is the
great hope for adoption in open source companies. In fact, a lot of people will prioritize a dev
rel hire over any of the business hires because they want to start to connect directly with that
community. Okay. And it's, it's, this is a balance, but the community can really help accelerate
and drive that awareness if done right. But here's the thing. Okay. Community is starting to turn
into the new marketing. For the last five years, the last 10 years, um, marketing has often been
in control of community. Community has been a subset of marketing, sometimes a subset of product.
But ultimately, this shift in mindset where the community is so important and it's driving so
many conversations, it's supplanting marketing. And there are reasons that you still need marketing,
but in the future, I think that what we'll see is the community team has marketing as a function,
not community as a function of marketing, which is a different way to think of it.
And that's a real mind shift for a lot of people in the business space. But if we do approach this
from a community first approach, we can accelerate and grow the open source space even faster.
And that gets back to this expectation, right? So when we talk about that expectation, I mentioned
earlier that funnel, the flywheel, you know, when we're talking about, Hey, can we have people in
the community who talk about us and then turn into followers of us who then continue to watch
our things and then who continue to try and use our software in different ways, that's the ultimate
outcome that we want. And when we talk about this community team, there's multiple functions in it.
This is a chart that I've used several times before, but, you know, we're talking about
DevRel or evangelism, we're talking about community management, we're talking about these
OSPO roles with contributors, all of these things are part of a strong community team.
All of them need to be satisfied. Now, a lot of us will focus only on evangelism,
and then they won't do the other functions, or they'll focus only on the contributors and not
do the other functions. And so all three of these are needed for a healthy, healthy ecosystem.
Now, what are some popular ways to grow open source adoption? Okay, these are probably obvious
for anybody who's been in the open source space for a while or been in the community, but they're
classic, right? Content, number one, right? Content, everybody loves content. The more relevant
content that you have, the more code examples that you can share, the more conference talks that
are relevant to people, the more blogs you write, you know, those will make a difference,
tutorials, sample applications and whatnot. All of these things are things that are important to
those in the community. There's other activities you can do, especially when your product solves
something that's newsworthy. Has anybody heard of the term news jacking? No? Okay, a couple of
people. It's the idea that, you know, if there's something in the news cycle like, you know,
oh, the latest hack, and, you know, or whatever, if there's an opportunity for you to maybe talk
to people about how to build better products, if your product or your company does something
differently that solves these other issues, this is a way for you to use the stories that are already
out there to reach additional people. You know, if somebody's hacked or some cloud provider goes
down, well, this is how we would prevent that, you know, or here's how our software did this
differently. Those types of things actually can have a really far wide reach because those are
things that are on top of people's minds. Now, you also need to generate friends telling friends,
right? So that peer-to-peer connection, if you will, of people who are willing to share their
experiences and share the different, you know, goodness of your software. And that goes hand
in hand with some other things like good messaging and products and making it easier to start.
Now, how do we make this easier? That's key. The first one is it requires a lot of collaboration.
It's a choreographed dance, okay? So making this easier is you have to have not only easier products
to use, you not only need a great user experience, you also need to make sure that you have enough
information, enough tutorials, enough example code, enough out there in the community activity
to merge those together because you have to have good product as well as strong community,
as long as strong content, good documentation to make this work. And so that easy is important,
but it goes beyond just one team's function, you know, and some of those key things or some of those
things that I see people sometimes stumble with or sometimes fall down on are things like installation,
you know, so how easy it is to install and get started. Same defaults. How many people have
installed software and it's like, how did you not set that up? Like, why isn't that defaulted to on,
you know, like encryption? Oh, encryption is just left off by default. Or my favorite is,
and I don't even know, maybe there's somebody here who's run Mongo recently, but they used to not set
a default password because they're like, oh, we don't want to limit people from getting started.
Well, how can you not set a default password? By the way, that's the number one reason MongoDB
has like data leaks, you know, you read these articles and it's like, oh, because these old,
you know, these old installations didn't set a password. I don't consider that a security issue,
that's more of a user issue, but that's a whole other story. How much automation do you put in
place to help users? That's another critical one. Again, UI UX and how easy it is to debug
problems. You know, if your problems, if the software crashes or has an issue or doesn't work
as expected, do you have the right debugging in place for people to actually find what's wrong
and fix it? Because if not, that's going to cause a really, really, really hard time in
getting people to operationalize it. So we talked about, you know, kick-ass product,
we talked about, you know, the awareness, we talked about, you know, how to make it easy.
Now I got to put on my other hat. I do have another hat. It's my metrics hat. I got to wear my
metrics hat for my metrics section of this. So we're going to talk about how do we track
open-source usage and adoption now. Okay. And there's really kind of four or five major functions
that I want to talk through. Awareness, usage, conversion, customers, and retention. Okay. And
this kind of follows that funnel and that flywheel that we talked about originally. This is one of
those things that, you know, each one of these requires a certain set of things to potentially
look at. You don't have to look at all of these, but these are metrics that you should all consider
and then pick and choose which ones make the most sense for your business. But when we talk about
awareness, okay, a lot of people start with the first one on this list. So how many people
track GitHub stars? Okay. Hey. You know, GitHub stars are a popularity contest, by the way. Did
you know that? Like, it really is. Because it actually doesn't really show much other than
people like your project or maybe they like people on your project. And did you know that for
only $5.99, I can get you 1,000 stars on GitHub? There are services that do that. And so I don't
know how many of the stars are actually real or not on some cases. It's hard to tell. But you
should be looking at that because if it is going up into the right and you're not gaming the system,
that is a good indication that people are finding your project. But keep in mind, from a project
perspective, there are more users than there are users who will go to your GitHub page and get
into your repository. And that's something to consider. Unless you're forcing people to go and
install, you know, via source or your documentation on GitHub, you might have more people who are
downloading some other mechanism. Maybe they're getting from a third party repo. Maybe they're
just going to your website and getting it. So they might never go star or even see your GitHub
pages. But looking at not only GitHub pages, but your traffic to your docs, your website, your
different pieces of content and understanding who's interacting with it, that's another critical
piece to this. And that's a classic marketing thing. A lot of people look at, you know, the website
traffic. But you also want to look at those unique views to each individual page. All of those
are critical to look at. Now, what's interesting when we talk about page views is we've had
conversations with folks who talk about page views and they're like, there are certain pages that
don't matter and then there's certain pages that do. And so understanding and being able to segment
your traffic and look at who's looking at what is a very important thing to understanding that
growth and adoption. So for instance, if someone looks at your pricing page, that's probably a
good indicator that they might be interested in something commercial. If someone's looking at
your documentation, that's a pretty good indicator that they're trying to install or debug an issue.
If they're looking at tutorials on how to get started, that's a very good indication that,
again, they're trying to use your software. And so you can track adoption through looking at those
types of things. Now, when we talk about external evangelists and trying to get additional people
into the ecosystem to talk about you or to figure out what you're doing or maybe get excited about
your product, looking at the referrals to the website is another really good example. So I can
see your blog or your blog pointed back to my website or your social tweet mentioned me. These
referrals are often more critical than the website traffic on itself. Now, there's also two concepts
that are really squishy. I won't get into a terrible amount of details if you're really
interested, check out opensourcemetrics.com or.org. But share a voice. Have you ever heard
of share a voice before? No? Okay. Think of share a voice is how often does the project or the thing
come into people's minds or how often does it show up in search? How much of the market do you have?
So, for instance, if I was to say to you, like, you know, when I say Linux, what pops into your
mind? Like, what distribution pops in your mind? I'm going to guess most of you are probably going
to say one of, like, three or four. But there's lots of other ones. And so those three or four
have a higher share of voice than everyone else. And so if you can measure how much of your share
of voice is, then you know how much of the market you potentially, you know, can reach out. And then
when you have something to say, people are going to potentially listen. And then there's this idea
of social reach. Now, probably everyone here has different social accounts on different platforms.
And that's awesome. And the question is how much of a reach do you have? And this is, you know,
measured by the number of followers, the amount of engagement. And the reason you want a larger
social reach from an awareness standpoint is when you do have an announcement, when you launch a
new product, when you talk about a new release, when you do have something important to say,
this helps amplify that voice. Now, from a usage perspective, usage is where the adoption really
comes into play here. Okay. Usage is how many people are actually using your software? All right.
Now, I know a lot of companies have struggled with usage on the open source side. There's a
lot of times people come back and they ask the question, well, who's using our open source
software? And the answer a lot of times is, I don't know, you know, certain number of people,
this number of people hit the download web page. But there's so many different places to get,
you know, that information. I can't really get it. But some people can get raw download numbers.
Anybody look at download numbers for their software? A few? Okay. It's hard to get. It really
is, especially when you're looking at, you know, I deploy via Docker, some people are doing source,
some people have packages. So that is a challenge. But it's important to understand if there are
more people downloading, that's good. But you have to be careful. Because a lot, oh, I'm going to
tell you a secret. There are a lot of bots on the internet. I don't know if you knew that. Don't
tell anybody. And those bots download stuff. In fact, what we've found is a lot of times we might
have a project. And so one of the things that I mentioned that SCARF does is it tracks, you know,
things like downloads and download metrics. But what we found was stuff like, oh, this project
has, you know, 50,000 downloads a month from two people. It's like, well, wait a minute. There's
only two people actually downloading. So when you see 50,000 downloads, but you see only like
two unique people, you're like, well, what is that? And then you dig into it and it's some bot
that's downloading it and distributing it some other way. So that's important to realize that
that is something that can happen. You want to look at that. But you want to look at that scrubbed
unique download. So how many people are actually downloading versus how many people are, you know,
just downloading and it could be bots or duplications. A lot of companies download the same
software over and over again. A lot of people in their pipelines will download the latest
version of software, et cetera. New users, new companies coming into the ecosystem. That's really
important for usage. Sign up. So if you are a SAS provider, you're offering a free trial. Maybe you
have a webinar. Maybe you have a mailing list. Maybe you have Slack. Sign ups are another thing
that you want to track for usage. But that's not necessarily going to correlate to actual usage
of the open source. But again, that's more of a directionally correct up into the right.
You know, so the one that is really on the bottom here, the last four, this one's sticky.
Okay. This one, this one's tough for me. Call home metrics. So most of the people in the open
source space hate the concept of anything that's going to call home. Right? It's not necessarily
always welcome. But there's a certain amount that might be needed for projects. And the question is
where is that line? Right? And when I talk about call home metrics, is something running, is it
installed? You know, is it available? How many things are running at any one time? These are
critical questions that a lot of projects struggle with. Because just because even if you have a
download doesn't necessarily mean that download actually translated into an actual user. And so
you want to make sure that you can go back and forth between, you know, yeah, they downloaded,
but they stopped using. Because if they downloaded and stopped using or never actually, you know,
use it on a regular basis, that's a very different thing than someone who's just downloaded and you
assume that they're using it. Now, when we, before we get into conversions, I want to say that just
because you have adoption of your open source software doesn't necessarily mean that that's
going to lead to commercial success. Okay? How many people, I mean, there might be some people in
here and maybe you're willing to raise your hand. But I know that several people that I've talked to
struggle with this where they're like, I have a million downloads a month, but I can't get anybody
to buy anything from me. You know, oh, yeah, there we go. We have one brave soul. That happens quite
a bit. And, you know, it gets back to some of those product things. And there's a lot of reasons
or things that you can do to try and change that. But, you know, it gets back to this expectations
on the awareness versus, you know, you know, what the business expects. And from a metric standpoint,
you've got the two sides, right? So when you talk about the community side, the adoption of open
source side, you know, a lot of times our efforts are around fostering that really strong community.
And then there's this big question mark in the middle. And then on the business side, then
there's, oh, now we want, you know, ARR, now we want, you know, to look at expansion numbers and
churn and all this other stuff. So how do you bridge the gap between these two? And this is
where conversion comes into play. And conversion is a bad word for people, right? You know,
yeah, you will be assimilated. You know, we want that from the open source side, right?
Might be a negative connotation, but I think it's funny. But I do have a super evil villain hat.
But you do want those conversion metrics. You want people to say, okay, what does it take to go from
free to paid? And to measure that, okay, there's, you know, different things to look at, right?
That conversion is impacted by a lot of different things. And each one of these are things you
can measure from a product. You know, you want better features, better security, you know, you
want support, things like that. From a policy perspective, you know, companies often will
require support or they might have compliance requirements. How do you meet them? And then
people, right? So all of these things affect your conversion ratios. But looking at conversion
ratios, you can actually control. You want to look at things like page docs or source to download
conversion ratios, doc views to those who have downloaded to those who eventually signed up,
if you can track that, that's great. I know that in the past, I've had to go through and do stuff
like that where I've seen, I mean, actual example where it's like company A, there's really large
company four years ago started looking at our blogs. And then they attended conferences, they
did all this other stuff. And then two years, they called us up and had a conversation. And then
a year later, they did something else. So there are breadcrumbs when you look that you can actually
see what people are doing and what sort of activities help lead them to be a customer.
Now, customers, when we talk about customer metrics, we're talking about standard business
metrics. So these are the ones that most people who are running an open source company are familiar
with the critical ones, things like the number of new customers or new logos, ARR, MRR, you know,
stuff like that. So I'm not going to go terribly deep into this because there are MBA courses that
cover a lot of these and I don't want to necessarily go in depth. But the ones that I look at typically
the big three, number of customers, number of new logos, and yeah, the ARR, MRR. And then also,
I look at the user to customer ratio. So if you know you have a million users and you have only
five paying customers, how do you adjust that? How do you tweak it? How do you make that work better?
And then I also look at the number of customers who are also advocating for us. From a retention
and churn perspective, churn is the idea that people start using and then go away. So you want
to look at those. You want to look at the number of instances that have gone away. You also want
to do some competitive analysis, right? So if you have users and customers who are starting to use
other open source projects or take a look at other things, you might want to be aware of that.
So recapping, not all businesses, open source businesses are the same. Realistically,
build an awesome project, focus on the funnel, and of course, measure it. All of these things will
help lead you to open source success. Again, if you are interested in getting more details about
any of the metrics or learning a little bit about what's been successful for other folks,
check out opensourcemetrics.org. You can contribute to it if you think that there is something that
is missing, something that you think we should work better, definitions, et cetera. We would love
to have your feedback and help there. Details, if you want to reach out to me, be happy to have
conversations with anybody offline. And that is it for me. Questions? Oh, we got one question.
We're running mics to people in the crowd, it looks like. Oh, it's not working. Okay. Well,
maybe you should shout. Maybe now. You mentioned collecting metrics from users, but because of
the GDPR, you need informed consent that you're allowed to collect metrics. In your experience,
what's the percentage of users that actually allow to do that? Is it like 1% or 10%?
It's generally more than you would think. I mean, it's at least a third, maybe more.
And beyond that, there are metrics that aren't tied to PII that can show those indicators going
up and to the right. So just because you know that you have web page traffic or downloads,
even if you don't know specifically who they are, you can still see those up and to the right,
and those are just as important in a lot of cases. And that's why you have to pick and choose,
which ones make the most sense. And in a lot of cases, what it is is it's about building that
community and that relationship, so they're willing to share details. And how you do that and how
you make sure is you don't do kind of like old kind of slimy sales tactics. Like you don't want
to spam people, you don't want to call them. Look, let people raise their hand when they're ready.
And that helps people a lot. And when people go to bat for you and tell you, you know, other people,
hey, you should sign up for the newsletter, you should sign up for this. And then they give you
that consent. That helps a lot. Thanks. Yeah. Oh, other other way, other way. Yeah. We had a couple
more questions. We've got one in the middle, one in the end, one down here.
Oh, hello. Yes. Okay. So I was one of the folks that raised their hands when you asked what,
what do we know, open core. So I don't, but then you started explaining and I say, okay,
that's like freemium. So I just was asking, could you explain the difference between open core and
freemium? Ah, so, yeah. So freemium is where, you know, your first taste is free. And then,
you know, you can, you can get more later on. Open core has been around a lot longer than,
quote unquote, freemium. Okay. And typically from a freemium strategy, you're going to pay more as
you go. And so having like a cloud service where the first, let's say, 100 gigs of data or something
that you store is free. And then it goes on. That's more of that freemium strategy. But from an
open source perspective, how I view open core is you've got a complete product that's running.
You don't have to pay for anything. And if you wanted to augment it or change it on your own,
you can. I think freemium typically comes in my mind and more into play on the cloud side,
where you've got more of that, you know, kind of like ongoing service where you're paying for
something where you can't necessarily replace it or pull it out. But it's a fine line. And it's
really difficult to draw that line. And a lot of people might go back and forth. Oh, it looks like
our time is up. I'm happy to answer your question if you want to come down and we can, we can chat
afterwards. That's cool. I appreciate your time. I do. Thank you very much.