Ben Rometsch
Ben Rometsch
Dec 16 2020

Interview with Uku Taht and Marko Saric: Founders, Plausible

Interview with Uku Taht and Marko Saric: Founders, Plausible
Listen now

Episode Overview

In this episode of The Craft of Open Source, I caught up with the co-founders of Plausible.io; an open source alternative to Google Analytics. After originally launching the project privately in 2018, Uku Taht decided to move towards an open source license. After doing so, the project began to gain momentum and now has thousands of companies and organizations using Plausible instead of Google Analytics. About six months ago, Marko joined him as a Co-Founder and they are now growing the product and community organically.

My favorite quote from the episode came when we talked about their goal for starting the project:

"What got us together was this point of Google that I discussed. We have a similar background in terms of our relationship with Google and Google's products and how that has evolved over the last few years. We both went from somebody who's used their products all the time, recommended them to friends and family then suddenly to like, “This is not as good as we were thinking. Maybe there's something that's gone wrong with them and turned evil.” To go opposite and like, “You should use this completely better alternative rather than the product I was using years ago.” That's the main goal behind the project. It’s the idea of allowing a web analytics product that's useful and accurate, but at the same time is compliant with all the regulations and privacy-friendly to the people of the web and the non-technical people that are visiting the websites.

Our goal is to get that out to as many websites as possible and reduce the hold Google has over all the websites, but depending on what stats you look at or what study you look at Google Analytics is installed on some 55%, 85%, to 90% of all the websites on the web. If we can move that percentage down by a couple of percents or more, that is the goal. Every extra website we can remove Google Analytics from is a step closer to the goal we have."

Hope you enjoy the episode. Please feel free to leave feedback in the comments section below.

-Ben

Episode Transcript

First of all, I wanted to thank you for giving up your time. Where are you guys at the moment? Are you both in the same place?

We’re working remotely. We never met each other in real life.

We started working on the week as they went to lockdown. That's when we started working together as cofounders. We haven’t been able to travel. We would have probably met this summer.

We have to get together, signed some documents and so on. Probably it won't happen until after the vaccine or things get back to normal.

It's funny because Flagsmith took some investment and some of the guys that invested in the company are also providing some time to do some of the go-to-market stuff and we've never met them either physically. It was weird. That's the new normal.

You got to get used to it.

How old is Plausible? How old is the codebase?

It was Christmas 2018 when I started working on it.

You guys only met up in 2020?

Uku worked on it. He released the first version last summer 2019. Earlier in 2020, in February perhaps, he emailed me and reached out to see if we can work together and focused on the communication and marketing side of things. I think mid-March when we started. It was Monday that week. We started since then.

Tell me what the genesis of the project was like? What caused you to put down that first commit?

The first commit came the biggest. I was working on a completely different product, a failed startup with a couple of my friends in London. The marketing person there, I wanted some more analytics data and he asked me to install Google Analytics. I felt uneasy with it. I installed it for his benefit but I was looking into some of the alternatives and self-hosted solutions and things. I didn't find a solution that clicked with me that I thought was what I wanted at that moment to install on this website ticket to have actionable data for a marketing person without having Google as the middleman there handling the data. It was a distrust towards Google and not finding a good alternative of myself that I felt was suitable at that moment.

It feels to me like it's quite a big task to take on an analytics product. You're having to deal with potentially large amounts of data performance issues, things like that.

Starting small, I made it technically a naive solution. It was using PostgreSQL storage page view as a row in the database, which gets too inefficient quickly. I've had to rework a lot of it and change the databases and change a lot of what's going on in the backend. I wrote a blog post when I started it. There were three main reasons why I wanted to do it. One was to try to build an alternative in that space. One of them was as a learning thing myself. I wanted to learn that space because the handling of these massive amounts of data is interesting like, “How are you going to make that work on a database level?”

It helps amplify everything when a big website features you.

I worked on some large projects, but in my experience, whenever the database goes beyond a few million records, it gets a bit tricky performance-wise. We ingested over 80 million records last month. It's been interesting to get there. The third reason was that I've been a fan of this Indie Hackers movement for ages. I wanted to launch something and see if someone will pay for it. That was one of the motivations was to build something and put it out there because I'd never done that myself. I've never launched a product in the marketplace.

