Welcome to Once a Maintainer, where each week we interview an open source maintainer and tell their story.
This week we’re talking to Jônatas Paganini, OSS contributor and developer advocate at TimescaleDB, an open source time series database. We spoke with Jônatas about working for developers versus working on products and the joy of linting. Jônatas is based in Brazil.
Once a Maintainer is written by the team at Infield, an app that helps engineering teams track and plan their dependency upgrades.
How did you get into programming?
I worked for a year and a half at a hardware assistance company. They were just fixing printers and old tube monitors and those type of things. My job there was a bit of electronics, but more like helping to manage all the machines and cleaning computers that had viruses and things like that. And then I got bored and moved to a software company that had a very generic business management system, they made software for all kinds of local businesses, warehouses and stores, restaurants, mechanics. They said just sit here and watch this guy working and he will explain to you how you will do your stuff. I learned how to do the basic scaffolding operations without knowing any, let's say, technical theory.
Then after about three years working I went to university and had algorithms, databases and all the theory behind it. But we didn’t have access to the Internet at that point in Brazil. We had just a library, a bookshelf. If you had a question about some API interface, go and get the book and read it. At my job, our boss was also worried that someone would steal his code, so we couldn’t get any code out of the company. If I wanted to research or study an algorithm I needed to print it and bring it home.
It sounds like it was sort of an apprenticeship program then while you were in university?
Yes, yes. Then I moved to a company that did software for agriculture cooperatives, for example, milk. They had a way to share expenses, buy some products together, etc. And for organic producers, building the software to allow them to manage the entire co-op in several units in different regions and villages. That’s when I started freelancing and working with several types of customers. In Brazil we have an organization that helps encourage entrepreneurship, it’s not part of the government but it gets a sort of budget from the government. We offered technical and professional services and technology for this organization. So we got a lot of clients from them.
I was working on several inventions, like prototypes for patents involving software, hardware, firmware, building protocol for things like Bluetooth gateways and broadcasting, all types of things. There was a Bluetooth music device that you attached to your leg to play in the car while you’re waiting in traffic. The idea was like okay, you can have several of these in your car and you can turn your car into a drum or whatever instrument you want. I also developed a prototype to measure your t-shirt size based on the size of a credit card. So you show your credit card in the image and based on that we tell you the size of your shirt. We worked on all kinds of things.
Wow, so how did you find your way into open source and focusing solely on software?
I joined a big US company several years ago, helping to onboard engineers in the company, so that was my first experience with real open source stuff. We were growing really fast, and our pull request checklist was starting to bloat because there were so many people coming on and it was creating a big cognitive load. So I was like why don’t we build an automation, code a linter that will do this work? I got really involved in rubocop. Luckily the creator of the project, Bozhidar Batsov, was my boss. He was the VP of Eng at my company at the time, and I just started building more and more cops. Every newcomer that joined the company I explained to them this idea of building cops and custom linters to help them get integrated, why we wanted to automate as much as possible. With a monolith it’s a very hard problem to synchronize dozens of teams, so more automation is always better.
I was very happy working for developers, not for the product. And that’s how I got into open source - your client is the developer. That was the key thing for me. The moment I realized I don’t like to be on the front lines working on the product.
From this project I learned a lot about AST and how to refactor code in an automated way. After I left that company, I went to another company where they were decoupling the Rails engine from the original code. I created a project that let them extract the code, run tests independently, interact with the engine, etc. It was a very long process and people did several manual attempts, but in the end if you don’t have git following the next changes it’s very difficult. So I was solving the problems for developers again.
It sounds like across a few different companies you’ve moved around doing infrastructure, front end, back end, and a bit of everything. How did you end up at Timescale?
Yeah, so when I got into open source and started speaking and writing a lot, I got this opportunity to become a developer advocate, which is a very different thing. It’s part of the marketing department, not engineering.
I love this idea of exploring data in general, thinking about data as a kind of recyclable gold that you can keep extracting and enriching and getting more and more from the same. Or just mixing with another gold and then you have more gold. This is a very cool thing.
I was doing Ruby for about 14 years. I was thinking about Ruby and thought, well, Ruby has a few million users. But SQL probably has a few hundred million users, right? It’s a much broader audience because every car needs an engine to run as every app needs a database, right? I am a community manager actually working in the community. We have more than 10,000 people in ours, and we have more than 200 people per week active asking questions. So yeah, that's a lot of interactions.
What are your favorite open source packages? What do you use?
From the Ruby ecosystem I really like the organization of Rubocop and the parser, they are great projects and very well defined. I love this mix of what we have in the Ruby community and then what we are doing with the global expectation of what code quality means for everybody and how we can build better linters.
I still appreciate the hardcore efforts on all the dry libraries - like dry-rb. It’s another way to see Ruby as a lightweight package rather than a Swiss knife for everything.
One project that I’m kind of excited about in the Postgres and Rust domain is pgrx (formerly called pgx). It’s a kind of Rails for generating extensions for Postgres but using Rust. I am trying to get more involved in pgrx. The guys that built it were building software to send information from Postgres to Elasticsearch. Every company has this need - you have some Ruby and you put some hooks in your Ruby code and you start streaming it to Elasticsearch. In my previous company, we were maintaining a lot of Ruby code just to solve this problem that is moving data from one to the other.
Sometimes we think about open source as a black box thing, right? We think like, wow, this is unchangeable, but it’s the inverse - this is totally changeable. You can go inside Postgres and learn it.
Who are some people, other people that you work with or you've interacted with just over the Internet that you think are doing cool things?
I have super admiration for the guys who are building mruby, they are Japanese. At a conference a guy was showing Ruby running on a video game console (Yuji Yokoo) - this is on a Mega Drive. Just an example of people that are really nerds, they just want to play with lego, they are playing with real code and making amazing things. I am always excited to see these kind of projects, especially creative projects.
One of my favorite open source projects is from Sam Aaron, that is Sonic Pi. It’s a really great mix of arts, technology and empowerment for people learning how to do software and also hear the software and listen to it.
To suggest a maintainer, write to hello@infield.ai or find us on Twitter.