Are you asked to generate reports for your company's data?
Has someone suggested that you buy or deploy massive BI software that's expensive,
closed source, and generally underwhelming?
Well, it's Redash and Python to the rescue.
Today you'll meet Eric Framovich, the creator of Redash,
whose goal is to make your company data-driven
by connecting to any data source to easily visualize your data.
Not only is it a cool open source,
but it's an example of someone taking a successful open source project
and building a business on top of it.
This is Talk Python to Me, episode 110, recorded April 27, 2017.
Welcome to Talk Python to Me, a weekly podcast on Python,
the language, the libraries, the ecosystem, and the personalities.
This is your host, Michael Kennedy.
Follow me on Twitter where I'm @mkennedy.
Keep up with the show and listen to past episodes at talkpython.fm
and follow the show on Twitter via at Talk Python.
This episode has been brought to you by Intel and Hired.
Be sure to check out what they're offering during their segments.
It helps support the show.
Eric, welcome to Talk Python.
Good to be here.
Yeah, it's great to have you here.
It's time to democratize some data and break it free from all the places it's captured
and use Python to do it, right?
Yep, yep, yep, yep.
That's how it started.
And it's still the mission.
Like, we're not there yet.
And it's a lot beyond the technology itself.
It's also educating people.
But yeah, that's the goal.
It's an awesome goal.
And I'm looking forward to chatting with you about it.
But before we get into that, let's hear your story.
How did you get into programming in Python?
It started over 20 years ago when I got my first PC, which was an XT computer.
I think there were newer computers at the time, but that's what we could afford.
And as a kid, there wasn't much to do with it.
So I started exploring and luckily stumbled at QBasic, which was shipped with DOS at the time.
And it had a few example programs and games along with it.
So basically, I just started running them and then messing around with the source code
and looking what results my changes have been causing.
So that was my first start with programming.
Later, I found some older kid at school who was programming during breaks.
And I was like standing behind him, looking over his shoulder, looking what he's doing,
catching up new functions and stuff, and then going back home to try.
And eventually, my parents bought me some books.
And that's how I really started programming.
From then, I kept learning, you know, started connecting to the internet, exploring more.
And I think that I got a bit into web development at the time.
And then the biggest jump was when I was 18, we have a mandatory army service.
I was lucky to join one of our intelligence, military intelligence units, where I was becoming a developer.
And there I was doing stuff that are completely different from what I'm doing today.
A lot of C++ and hardware interfaces gained a lot of interesting experiences like debugging on a helicopter.
Debugging on a helicopter.
How interesting.
Yeah, yeah.
It's not, I can't share that much details.
But yeah, that's, that happened.
Anyway, when I finished my army service, I got back into the web and web stuff.
Although I had the chance to do pretty much everything like full stack and mobile development, like native mobile development and anything, whatever the job requires.
Yeah.
So, and Python, I think that I started with Python.
I'm not really sure.
But definitely, I've been doing Python when Google App Engine was released.
So, that's around 2008.
I had some detour in Ruby for a few years.
But then four years ago, when I joined EverythingMe, I went back to developing mainly in Python.
Been doing some Go in the past years.
But there's nothing like Python.
Yeah, that's right.
And, okay, so this is interesting.
You talked about, what was it called?
EverythingMe?
Yeah, yeah.
Yeah, so for a while, you worked at this company called EverythingMe.
And that was like a launcher app for Android phones.
Is that right?
Yeah.
Yeah, that's right.
Okay.
And that was super popular, right?
Like between 10 and 50 million downloads or something on that scale?
Yeah, something like that.
Yeah, that was the scale.
I don't remember the exact numbers by now.
But yeah, that was the scale.
Were you guys using Python there?
Or was that mostly just things like Swift and Objective-C?
Or not Objective-C, Java, I guess.
So yeah, our client was Android only.
So that's Java.
But we had a lot of...
Because probably today we would call it AI-based launcher or whatever the current buzzwords are.
But it was personalized and it was learning you over time and adapting to you.
I mean, in various ways in the UI.
So there was a lot of machine learning and logic on the backend.
And most of it was in Python.
And then we had a lot of machine learning and learning.
Some of our new code was in Go.
But I had...
Like I was doing many Python.
And then that shut down, which is actually a really cool story, which we'll get to in a minute, which kind of gave you an excuse to do something even more cool.
But it seems like they came back.
Is that right?
The application itself had come back.
It was a bit weird for us.
But yeah, there was another company that bought the IP, I think, or something like that.
I'm not really sure about the details.
But they brought back that.
Yeah, because I read your Medium post about how when that shut down, you went to work on this project.
And then I did some research to look at just what that was historically.
And I'm like, oh, wait, it's still in the Play Store.
And there's still an active website.
And okay, I figured somebody must have purchased it.
Yeah, exactly.
Okay.
Well, that brings us to what you're doing today.
So what are you doing day to day for programming?
These days I'm working on Redash.
And I'm working on the three levels.
One is Redash itself.
So the code.
Trying to build the Redash community because it's an open source project.
So trying to build the open source community around it.
But it's also the company that I started when everything in me was shut down.
So I'm also trying to build a company.
And yeah, so that's my day to day.
And I'm trying to balance between all of this.
Usually one of the aspects is suffering more than others.
But I'm trying to learn over time how to improve the balance.
That's really cool.
So one of the things I always love to talk about and share with everybody is how people
have an open source project and how they, in some way or another, make a business about
it.
So I really want to dig into that.
But before we do, let's talk about just Redash itself.
What is Redash?
Where did it come from?
Things like that.
Okay, cool.
So there for me, when, like at some point, when we started, we collected event data, like
about usage and stuff like that with Splunk.
You can compare it to Elasticsearch with Kibana, something like that.
And once we started getting actual usage, it just didn't scale well with the amount of data
that we started to collect.
And we've been looking into different alternatives and decided to go with Redshift at the time.
It was really around the time that Redshift was just introduced.
It was a bit over four years ago, I think.
All right.
Tell us all what Redshift is.
It's from AWS, right?
Yeah.
So basically, it was a mobile app, but you can compare it to Google Analytics, like the data
that Google Analytics collects.
So it's the same thing, like a user clicked this button, user swipe left, user swipe right,
user did that, looked at that, and stuff like that.
And for us, it was really important because along with Splunk, we've been using Flurry,
I think, and some of the off-the-shelf analytics products.
But most of them really didn't work for us because we've been creating quite a unique product.
Like it's a launcher.
So it's not an application that you start, do something, and then close it.
It's something that runs all the time.
So the concept of session is completely different from how other apps see it or how the off-the-shelf
products see it.
So being able to access the raw data gives us a lot of power and ability to really understand
what people are doing.
So that was Redshift.
So you said Redshift is a column store database.
Column and R, yeah.
Which is not necessarily the same as a standard relational database.
It's not a document or key value store type of database.
Yes.
How would you describe that?
Like what does it mean to be a column or a database?
Redshift has two properties.
One of them is that it's columnar.
And what it means is quite easy to understand is that it stores data in columns.
So when you write a row, it takes each column and stores them, each one of them, along with
the other values of that column.
And what it allows, it allows for easier compression.
Like it can really compress your data really well.
Because think of like if you have a column which is a boolean.
So it's super easy to compress it if you have only these booleans versus if you store them
by rows.
Because then it gets harder to compress this row because it has all the different kinds
of data.
And this compression both saves you space.
And when you're dealing with large, large amount of data, it's important.
But it also makes processing much, much faster because you need to load smaller amounts of
data each time.
The other property of Redshift is it's I think the term is MPP is massively parallel.
What's the other P?
I don't remember.
Massively parallel.
That's just them.
So why MPP?
Massively parallel processing maybe.
Yeah, exactly.
Yeah, you're right.
They have, like when you run a query on Redshift, they compile binary code from it, from your
query.
Distribute this code to all the nodes in your cluster.
And then each node runs the query and then the master node aggregates it all.
So it's all sophisticated ways to process large amounts of data.
That's cool when you're processing large amounts of data.
It's not cool when you have small tables because then the penalty of like waiting for the compilation
step and all that is like it's too high compared to if you just ran this query on a normal database.
So you need to know when you should use it and when not.
But it's a great tool.
If you like on the Google side, you have BigQuery, which is again a columnar database.
But BigQuery has the advantage that it's you might call it serverless because with Redshift, you need to decide what the size of cluster you have.
You need to maintain it.
You need to vacuum your data like you do with Postgres.
With BigQuery, you don't have all this hassle that you just load that into it, run your queries.
You don't worry about anything.
Google takes care of it.
It comes with the downside that you pay per query.
They have an interesting pricing model where you need to pay basically based on the amount of data that your query is scanning.
So you need to be really aware what your query is doing and what columns you're picking to query and stuff like that.
That is an interesting business model to like, as your code runs less efficiently, you pay more.
But that's a pretty straightforward way to, I mean, that's how you use it up, right?
Yeah, exactly.
And the thing is that while it's not straightforward this way, with Redshift, it's practically the same.
Because if you write a BigQuery, you're waiting longer time, you take more resources off your cluster.
So you will end up eventually having to buy a larger cluster.
So it means it costs you more.
It costs you in human hours, like when your analyst is staring at the screen and waiting for his query to return.
So it's less explicit, but it's practically the same thing.
But obviously, from a financial standpoint, it's much easier to say, OK, we have this and that budget.
That's the kind of cluster that we're going to buy.
And that's it versus BigQuery where you, OK, I'm not sure how much it's going to cost me.
Let's hope it will be OK.
Yeah, it's definitely harder to predict.
But OK, very interesting.
All right.
So you said, look, we have this high performance, massive scale database and sort of regardless of which one you choose.
And we have all this data coming in.
And you're like, well, now we want to look at it and query it and do reports on it and things like that, right?
Yes, exactly.
So we had this project.
So we had this project of, OK, let's start piping our data into Redshift and to understand how we should do it and all that.
And when we started to get to the finish point of this, we said, OK, we're starting to have data in Redshift.
What are we going to do with it?
And we've been really spoiled by Splunk because Splunk has a really good user interface that allows you to query the data that you send into it.
And they have their own language that some people like it, some others not.
I didn't use it enough to form an opinion, but it was obviously lacking with Redshift because Redshift is just a database.
They don't handle the UI.
And at this point, we decided, OK, let's look at what the big boys are using.
Let's find the BI tool.
And we looked at Tableau, Yellowfin and maybe some others, but all of them failed with Redshift.
They might be great tools for traditional BI, let's call it, but with Redshift, what we've been doing at the time and probably many others doing,
we had a huge table, which being our raw events data, and we wanted to start running queries on top of it.
And it's something that's super hard to do with tools like Tableau or Yellowfin.
I think that they improved over the years and adapted to support better tools, databases like Redshift.
But it's definitely not the same thing as being able just to open an editor, write your query and run it on top of the table.
We tried to find a tool.
And at the same time, because we started already collecting data, anyone who wanted access to this data, we just created a user in Redshift,
told him to connect with any SQL client that he likes.
And people started inquiring for data, getting results and sharing them.
But the way they've been sharing them is basically sending CSV or Excel files over email, which is okay.
But then you get into questions like, okay, we see an issue in the data.
Okay, we see that we have a drop in conversion.
Now we start with questions like, do we really have an issue?
Maybe the issue is with the data that we collect, because it's a new pipeline.
Maybe we have a bug, and it's not really a drop in conversion.
Or maybe it's just the way the person who wrote this query, he made a mistake.
And he calculated the conversion wrong.
So you start reverse engineering the kind of query that he ran, because he obviously, since then, closed his editor.
He doesn't remember what he did.
He just has a CSV file to show.
And it was really, really frustrating.
I'm sure.
And you can't even verify it some of the times, right?
Because the person might not remember exactly what they did.
Yeah.
And this is like an exact true story, where I was reverse engineering.
I knew what query that person started with.
So I started with that query, and I'm running it.
And I see, no, that's not the same numbers.
Okay, let's change this and that.
Not the same numbers.
And then I followed the steps until I got the same numbers.
And okay, he had a mistake in the query.
And this is not something like, I had a similar experience in a previous working place.
So the problem felt familiar.
And me and our CTO at the time, Joey Simchon, we started talking about, how about if we had a JSFiddle-like UI for queries, where a person can write a query, get the results, and then share this URL with others, where the other person gets both the results, but also the query.
So that you can see what he did, and maybe understand if it's like, do some peer review.
And also, if you want to keep digging in, you have the query to start with.
So we had this idea floating.
And then we had one of our hackathons.
And this is when Ridesh was born.
Nice.
Yeah, you know you have a good product or idea when it's solving a problem that keeps coming back.
Right?
You're like, oh, we've been here before.
Why is there nothing that actually does this well?
Yeah, yeah.
And I think that only after I realized, yeah, that's actually something that I wanted to build back then.
Hmm, interesting.
And many people that adopted Redash since then have been telling me, yeah, we built the same thing internally, but we dropped it for Redash because, well, we can't really maintain it for a long time.
And here's a product that someone's already maintaining and using.
So let's switch to it.
Right.
So Redash kind of is made up of two different parts.
You've got, like you said, this JS Fiddle-like query editor.
And it's actually really nice.
It has auto-completion for the columns and tables and all sorts of stuff, right?
Yeah.
It depends on the database that you connect to because not all of them will have support for loading the schema.
But if it's a connector that supports loading the schema, you will have auto-complete.
And we have some other features that we adopted over time, like query snippets.
And you can have parameters inside your query so you can create something more interactive that the end user, let's call it, can play with instead of changing the query every time.
I see.
So can you have, like, so the other half of the story is you build the queries.
The other half is the dashboards and visualizations.
So on your visualization, could you have, like, a slider that is, like, a number of days you want to average across or something like that?
And you can slide it and it'll change the query.
So unfortunately, the parameters are not as slick as a slider or something today.
So currently, they're just input boxes where you can, the most that you can customize is, like, say, okay, this is a number input box or it's a date input box and the UI will adapt accordingly.
But it's not as simple as you can't.
So you can't.
able to give these people a way to create interactive stuff is super important.
Sure. And being the person who writes that query where they're like, well, I asked for
one day, but now could you do it for seven days? You know, that's also not fun to be
doing that, right?
Yeah, exactly. Although I've seen more than once that people who are not like your traditional,
someone who, like, obviously developers will know to write queries. Then there are the
product managers who some of them had some engineering background, they know to write
queries. But I've seen marketing people learn to write queries just because, well, they
started with asking someone to write a query for them. And then over time, they started
picking at the SQL and saying, okay, that's not a frightening, let's change the number of
days from seven to 14, running the query and hey, I got the results I wanted, that's cool.
Then the next step is that they, okay, let's just learn SQL and there are some good resources
online to learn SQL. They learn SQL, then they feel really empowered because now they can
have direct access to the data without anyone in the middle. It creates some issues sometimes
because many times the company's organizations actually won't have a clear schema of the data.
The data model is not that obvious.
Especially on these event streams, right? Where you're just like dropping data and that's streaming
in or something.
So yeah, so the event stream is definitely hard because it's also harder to, like, every question
beyond like, okay, how many events we had yesterday, how many unique users and obvious stuff like that
becomes really complex query. So this is something that I really want to tackle in the future.
And basically to make it easier to create more sensible models around the data. And I have some
ideas here, but that's, it will take time to get here. But yeah, so, so it's not that obvious to give
people a way to play with data. But I think that the fact that in Redash, you can always see the
querying, always have some peer review. It makes it much more safe, let's call it, to do it. And I see
really good success stories around this.
Yeah. And you have the ability to very much JS Fiddle, like to share your queries and, you know,
save them in the dashboard. And then people can like fork them off and say, I'm going to make a copy
of this and then I'll tweak it myself and save my version and stuff like that. Right. So that's pretty
helpful.
Yep. So basically the flow is that you can write the query, get the results. From here, you can just share
the table that you got. That's cool. You can access it with an API if you want to connect it to some
other tool. But you can also visualize it. And there are several types of visualizations.
The default ones like charts, maps, some Sunkey, WorldCloud and other stuff. And then you can group
several visualizations into a dashboard. And that's Shareware as well. That's basically the scope of it.
Yeah, that's cool. And so really, I think, you know, the way people probably perceive it is like,
here's a site internally we can go to, or I guess it could be public as well, that we can go to and
it'll show us the stats for our company. If we've got an app or web app, how are people using it? If you
got sales, like what sales versus leads doing, right? And there's a lot of different ways to visualize it.
One of the things I saw that you guys had that I really appreciated, because I've had to build it
before, is cohort analysis for like subscription services, or you know, those those types of things,
you know, users come and then they fade out. And that was really nice. So you have a lot of nice
visualizations. And they're pretty interactive. And they look really good. They're certainly things
like you would be happy to put in front of the CEOs or whatever. And go, here's your dashboard. Enjoy this.
In many cases, the CEO is the most active user on Redash, like at Everything Me, usually the CEO was
the one to spot data issues, because he was like, all the time on Redash, and he would spot various
changes in data. And we had, because we've been using Redshift from the early days. So we had cases
where a data for a whole day just disappears, and then reappears. So he was spotting that just before
anyone else. Sure. I live in this. I know this looks weird. I've been watching this for 14 days.
Yeah. So he was really challenging us to build the better alerting and monitoring mechanism for our
data flow, so that we can spot it before him. But I know that other companies as well, like the most
active user is the CEO. And he's like starting his morning, checking from the phone, the stats,
and then goes to email. So yeah, it's really, it's really nice in that way. And, and really,
like the visualization is something that we really want to find a way to get more contributions from
the community. Because this is like a venue for people to really become creative and share stuff
that they know. And I think that something that really, really, really help with it is if we will
have some plugin model. So today you need, like, if you want to add a visualization, you need to make
a pull request to the main repository. And you need like to start the whole project for that, which
over time became a bit hard. So I think that once we have a plugin model, it might catalyze more
development around this area. Yeah, I was thinking that a plugin model, I was going to ask you about
that. That seems like a really good idea.
We all love Python for its tremendous productivity benefits, but getting the best performance takes
some work. What if you could get out of the box, easy access to high performance Python? Intel distribution
for Python developers delivers just that. Get close to 100 times better performance for certain
functions when using NumPy, SciPy, Scikit-learn, linked with optimized native libraries like Intel
Math Kernel Library, access efficient multi-threading, and Python projects like Numba and Scithon.
Try the Intel distribution for Python and experience performance today at talkpython.fm/intel.
And profile your Python and native C, C++ applications for performance hotspots with
Intel VTune amplifier. With Intel, it's all about performance.
We also talked about the community. Like if you check out the GitHub repo at github.com slash
get read dash slash read dash. And when somebody, one of my listeners suggested that I have you on the
show and that we talk about this, I'm like, okay, this is a pretty cool looking project, but like how
many people really care about it? And then I went and looked at the GitHub repo and there's like 65,
almost 6,500 stars. There's like 135 contributors. I'm like, whoa, people are using this a lot. And it
seems like such a nice alternative to like Microsoft Excel with like some BI plugin or, you know, something
like that. Or all the various like big corporate commercial things that you have to buy into to
sort of do your BI dashboard type stuff. Yeah. And most of them are many times will be too complex for
many use cases and overpriced. So basically they've been like priced let's buy, let's charge as much as
we can, which is not really friendly for smaller companies or for different economies. Like
read dash has users really all around the world. And we see like people from Asia, Africa, South America,
where they have a completely different economy and it's really hard for them to afford all the other
tools. So being able to like to give them something that's really affordable, like almost free, like
it's open source. So it's really free except for the, I don't know, the cost of the server really gives
them a, I don't know, the same playing field as others, which is kind of cool. We have like, besides that,
we have all the big names that use it and that everyone knows like Amazon Atlassian, Mozilla,
Cloud, Outbrain and others. But it's really cool for me that I know that it's being used everywhere
and not just, you know, like in the United States, in the Silicon Valley. And actually I think that in
the Silicon Valley, probably less popular in many other areas. Right. Cause they have the money to burn
on whatever they want. Yeah. But it is cool. It's cool that it's used at some of these major tech
companies. It's also cool that it's enabling places where they're just with nothing possible or much less
possible before. So you talked about supporting different databases or connectors. You actually
have a quite a few integrations, you call them. What are some of the integrations that you guys have?
We started with Redshift and Postgres and basically it's the same thing. It's used like Redshift. You can
talk to it with a Postgres client. So this was the first connector that we had. I think the second one
was MySQL and the third one was BigQuery. But since then we had many more and most of them came from as
contributions from the community. Basically, someone found Redash. He wanted to connect it to his database and
he created the connector. And I think it's, there are two reasons why it became like this kind of contribution
became probably because there is a really simple API that you need to implement to add a connector to Redash.
And also it's like the thing that you must create to be able to connect to your database. So it's been really
motivating people to do it. So yeah, today it connects to many databases that I never used or heard of before.
So it's like InfluxDB or Impala?
It's actually InfluxDB I used.
Okay.
But Impala, yeah.
Yeah, yeah. Cool. And also it connects to like the standard sort of big company ones like Oracle, Microsoft SQL Server.
You've got MagaDB and MySQL, like what you already mentioned, and Cassandra and some others, right?
Yeah. And with all of them, you can say, well, let's say with all the SQL ones, you can just write the regular SQL query that you will write for the database.
Like we don't do any processing on your query. We send it as is. And this is one, this is a decision that allows us to support all these databases so easily because adding a database is just a matter of having proper driver and Python for it.
And even that's not really a limitation as like Amazon Athena, which is something they introduced recently.
They released only a JDBC connector for it.
And basically what I did is write a simple microservice in Java that uses the JDBC driver and exposes an interface that Redash can talk to it.
I see.
But most of the others, we just use the Python driver.
Now, if it's a database, if it's not like, if it's a database like MongoDB, then you just need to write a JSON that describes the query, the MongoDB query.
And it's almost similar to the syntax that you might use if you wrote the query inside some Mongo shell.
Not exactly the same, but quite similar.
But we also use this for other, like we have connector to Google Analytics, for example.
So again, you write a JSON that describes the data that you want to fetch from Google Analytics and you can get it into Redash.
Similarly, we have support for Google Spreadsheets, Jira and some other stuff.
And what this allows is that you can create one dashboard that shows data from the multiple data sources that you have.
It became quite common these days that many companies will have different type of data sources.
And it really helps them to be able to just show data from all of them instead of having different silos of UIs that show data from each one or having to build it in-house yourself.
Right. So maybe you could have like Google Analytics, like a Google Analytics widget on your dashboard right next to, so for web traffic and conversions, right next to like your sales numbers for the day.
And you could see how those relate potentially or something like that, right?
Yep. Yep. Yep.
Nice. Do you have integration with things like Stripe?
No. And it's something that comes up and maybe in the future we will have, but it's much easier today to just use something like, I don't know, Segment or Stitch, which are companies that give you the service of you connect all these web hooks to them or they just use their REST API, whatever.
And they can write the data into your database or maybe BigQuery or whatever you want.
And then it's easy to query that in Reddish.
I see. Let them handle all the API bits and the callbacks.
It's not only that. You get also the advantage that you have all the data in one database so you can start joining the data easily.
Right. Okay.
And it's something that you can do in the hosted version of Reddish, that you can write a query that runs across different data sources, but it's still not the same thing as having it in the same database and easily manipulating the data.
Sure.
So we've talked about a lot of the databases and data sources on the back end.
What is Redash itself built in?
It's a Python web app, right?
Yep.
Yeah. So it's both Python and JavaScript because it's a single page application. I think there are new names for that today. But basically, the Python side is an API.
And then there is the front end application that uses this API to present the UI.
I see. So you've got like a Flask backend. There's a bunch of JSON services. And then you've got what, Angular running on the front end?
It's a bit embarrassing these days to say it. But yeah, we're using Angular 1. So yeah, when we started, it was quite new and fun. But these days, yeah.
Isn't that the problem with JavaScript? It's like, we got the most amazing thing. It's just taken off. And like six months later, it's not. Right? There's five other choices. It's hard to really pick a winner. I mean, it's just nobody seems to reign very long in that world.
Yeah, it's a bit frustrating in this sense. Ember been quite surprising in the sense that they kept just moving ahead. And they've been able to really pick up the good parts of each new iteration of frameworks.
But it has its own issues in other senses. But it was really impressive to see how Ember just evolved over the years.
And I think that there is a feeling that things are starting to stabilize.
That the community is starting to adopt less, like the same tools and start to evolve them instead of, yeah, let's reinvent it again.
And it seems that React is going to be among the top winners along the side with Vue. I'm not sure how to pronounce it, but it's V-U-E.
Okay.
And probably Angular will stay because all the enterprise players that use it.
But it's probably not going to be the tool of choice for new companies and smaller companies.
I really like the Angular 2 and by now it's probably Angular 4 syntax is really like, I just don't like how it looks, the API they created.
But that's just a personal thing.
So, yeah, we're still with Angular 1.
I really hope that I could devote the time to migrate to something else.
But every time it comes up, I need to wear the product manager hat and say, the user doesn't care if it's Angular React or whatever.
So, let's focus on things that the user cares about.
Yeah, I mean, it really doesn't matter too much until maybe there are contributors that's like, I would love to contribute, but I'm not writing Angular.
Or it's really in the way of evolving the product, right?
Yeah, exactly.
I'm sure that there are a few things that I can, like, the aspect of attracting new contributors is definitely an issue here.
Because many people will just stay away from Angular these days and will be bummed by that.
And I can see some technical challenges that will be much easier, including the plugin model and stuff like that, if we adopted something else.
What would you pick if you could pick anything?
It's a good question.
It will be probably either React or Vue.
There are some things that I really like about Vue or whatever its name.
Vue, maybe?
Yeah.
Yeah, it's probably pronounced like Vue, but yeah.
Anyway, V-U-E.
So, there are many concepts there that I really like, but it seems that most of the mindshare is around React.
And as an open source project, I think it's important to adopt the more common technologies so it's easy for people to jump in and contribute instead of picking stuff that might make more sense from a technical point of view.
Yeah, there's really that balance, isn't there?
I mean, you definitely want to make it as easy as possible for contributors to contribute and extend it.
Yeah, and in that sense, Angular was really bad choice.
I remember an instance where someone like a coworker there for me wanted to add some feature, and I started to walk him through the things that he will need to understand to add it.
And then after like three minutes, I said, you know what?
Never mind.
I just implemented myself.
It will take less time than to explain it.
On the other hand, there was some internal app that I wrote later on with React, and I wanted someone to help me with a specific component.
And he didn't even need to look at React documentation.
He figured out the API from the code that I already had in place.
So it really reassured this feeling that I had that React has a really good learning curve.
So even if someone is not familiar with it, it's super easy to understand.
And it has other issues where it's like the ecosystem around it is a bit complex at this time.
But yeah, I don't know.
It will take time until I will have to make this decision again.
So we'll see how things will shift until then.
Yeah, maybe someday you can rewrite the front end.
But for now, there's more to do.
So one of the things I wanted to talk to you about, make sure that we covered on the show, is when you first started this project, it was an open source project.
And then recently, we talked about everything me and it's shutting down.
And that gives you a chance to say, okay, well, if I'm not doing that anymore, now what?
And you decided to try to take Redash and make it a proper company, as you talked about in the beginning, right?
I think there are a lot of people working on open source things.
And it feels to me like the standard way to level up off of open source stuff is to, all right, I've created something.
Let's just say like Flask.
I don't actually know how Armin Roeneker works this angle.
But let's suppose I create Flask.
Flask is popular.
So I try to do consulting for Flask projects.
And that's fine.
But I feel like in a lot of cases, it doesn't work very well.
You're still trading in your time for money, which is not always the best thing to be doing.
So you said like you actually thought through the different business models.
And right now, you're basically offering, in addition to the free open source version, hosted Redash as a service, right?
Yeah, that's correct.
So you want to talk about your thinking through those different business models and whatnot, stuff like that?
Sure, sure.
About half a year ago, I did a talk at a local meetup about what I learned from the experience of taking an open source project and turning it into a company.
And there have been three lessons.
The first one is that if you want to be able to work on some open source project, like your project, don't start a company.
That was a mistake.
And it's like an obvious thing.
Starting a company has its own challenges.
It has its own challenges.
It has its own demands.
And it's not easy.
You have to learn about accounting and all sorts of stuff that is, you're not trained in marketing, for example.
Yeah, so there is that.
But there is the whole thing of creating a business, which has nothing to do with creating a project or creating a product even.
Like you have your open source project.
That's cool.
But it has nothing to do with creating a business around it.
And I know that I made mistakes.
Some of them intentional around the business side of Redash.
Because the reason I started the company was to make sure that Redash will stay here for the long term.
So basically, the project doesn't serve the company.
Like it's not that I'm building a company using the project.
I'm building the company for the project.
Like I'm building the company to be able to work on the project for the long term.
Obviously, I'm also making it for my own self-defense reasons.
Because like I always wanted to create a company the way I see that it should be.
But there is some balance where usually you will invest more in the business itself.
I tipped more towards the project because that was the goal.
Now, in terms of business model, luckily we can see a lot of open source companies these days.
And you can see different models they do.
Many of them actually, if you look into it, they do all of them.
So basically, you can either like have some dual licensing or two versions.
Like have some your community version and your enterprise version.
Something like GitLab.
Yeah, GitLab is doing.
So they have their community GitLab version that anyone can download and install.
And there's the enterprise version of GitLab.
And these days there are, I think, two flavors of their enterprise version, which you can buy a license for and install them.
So that's one model.
There is the model of offering some professional services around your software.
And there is the model of offering a hosted version of your software, which is something that GitLab is doing as well.
But it's not their main thing.
The product that I took inspiration most from is Sentry, which is actually Python as well.
And I exchanged a few emails with David Kramer, who was really generous with his time and shared some advice.
And what they're doing is that they have a SaaS offering, which is exactly the same as their open source project.
When I started, I decided to keep everything open source and offer it as a service as the SaaS offering.
And basically, the idea is that anyone who doesn't want to manage his own installation of Redash and have the hassle of, like, uptime and keeping up with the upgrades and all this stuff, he can use the hosted version.
What I learned since then is it takes time to scale a SaaS business, especially when it's not your only focus.
Like, I'm always, like, juggling between, okay, we have the open source version and I have some production issue with the SaaS and you need to prioritize.
And also, like, building a SaaS business, again, like, at this point, Redash is good enough to just keep selling it.
Like, to focus on finding the market, finding the market and blah, blah, blah, blah, blah.
But because it's also open source, it has to keep moving forward because no one likes, like, a stagnating open source project.
So there is this balance which is not that easy to maintain, especially with limited resources.
So besides deciding, like, on this business model, I also decided to keep the company bootstrapped and not raise any money.
There were different reasons for that.
Essentially, it's just the thing that I felt most comfortable with.
This portion of Talk Python to Me is brought to you by Hired.
Hired is the platform for top Python developer jobs.
Create your profile and instantly get access to thousands of companies who will compete to work with you.
Take it from one of Hired's users who recently got a job and said,
I had my first offer within four days and I ended up getting eight offers in total.
I've worked with recruiters in the past, but they were pretty hit and miss.
I tried LinkedIn, but I found Hired to be the best.
I really like knowing the salary up front and privacy was also a huge seller for me.
Well, that sounds pretty awesome, doesn't it?
But wait until you hear about the signing bonus.
Everyone who accepts a job from Hired gets a $300 signing bonus.
And as Talk Python listeners, it gets even sweeter.
Use the link talkpython.fm/Hired and Hired will double the signing bonus to $600.
Opportunity is knocking.
Visit talkpython.fm/Hired and answer the door.
There have been a few local investors who've been really interested.
And they even had a funny thing that one of our SaaS users, we have an integration with Slack that you can share visualizations from Reddish on Slack.
And he has a Slack channel with his investors.
So he started sharing with them KPIs and stuff like that from Reddish in Slack.
And so his investors saw it and he said like, hey, what's that?
That looks cool.
Can you connect me with the founder?
I might want to invest.
But I passed that opportunity.
Yeah, that's a hard decision to make, right?
But as soon as you take funding, the clock starts ticking for growth and other types of things that are maybe short term and not necessarily where you want to focus.
Well, it's a long discussion like bootstrap versus VC and all.
But essentially what I realized is that I prefer to keep it bootstrap.
So let's just move with it.
It definitely puts many constraints on what you can do.
Up to this day, I'm still working mostly alone on it.
Like full time, I'm the only employee at the company.
I'm using some freelancers, but full time, I'm the only one.
I am currently trying to hire another developer.
But it takes time.
So it's still only me.
But hopefully soon there will be another person.
So do you feel like having your open source project also powering a SaaS company?
Do you feel like Redash is better because of the exposure and experience you got running the SaaS company?
Yeah, that's for sure.
The hosted version of Redash is probably one of the largest deployments of Redash.
And it allows me both to stress test it and to find weak points in terms of performance and stuff like that.
But also it gives me visibility into how people use it.
So as an open source project, you practically have no idea how people use your project, what they do with it, how they use it, what kind of connectors and all that.
So you need to make decisions really blindly compared to a SaaS business where they have a lot of data that they can collect.
Yeah, it's not like everything me, for example, which started this whole thing where you have all these stats coming in.
And now I'm sure you have like all sorts of usage stats on like features, how frequently they're used and the type of errors you run into.
And you wouldn't get that if it was just cloned off GitHub and run the script.
Yeah, exactly.
And so this as well improves the project itself because it allows to make more informed decisions.
I remember there was one instance where someone wanted to switch just some behavior.
And it felt to me that what he proposed is not common enough.
But then I checked the data and I realized that he's right.
So it really, really helps to be able to see how people use it and to have more direct access to them and to be able to understand what they do with Redash.
It has some downsides towards the open source project because there are things around the way like the deployment story and stuff like that, that might be investing more into them if it was only a self-hosted solution.
We still have quite an easy way to deploy Redash.
Like I maintain images for Amazon and Google Cloud.
And also there are Docker images.
So it's not that hard to start using Redash.
And in the last version, I even added some wizard that allows you to set up the user without having to use the CLI.
That's eventually improving, but it could move faster if I wasn't also working on the SAS project.
Yeah, it's easy to see it that way.
But at the same time, the SAS project lets you put all of your time into this open source project and not do like consulting for a bank where you're building forms over data type web apps.
Yeah, exactly.
And at the beginning, I've been doing some custom development, paid custom development for on top of Redash, but still like doing some sort of consulting work.
While over time, I could focus more on the product itself.
So it definitely has its benefits.
And I'm still like it's a recurring thing dilemma for me, like around whether I should invest more in the SAS or should I find a business model around the self-hosted version?
Because even today, there are much more users who use the open source version, the self-hosted one, than ones who use the SAS version.
And there are people who even start with the SAS and then like they use the trial of the SAS.
Oh, that's cool.
Let's move to the open source one for different reasons.
Some of them just don't want to open their database to an external company.
Others are just cheap.
And I even compared the numbers with Sentry and they said that they see a better ratio between the open source users and the SAS users.
And I think that part of the reason is the kind of product I'm building where you really need to like give access to your data to another company and many people not feeling comfortable with that.
So I always like it's a recurring dilemma of whether I should find either another business model or an additional business model where I can offer something to the self-hosted crowd.
And the obvious thing here is just some kind of an enterprise edition.
But my concern here is that once I start offering an enterprise edition, there are two problematic outcomes here.
One is that usually enterprise clients, they're not only buying software, they're also buying support, which means selling services.
Right.
What's your SLA and all of that kind of stuff?
Yeah.
And you start deviating into the world of selling hours instead of selling software.
That's one issue.
And another issue is that they have completely different demands than what the rest of the users need.
And then there is the concern of turning Reddish into Jira instead of keeping it as Trello.
And this is like something that it's a slippery slope where you find yourself with a bloated product because of different bigger clients with weird needs.
And today it's easier to ignore them because they're not paying you.
But once most like huge chunk of your revenue comes from them, you need to be more attentive.
So these concerns keep me on the SaaS model, but it's like a recurring dilemma.
And I hope that one day I will have a definitive answer here and I will know like, yeah, that's what we're sticking with.
Yeah, it's not super straightforward, I can tell.
But I think it's really great that you're making it work on either path.
And the SaaS one is definitely adding value to the world.
So nice work.
And I'm sure it's inspirational to a lot of people to hear it.
Yeah, I hope so.
I hope so.
All right.
Well, I think we're going to probably have to leave it there more or less for Redash.
So let me ask you two final questions before I let you out of here.
When you're working on Redash and you open up an editor, a Python editor, what one is it?
So until not long ago, it was Atom.
But recently I started using Sublime again.
So I guess it's both of them.
And obviously with Vim mode enabled.
Yeah, of course.
Very nice.
And what out of the 100,000 plus PyPI packages, what one do you think is notable that people maybe don't know of, but they should check out?
So the first one is PeeWee.
P-E-E-W-E-E.
Yeah, exactly.
It's an ORM.
It's a Python ORM.
I think it's not, it should be much more popular than it is.
I think it's the most Pythonic ORM.
Yeah, exactly.
I really don't understand how SQLAlchemy getting more mind share than PeeWee.
It's really like a mystery to me because PeeWee is much more Pythonic.
And Redash has been using PeeWee up until like half a year ago when I decided to migrate to SQLAlchemy.
And no offense to the SQLAlchemy people, but I think that was one of the biggest mistakes of 2016 for me.
Yeah, I should have stayed with PeeWee.
How interesting.
Yeah, you're right.
The SQLAlchemy definitely gets a lot of the mind share.
SQLAlchemy is great.
But I do think also PeeWee is quite cool.
Basically, you give it Lambda expressions or generator expression type things, and it transforms that into the actual SQL query.
I think that's glorious.
Yeah, and just simple to use and fun.
Yeah, exactly.
And I also noticed that there's an extension sort of package that will convert it to an asyncio variation.
So you can basically create async coroutines and use PeeWee queries and await the queries, which is, that's just icing on the cake.
That's nice.
Oh, that's kind of cool.
Yeah, it's very cool.
So thanks for that.
Those are awesome recommendations.
Now, final call to action, like, how do people check out Redash?
How do they check out the hosted thing?
What do you need from the community?
Things like that.
Go to redash.io and you have all the information there.
It's super easy to start, either if you go with the hosted version or even if you start with your own deployment.
It's really a few minutes and you can start curing your data.
And probably if you have a database, you need Redash.
And contributions are always welcomed, like both code but also documentation.
Like, this is something that we're not getting enough of.
But, yeah, any contribution is eventually welcomed.
All right.
Well, sounds good.
It's definitely a cool project.
Eric, thank you for sharing it with everyone.
Thank you for inviting me.
You bet.
Bye.
This has been another episode of Talk Python to Me.
Today's guest has been Eric Framovich.
And this episode has been sponsored by Intel and Hired.
The Intel distribution for Python delivers the high-performance Intel C libraries built right into Python.
Get close to 100 times better performance for certain functions when using NumPy, SciPy, and Scikit-learn.
Check them out at talkpython.fm/intel.
Hired wants to help you find your next big thing.
Visit talkpython.fm/hired to get five or more offers with salary and equity presented right up front
and a special listener signing bonus of $600.
Are you or your colleagues trying to learn Python?
Well, be sure to visit training.talkpython.fm.
We now have year-long course bundles and a couple of new classes released just this week.
Have a look around.
I'm sure you'll find a class you'll enjoy.
Be sure to subscribe to the show.
Open your favorite podcatcher and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, Google Play feed at /play, and direct RSS feed at /rss on talkpython.fm.
Our theme music is Developers, Developers, Developers by Corey Smith, who goes by Smix.
Corey just recently started selling his tracks on iTunes, so I recommend you check it out at talkpython.fm/music.
You can browse his tracks he has for sale on iTunes and listen to the full-length version of the theme song.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Smix, let's get out of here.
Outro Music.
And I'll put it in.
Thank you.