Was it always in your mind to make it open source from the start?

It wasn't open source to begin with. Open source is a bit later on. It was on my mind to open sources from the beginning. The reason why I didn't was that I had a bunch of building code in there and some code that I thought was going to be sensitive and maybe we shouldn't put and make it open. Six months after I started the project, I asked some of the people in that space whether this was an issue. As long as I keep my secrets secret and I released the code like the billing or user management and whatever I thought was a bit sensitive. I was assured by some other open source maintainers it's a non-issue. That's when I open source with the billing code, it's open now. If you don't know the API token, then it's not helpful to you. I was initially scared of open-sourcing because I was afraid that someone would exploit or do something with Plausible that wouldn't have happened otherwise. It's been striking to the codebase. I get security reports from people saying enhancing the security rather than taking advantage of the open source aspect of it.

I see you've got 1,500 stars on your repository, which is ten times what we have at the moment. Did they happen naturally? Did you make conscious efforts to go out? What was the number, Marko, when you hear it?

Maybe 500. Now we’re at 4,300. I'm a developer, first of all. I didn't even realize that there's any value in GitHub stars. We did not go after like, “Let's get GitHub stars,” because I don't see what's the big fuss about all these stars. When we reached 1,000, Uku was like, “We reached 1,000.” I was like, “I did not even know that we had this star.” There were no growth hacks or whatever we did intentionally to get these GitHub stars. It happened as a result of the whole platform, product, and project growing. That comes because of the content we posted and some of the other things we've done to get out to different communities such as Hacker News, Lobsters, and stuff on Twitter. By being an open source and on GitHub, people also find us there and some of them like it. We have quite a few stars. We've been trending a couple of times as well on GitHub Trending. That helps too. The whole product project grows and you're getting traffic and getting people to talk about it. By being on GitHub as an open source project, you will have that side of things grow as well.

There's no single thing that we do that works that we can repeat. We've got to do like twelve things constantly all the time and then it slowly seems to build a little bit week by week and month by month. Is that the same experience you guys have had?

The biggest spike we had was the first blog post published. We started working together in mid-March. I published the first blockbuster first week of April and on that exact date, we had maybe 30,000 or I don't know how many visitors because of that one blog post we published. There have been some other blog posts since then with similar results, maybe 3, 4 of them. That's over a period of 6, 7 months. All that time in between those 4 or 5 blog posts that went viral and crazy, there's been all of this putting the effort, talking to people, communicating, a small step at a time, small achievement at a time, and getting one customer at a time. That builds up the growth over a longer period of time. That's what works. These huge spikes because of stuff that goes well on a big platform or somebody, a popular share. It's when a big website gets features you, that's what helps you amplify everything. The day to day work is the actual award that delivers the results and that keeps the growth and momentum going.

Those stars, what do they lead to other than a nice feeling? Do you get more contributions, sales, or what do they translate into?

As a developer, I look at the stars and GitHub repo and to me, it means that the project is legit. That's more trustworthy when there's plenty of stars. Everything we started working together, I was trying to explain to Marko, “Developers care about these stars.” When I'm comparing open source projects, I often compare the number of stars as a proxy for like, “Is this thing being maintained? Is there stuff going on? Are people talking about this? If I have a problem, can I get help from someone else who was using this project?”

It's a social signal and in a way it's meaningless, but on the other hand, it means everything with an open source project. It's difficult. Something concrete that happened. There's a venture capital firm called Runa Capital that compiled the list of the fastest-growing open source companies. Their methodology was to take GitHub repo and look at their quarterly increase in get up stars relative. Not an absolute growth, but in terms of relative growth. We topped the list for Q3 of 2020. That got picked up by TechCrunch. We got some traffic and the link from TechCrunch. Thanks for that. That was a material thing where it helped to get in front of more people.

I spoke to Michael DeHaan who started Ansible. I get the feeling that he was on the back of this wild horse of trying to maintain this monster open source project. Are you guys getting lots of strangers contributing?

Not as much as we would like. I tried to encourage it but at the same time, it's a hassle to deal with a bunch of contributions. There's a balance I'm looking for with it. At the moment, we've had maybe in terms of real code, there's always fix the typo in docs PR. As I know an actual feature, maybe there have been 2 or 3 contributions that are sizable. I do something that would have taken me time to build. It's not that many, it’s few. It's been picking up quite a lot because we released version one of self-hosted Plausible, which means there are a lot more people running the code on their servers. It's invented more of hacking on it mentality by people.

The code has been open for how long?

The code has been open since 2019.

You mean you made a simple path to self-hosting?

It was open. There were some people who downloaded the code and figured out how to deploy it. Before that, we were running on Heroku. I didn't have any infrastructure code written or any Dockerfile or anything for people to run it. The code was open but we weren't encouraging people to self-host. I perceived it as something that would take away from actual product development time-wise. I felt that the Docker set up for self-host was contributed from the community. Once it became a thing, we released the beta with community contributions, then I felt like I need to finalize it and release an official version one of the self-hosted solutions.

That's interesting because we've been trying to find literature and discussions about this. Having debates internally about having some open source projects have deployed to Heroku Button at the top of their GitHub ReadMe. We've always been like, “Is that a good idea?” As projects get larger, they can become more technically complicated. The infrastructure can be more complicated. By sheer size, they have to have this complicated deployment path. Ours is still fairly simple at the moment. We find it hard to get opinions on what the benefits are of making it. You can do the work to have one click on AWS, GCP, and Azure. Can you talk about your discussions about that? Were you both in agreement straight away?

Not quite. We were still hashing that out. It's not something we have a concrete stance on, especially those one-click install buttons. On one hand, if someone wants to self-host as possible, it's a nice convenience for them. On the other hand, it feels like DigitalOcean or Heroku competing with us because they make money from it and we don't. It's conflicting for sure. We don't have the answers. I’m happy to talk about it further. Marko, did you have some thoughts?

I have many thoughts about this. One thing that happened since we released the self-hosted was that suddenly, several bigger companies reaching out to us. It was in the sense like, “We want to use this self-hosted product and we want to sell it to our customers. We want your help to set it up, but we cannot pay you a role. They will give you good publicity.” That has happened several times.

It's like people who run hosted WordPress sites.

This has happened several times since our release of self-hosted. For me, this didn't make sense. They are larger than us. They have tens of thousands of paying customers. They want to charge for Plausible to these customers and they want our help to help them enable that but they're upfront by saying, “We cannot pay you. We don't want to pay you even if you become hugely successful in selling Plausible. We don't want to contribute anything back to your project, but we still want your help. We will give you some publicity.” I’m like, “We don't need publicity. It will be nice with some support from these people.” What happened is that one of the first things which were unplanned was that, “We need to change the license now,” because we were on a permissive MIT License.

One of the posts that went viral was when we announced, “We are now changing to AGPL.” This was a direct response to us releasing the self-hosted and several companies coming to us and saying, “We want to use this for commercial purposes to charge money for it to our customers. We want your help, but we don't want to contribute back.” We were like, “How can we minimize this incentive from these large corporations to come in and take advantage of our permissive license?” We were researching and AGPL probably the best open source license that's approved by everyone.

That helps SaaS products that are hosted in the cloud. We changed the licensing in order to say, “If you don't plan to contribute, maybe it's not something you should look into because with the AGPL, you have to open source any changes you're making it and so on.” It's a big topic and I assume every open source project has big discussions about easy self-hosting license. How to deal with all these larger corporations that want to take advantage of the work you're doing without contributing back to the project.

Talk about a little bit more because we've been going through the same thought processes. Everyone seems to be grappling with what's acceptable for the community and how to build a sustainable business. I’m a WordPress hoster and people are paying me to hit WordPress patch which I probably don't do well. Before your license change, I could take your code, white-label it, and charge people for it, right?

With MIT License, you can do whatever you want. There are no restrictions. That's what the license says, “You can do whatever you want.”

How has that changed when you changed to AGPL?

The difference is if you are going to do something to the code, such as change it to something else, you have to open source the whole thing and contribute it back. Make it open source to make it available. The original project can use it if they want to. The big difference is that it makes the playing field more level. Large corporations cannot start with what we have and take advantage of that and go one step above us because of their capacity and resources. Whatever they do with the code, they'll have to help pass to enable us to use that ourselves as well. That's a big difference.

If they wanted to plug in their billing system or login system, they would then have to publish that code or legally they would have to whether they do or not.

Many companies are after the brand name because they've seen the growth and the buzz, and they want to get on that train. 

Part of the reason to be an educator, because most commercial companies, especially these mega-corps are antagonistic towards the AGPL license. They're not willing to incorporate that into any of their products.

They want to keep your arm's length.

Something like Amazon probably not going to sell an AGPL licensed product because that would be a huge risk for them. I want those to speak to the case of these WordPress hosts. There are many of them and they're everywhere. They might not even want to necessarily change anything about the code. They might want to take as it is and sell it to their customers, which are technically allowed with AGPL. They have to publish the source code, which is already published. It sounded it could have but with those companies is we can't stop them necessarily from selling it.

That's the spirit of open source is you open up the code for commercial use by others. What we can do is keeping an API module. A closed source as a proprietary add-on. Something we see many open source companies go towards is by selling proprietary add-ons essentially. That's enabled certain use cases. If you're a big posting company with a bunch of customers and you'll need an API to work with Plausible, that's the thing that we would probably license to those companies. The open source part, they can take and run it as they want, but it's inconvenient without an API.

Have you thought about whether you would keep that completely closed or make it public, but licensed in such a way that they'd be breaking your terms? That's another thing that I want to try and avoid having like it's easier. It makes life easier having one repository and not having to worry about building different versions of the application and things like that. I saw some companies have a nice little solution wherein their root license, they point to a folder called enterprise or something and say, “Anything in this folder is licensed differently but it's still on GitHub and you could still run it.” You'd be breaking their license, which was quite a nice elegant workaround.

They haven't reached this point yet. API, we haven't even started developing but that would be an ideal solution also for us. All pen, like everything else we do, the people that we created Plausible for, they can do it and use it whatever way they want. If you want to use it for commercial purposes, sell, and resell it, you want this easy accessibility to create hundreds and hundreds of websites immediately through the API. You will need some commercial agreement and license deal with us. It's something we haven't done yet. It's something that we will have to decide in the upcoming months before we released the API and figure out what's the best approach.

This whole thing with the AGPL is something we didn't plan. It was something that came up because of these concerns we've had in these threats. We've seen from this commercial to large corporations. The next step will be to figure out what is the best approach and see from people like you the examples you know and others in the community. How can we do this to still stay with our roots, our open source, and everything to protect ourselves from these parasitic threats?

It doesn't seem we've done a lot of reading about this and we're about to make some changes to our license in a seminal way. To try and you'd be still in a state like philosophically open source, but we want to build a small business around it. Unlike a lot of things, when starting a project like this, there's no consensus about this. There are lots of different ways you can approach it. No one seems to have like, “If you want to do that, then everyone has this same path. You do this and use this license and that's it.” Even to the point where the larger companies like CockroachDB have written their own license, which is specific to their use case. It's something that we've been not struggling with but I'm sure that the solution we come up with will work whether it's the most elegant and the one that serves us over time. I don't feel like you want to be changing the license all the time as well, or ever. One question I do have. If I download and self-host the platform, do you get any instrumentation that that's happened?

Zero. I was writing the recap and I don't know how many self-hosted installations there are because we have zeroed telemetry from the self-hosted installations. I will never add it opt-in by default. We don't know. There were 36 support requests relating to self-hosted. The actual number of installations is probably in order of magnitude or something like that.

We published a century key. We sometimes get alerts from domains that we'll see like in the deepest and darkest recesses of some of the company's intranet. Early on, we saw that the financial times had fought our repositories. I’m excited about that and got in touch with them. They said they were using it and I asked them to sponsor it and they'd said, “No.”

Are you MIT- licensed as well?

No. We are BSD 3. We're about to put some of our features behind a more restrictive license. I feel that if you're at that size of the organization where you have to have role-based access controls to manage your feature flags, you can probably afford to contribute some money. It doesn't have to be a lot, but it's a lot cheaper than the commercial offerings. I'm not quite sure. We've emailed a couple of people who've been contributing to the API and saying as a sounding board like, “How do you feel about this? Is this going to piss you off or upset you? Are we wrong?”

People are quite understanding. If it means that you're going to we're going to write a bunch more features that are going to improve the project then and you can still write your own role-based access control if you want to. No one's done that yet when we moved that out. We're still trying to figure out what the best license going forward is and it's a bit of a balancing act. You want it to be as open as it possibly can be. The two things that we were concerned about were large organizations using it in production and without any contribution back. Someone's setting up hosted Bullet Train to IO and providing a pure SaaS-hosted API, which we think would not be right. I understand that philosophically doesn't make us a purely open source, but I'm okay with it.

Something we've been looking into for that use case is for that case is how strict we can be with our trademark because it's possible that you get through to the spirit of open source, you can take the code, host it, and run it, but you can't call it a plausible. You can't call it a bullet train. You have to build your own brand with it if you're going to do that. That's something that would be beneficial but I'm not a trademark lawyer. An open source trademarking is interesting. It's separate from the copyright on the code, the trademark applies to your name and to our logo. This is something we've been discussing. Is it the code that's valuable here or the brand that we're building? They're separate.

After this post about AGPL that went on Hacker News, I had a call with a gentleman from Red Hat and his concept was to separate the code and the project from the brand, these are two completely different things. DigitalOcean does not want the code from GitHub. DigitalOcean wants Plausible because they've seen all the growth and they've seen how many people like it on the comments and social media. That's what they want in order to get some more customers because they want to stall that on DigitalOcean. If you can disconnect the brand itself and have the trademark or some rights, you can decide. If you get into discourse agreement, yes, you can use this because of this reason, but if not, then you cannot use our brand name. That removes even more of these concerns. Many of these companies are after the brand name because they've seen the growth and the buzz and they want to forget on that train.

You're saying that if DigitalOcean had a landing page, someone a Googled self-hosted Plausible, and they had a landing page which had your logo on there and your name with a one-click button. Do you think you'd be able to prevent that?

There are different ways to do that. This is all brand new for us. We didn't even consider any of this. It's something like they are taking it one step at a time. If this comes up as an actual situation that they cannot control in any other way, then there is some space there to play around with this, the trademark and the brand itself compared to the code, which can be seen as completely different.

I saw you guys are on Elixir, Phoenix, and Beam. It’s like an evening project teaching myself some functional programming, which from someone who grew up in the ‘90s, learning C++. We chose safe like Django, PostgreSQL. Keep it super simple. I want it to be no craziness. You're not totally out there in terms of a platform and stuff, but do you think it helps that you're doing something that's a little bit less run of the mill?

It helped us in the way that the elixir community has picked up the project. It's a small community, the word gets out fast, that's been useful, but in terms of contributions, it's some limiting factor. If it was Ruby Python in Java, more people would be able to contribute. They were restricting us in the sense that a large corporation might not want to maintain an Elixir project.

It was more from a community point of view like the Phoenix framework and people champion you a little bit as like, “Here are some guys that are running on our platform in production, etc.”

There's José Valim who is the creator of Elixir. He's been helping to promote us.

That contributes from there.

He founded Dashbit, they offer an electric development subscription. We can pay them to review our code which I'm planning to do at some point because I would love for them to be involved. I'd like to contribute back to Elixir itself.

Do you play that angle from a marketing point of view as well?

It has happened organically because this is a new growing community and there's a lot of buzz behind the Elixir. I'm not a technical cyber. It doesn't matter which codebase you're working on it. That's not something that I would use in a communication to an audience. That is looking to replace Google Analytics on their website. That's something that's irrelevant to the majority of them. Not directly, but it has helped, we've had to share some Twitter from these bigger personalities within this community. It's a certain aspect of our growth comes from there.

There's Django and I love it. We've used the Django REST framework, but there are thousands and thousands of open source projects that are built on top of the Django REST merch. You're a small fish in a big pond.

That helps to get on the wave, if there is a wave and a language is growing, more developers are coming to it and more projects. If you ride that wave, you will get some benefits from it rather than PHP or whatever is that something that's established. It's everything else in the way you communicate. For example, Veer. Veer is doing the pre-operative first. It’s the opposite of the Google Analytics platform. There's a wave of people caring more about privacy and in all these regulations as GDPR, all this the bad stuff that Google is doing, and then many people are vocal against it. You can we are riding that wave as well. We are riding the Elixir wave a bit, but we're also writing the wave of privacy and people getting enough of Google base. If you can get on a wave like that, it helps in the way you can communicate. It helps build the community and the engagement around your brand.

Uku, are you doing anything crazy in the Beam VM that you wouldn't be able to do in Python? It has some weird properties.

Without the community, we couldn't grow.

I don't think we're quite there yet. I don't think we're doing something so crazy that you couldn't replicate that on Python, Ruby, or YMAL. Most of the work is done by the database.

My favorite Erlang stat is designed for a telephone switch. They achieved 99 for reliability in the telephone switch. Every time I read that statistic, it completely blows my mind.

It was developed by Ericsson for telephone switches. José puts it well and he says, “The Erlang VM is excellent for anything running on top of a socket.” As long as you're doing networking, it's great. IO over sockets is so fast. Something that's built into it is the ability to cluster for service to talk to each other, essentially, and to manage a cluster. This is something that we're going to get into. Over time, our solution will become quite special in terms of interacting with the Beam VM and doing things that we couldn't do in other languages, especially when we moved to multi-server deployments, it's still a single server.

You've got the foundation there that you wouldn't have if you were running in Python.

I never doubted the choice to go with an Elixir, it's excellent and it's perfect for the use case. I'm more of a generalist and anyway, most things can be done in most languages and then it's more a personal preference than anything else.

Before you agreed to work together, did you feel like you had a shared goal that was fairly similar? There's a wide spectrum of ending places that you could potentially end up in 5 or 10 years.

What got us together was this point of Google that I discussed. We have a similar background in terms of our relationship with Google and Google's products and how that has evolved over the last few years. We both went from somebody who's used their products all the time, recommended them to friends and family then suddenly to like, “This is not as good as we were thinking. Maybe there's something that's gone wrong with them and turned evil.” To go opposite and like, “You should use this completely a better alternative rather than the product I was using years ago.” That's the main goal behind the project. It’s the idea of allowing a web analytics product that's useful and accurate, but at the same time is compliant with all the regulations and privacy-friendly to the people of the web and the non-technical people that are visiting the websites.

Our goal is to get that out to as many websites as possible and reduce the hold Google has over all the websites, but depending on what stats you look at or what study you look at. Google Analytics is installed on some 55%, 85%, to 90% of all the websites on the web. If we can remove that percentage down by a couple of percents or more, that is the goal. Every extra website we can remove Google Analytics from is a step closer to the goal we have.

In the time we have worked together, we announced were running on more than 8,000 websites with content of more than eighteen million page views in one month. From speaking to most of these site owners, it's quite an accurate stat to say that at least 9 out of 10 of them have run Google Analytics at some point in the past. They have removed nearly 10,000 websites. We were removing Google and it's quite a few websites around the web. That's what keeps us motivated and going.

Do you think your main growth is going to be self-service SaaS customers? Have you had interest from larger enterprises?

It started a lot with developers and personal bloggers. As the product is evolving and we're adding more useful features for more commercial purposes, such as UTM tags, goals, events, and lots of the other stuff we've added, we are seeing a change. We are seeing more companies, agencies with clients like governmental institutions and universities. We've basically added on top of our core audience, the original audience of developers and bloggers. We are seeing the progress every day, like a large website going and coming onto the platform with tens of millions of page views. With the information that comes to your awareness, were bringing about issues with Google and privacy, and then us improving the product. It's more competitive with what people are used to be on Google and they can get some of those main stats they need, and those two levels bring us forward.

You've got the same problem that we do where your growth has not a function of how many people sign up on your platform because you could have CNN sign up on your platform and put their tag on their home page and you’d have an interesting week.

We charge the subscription fees, standard SaaS. We don't charge per website. We charge per page. You can have somebody like a small website, then I can add hundreds of them and it might add other 10,000-page views to twelve levels, but you can have one. We've had some tens of millions of pages per month. That makes a difference in terms of how much revenue we got because we were charging per page.

We're charging per API call or it's one of our dimensions. It's been difficult because we're about to up the limits. We do a product that doesn't have that opportunity quite so much, but people are then starting to do work as part of the integration to reduce the number of requests that they're making against our API, which then makes the product less effective. We've been struggling with that. It's good because it ties nicely to how much is costing us in terms of infrastructure and having a dimension that dissuades people from using our products is not ideal. We do feel like we have to cover ourselves because we have had people integrate and deploy our RSDK into a highly trafficked mobile application that then sends out a push notification to millions of people at the same time. All of a sudden, we get these crazy traffic spikes. That's been tough. You've got a similar concern there.

The biggest concern we have is not the biggest but with pricing. What's tricky is that someone might have a spike. What if it's a seasonal website? What if it's a Christmas website? One of our highest traffic websites is election coverage in the US, which is once every four years. It's tricky to price websites that don't have steady traffic since we're doing it on a monthly basis, according to page views. In most cases, it works okay for us to do this way.

Did you have anyone that you wanted to give a shout out to, say thanks for helping, any sites, contributors, or things that have made a difference to you guys?

The whole community is there and it's amazing. Without them, we couldn't grow. One that may be relevant to you and maybe you can interview them as well is our elementary iOS. They're operating system. They came on to Plausible months ago, they saw enthusiastic about it and open about it. They signed for the product and for a subscription. They installed it on all their websites, push the product in terms of goals, what they use it for, and gave us lots of ideas. They also publicly shared that to all their audience, on Twitter, on their website, and they wrote up on the blog, you need larger companies or influential people to share your project in order for it to grow. This was useful for us and something we were thankful for. We still are in touch with them and they're one of our beta testers. Something new when we have, we go through them to get their point of view and their feedback. They’re nice people, but that's one name that comes to my mind.

How about you, Uku?

There are many people. It's crazy how much positive attention we've been getting. From my end, I can thank Chandra who has been working to make the self-hosting. The self-hosting part is contributed. I wrote a small part of it. It was all mostly written by Chandra. I can't give you his last name because I don't know and I don't know if I want to give someone's full name in a show. It's great to have someone lift us up so much. He's contributed so much in terms of codes. We don't get that many contributions, but this has been one person who's been super helpful and contributed not only once but over several months has been putting much effort into making the self-hosted version available to everyone. It's a huge thing we can offer to people and it's helping around and everything.

Guys, thank you for your time. It was the AGPL post that I saw on Hacker News that then made me think, “I need to speak to these guys because they’re treading a similar path.” It's interesting how those things can fan out the power of that. I appreciate your time. Your site is Plausible.io for those of you who haven't been on there yet. Good luck in the future.

Thanks, Ben. I love to hear what you figured out with your license.

We will be writing about it soon.

About Plausible.io

Plausible Analytics is a simple, open-source, lightweight (< 1 KB) and privacy-friendly Google Analytics alternative. The mission is to reduce corporate surveillance by providing an alternative web analytics tool which doesn’t come from the AdTech world.

Plausible Analytics is completely independent, self-funded and bootstrapped. The full-time team is based in the EU and consists of Uku Taht (design and development) and Marko Saric (marketing and communication).

Plausible Analytics is currently installed on 7,651 websites and has counted 107,251,707 page views in November 2020. It is AGPL licensed and you can use the Plausible Analytics cloud service for the easy and convenient experience or if you're happy to manage your own infrastructure, you can self-host Plausible on your server.

Links from the Episode

PostgreSQL
GitHub
Hacker News
Lobsters
Runa Capital
TechCrunch
Ansible
Heroku
DigitalOcean
CockroachDB
Red Hat
Elixir
Phoenix
Django
José Valim - LinkedIn
Dashbit
https://Plausible.io/
https://Github.com/plausible