Jani Eväkallio // @jevakallio

OPENING QUOTE:  I feel like I'm more of a firestarter, you know. I run up and down the coast and lighting fires. And when the boats crash on the coast, I prance off and do something else. And I used to feel really badly about that for many years. And it's led to some of the lowest moments of my life and my mental health journey. But I don't feel bad about it anymore. I also think that there's a space for creative thinkers and experimenters and that's where open source really distilled for me today. It's a creative venue. It's not necessarily an obligation in the same way as many maintainers take on.

Brian: That’s Jani Eväkallio, founder of many open source projects, FOAM being one of the most well known ones, and this is The ReadME Podcast, a GitHub podcast that takes a peek behind the curtain at some of the most impactful open source projects and the developers who make them happen. I am bdougie aka Brian Douglas…

Neha: And I’m nerdneha aka Neha Batra.

Brian: Every episode, Neha and I invite a maintainer or open source developer into our studio to explore the impact their work is making on the world around them. 

Neha: In this episode we speak with Jani, who got into programming and open source as a teen and has continued that pursuit his whole professional life. In our conversation, he shared his thoughts on how to be a successful maintainer but also a fulfilled human being. We’ll hear about his relationship to open source, the learnings he had over his career, and where he currently puts his intellectual and creative energies. He has maintained countless projects over the years, and while he loves open source, he has also discovered his limitations. 

Brian: This is a topic we hear from a lot of our guests—how to balance the volume and expectations that come with open source work, and the challenges that that raises. It’s important to look at all sides of being an open source programmer and maintainer, and that’s something we try to do throughout each episode. I was recently a guest on Compiler, RedHat’s new podcast. I and a few other guests had the pleasure of sitting down with their team to dive into the topic of balance and burnout. Here’s a little sneak peak of the episode that dropped today.

Brian: I think what it really comes down to is like we've learned from the stories that are existent. And the more conversation we have about burnout, and more conversations about maintainers stepping down from projects or looking for new maintainership. We can help push the community in a positive direction by talking about some of the stuff that maybe isn't as positive at the end of it.

Compiler: I like that. I like that we can talk about burnout being a real thing. It's not taboo. I mean, think about it in the past five years or so, you know, we would never hear people talking about their, their mental states and their mental health. And I like the fact that we're having this conversation so people can turn the mirror on themselves maybe if need be.

Neha: But back to the ReadME Podcast. Let’s dive into the interview with Jani. First—and as always—we asked him what his first experience was with a computer.

Jani: I'm not exactly sure what my first interaction with a computer was. The first memory I have is playing solitaire on Windows 3.0 machine at my aunt's house I think. And just really being very taken with the incredible user interface of that. And if you only got on Windows and Windows 3.1, then you did not know what a horror show a 3.0 was. I believe it looked like the hot dog theme by default, whether or not you want it to or not. I think the design wasn't quite up to par at that time.

Brian: Excellent. So curious what got you into writing code? That's always an interesting question to find out as well.

Jani: Yeah, for me writing code in the beginning wasn't really infatuation with the computer as a device, or I wasn't even infatuated with what computers can do. I think it was just a very difficult thing and my adolescent brain really gravitated towards doing difficult things for the sake of doing them. So I think the first time that I ever wrote code I was an IRC. I was managing a channel and I needed a bot. And at that time you couldn't just install a bot on a VPC as easily as you can today. So I needed to figure out how to build a PEARL program, how to modify that, first how to get it—how to download it from FTP server and what even is FTP.

And it snowballed from there to the point where I think by the time I was 16, when I took my first hiatus from programming, I think I knew something like five or six programming languages, which is more than I can say that I know today. And it was always just the next thing and the next thing and the next thing.

Neha: So wait, before you wrote your first line of code, you were already managing an IRC channel?

Jani: Yes.

Neha: Could you walk me a little bit through that? It sounds like you almost got into it through a side door versus what we hear in our typical stories, which is really cool.

Jani: Yeah. So for me, when I was 14 years old, I broke my leg in an unfortunate sporting accident. And the whole summer I was stuck inside where everybody else was playing ball and doing whatever 14 year olds do in the summer break. And I was stuck at home and IRC was for me, it was kind of like the lifeline, the way to connect to people. And of course, I didn't tell anybody that I was 14, not that I was trying to hide it, but also it doesn't come up, you can hide behind an avatar or hide behind an alias. So I was just another guy and I felt great to be in a group of a little bit older kids and adults and whatever and be viewed as a peer of those people. And the whole charade only broke down when we did a meetup and I showed up and they look like, "Who is this kid? And also is this illegal?"

Brian: Yeah. So this was IRC, was it a meetup in Finland at that time? 

Jani: Yeah, it was a meetup. So I used to have a really big sort of like a computer demo scene event called Assembly. And from that channel, everybody went to Assembly every year. So I tagged along at the end of summer with my crutches and my pimply face. And yeah, it did not go well for me.

Brian: And then you've mentioned previously that you took a hiatus at 16. Can you expand what you mean by hiatus?

Jani: So for me, I was an, I would say, an economically naive kid. At home we didn't talk about money. I didn't really realize that programming was something that you could make a living at and it was just a hobby. And then I went to high school and I got drawn into a different crowd. I started to get really into poetry and literature and the humanistics. And that's what I went to study at university as well. And it was only when I got to university and I needed to pay rent for the first time in my real life. I had to ask myself, how do people make money? And if my life was a movie there would be a scene where I'm with a pen and paper sitting somewhere and the first thing I write is “write poetry.” And then I scratch that off because nobody's going to pay for my poetry. And then the next thing I write is “write code.” And then the light bulb goes on. 

It's like, “Hey, this is actually something that you can do. And people are probably interested in reimbursing me for it.” So for me computer programming was a completely accidental career and it's been by far the luckiest accident. The fact that I broke my leg at 14 and this whole thing has snowballed into a career of 20 years and living in multiple countries and getting to travel all over the world and live a somewhat easy life, it was just being in that boat that was lifted by the tide that we all rose with.

Brian: Just like the lucky accident that led Jani into programming, his path into open source wasn’t an intentional one. Opportunities and challenges arose and he responded. 

Jani: I think it started from being a quite active contributor on Stack Overflow and answering similar questions and seeing people finding things difficult. And I think my first open source contribution, might've been, I think, a patch to a Backbone, the JavaScript library, because I was quite active in maintaining the Backbone community on Stack Overflow. So it was like, why help people here at the end user stage when you can actually fix these problems at the source? And from there, I took a few years. I wasn't an active open source contributor by any means for many years. It's only when I had opportunities to work with open source technologies at work and contribute to them as I learned more about it that it became a viable thing to do.

Brian: Yeah. I'm familiar with the Backbone community. That's like around the time I started doing JavaScript, and then towards the tail end of that Backbone. And then Angular came out of somewhere and then eventually we got to React, but it was a couple of years in between that even then. So yeah, hats off to you for contributing, even on a work time. Which I think is something that not a lot of folks think of as a possibility. You mentioned you answered Stack Overflow questions. When I find a Stack Overflow question, I look for the answer, but I don't necessarily always go answer the question if it's unanswered or if I do find any answer, I don't go back to it. So it's something that, a lot of folks focus on the green squares, but they don't focus on the actual green check marks in Stack Overflow. 

Jani: I mean, I think for me initially Stack Overflow was just like a place where I could meet interesting questions and problems and help answer them. I think it was the same intellectual exercise as learning to program was, in the first place. I'm not a person who has a true altruistic communities period. I do very few things for this higher cause. It was just something I find interesting. And I guess I was a bit bored in my job as well. So it was a great way to learn more about something. And open source in a way was initially an extension for me in that, although it has transformed into a very different thing in my life over time.

Neha: I feel like there's a corollary between trying to answer questions in an elegant way and poetry because there is a beauty to hitting the answer in the right way and being able to help that person. And that happens through prose, which is like answering questions and communicating to other people.

Jani: Oh, absolutely. And one of my strengths, I think as a software practitioner, not necessarily even as a programmer is that I have a fairly strong written communication skillset that comes out of being a writer and being a thinker and being a communicator of ideas. And I think one thing that most open source projects need more than bug fixing, they need better documentation and they need a better README and better way of communicating both the pros and the cons of that tool set. And the minor success that I've had in open source projects and the tens of thousands of GitHub stars that my projects in aggregate have amassed I think is largely on the strength of my writing and not necessarily the strength of my programming. I don't want to fancy myself as the Alexander Hamilton of JavaScript, but in some ways I do like that, the Hamiltonian idea of embodying ideas and the strength of writing.

Brian: Communication is key, whether it’s through documentation, a README, or even between contributors. Going back to Jani’s earlier years as an IRC channel manager, I was curious how he saw his role now in the communities he participated in. 

Jani: Well, not necessarily on my GitHub repositories that strongly, but I definitely do have a very active involvement in the programming communities around me. I run meetups and different kinds of social things for programmers. And my most recent project, FOAM, I think it was a very interesting experience in that sense. It was the first time when Discord was around when one of my open source projects went viral. And so I set up one of those and suddenly I had hundreds of people who are very interested and very excited to both contribute and to use and to give feedback. But at the same time, those people also needed a lot of things. They needed a lot of attention and they needed a lot of support.

And every idea is valuable, but not every idea is compatible with the idea that you have about a project. So in practice that community, is very much a richness and it's a wonderful thing to have, but it can also become a bit of a burden to a person. So for me, when I think about open source communities, I have a very complicated relationship with the idea that you as a maintainer have to be responsible for that community or the happiness of that community, or even necessarily the maintenance of your open source projects. I mean, I'm a creator of multiple open source projects and I'm a maintainer currently of precisely no open source projects, including any of the ones that I created myself.

And you had, a couple episodes ago, you had Daniel Stenberg from cURL. His software runs on 10 billion machines and he's been maintaining it for 25 years. For most of my open source career, I've idolized him particularly, but also people like him who have this steadfast ability to take on and carry something and nurture something. Maybe in the case of cURL, it’s not so much of a community as a mailing list, but it is definitely a stable resource for people. And so if Daniel is like a lighthouse keeper, he's sitting there with a pipe and making sure that all of these boats in the night don't crash ashore. I feel like I'm more of a firestarter, I run up and down the coast lighting fires. And when the boats crash on the coast, I prance off and do something else. And I used to feel really badly about that for many years. And it's led to some of the lowest moments of my life and my mental health journey. But I don't feel bad about it anymore, as much as I idolized Daniel, I also think that there's a space for creative thinkers and experimenters and that's where open source really distilled for me today. It's a creative venue. It's not necessarily an obligation in the same way as many maintainers take on.

Brian: And the self-awareness of understanding your limits and what you're good at, not everybody's good at managing community and taking requests and triaging tons of Stack Overflow questions. Those are very special people in the open source community, but there are also a lot of people out there, like yourself who create a lot of really cool ideas. I used to joke all the time that whenever I joined an engineering team that I professionally create tech debt, because I always get put on projects to start the project. And then they would like, for example, my previous employer, Netlify, they grew the entire front end team after I left. So I was the one creating all the worst React code and then they hired more people. And I was like, “Oh cool. I feel comfortable to let other people do the good work.”

Neha: Yeah. I relate to that so strongly, which is I also feel like I'm a starter and I'm not necessarily a great finisher, but you’ve got to know what you're good at. And if you are able to come into a community and inject a ton of energy and then people are then energized and able to do something, I feel like the gap, or the point at which you can take a step back and walk away is when people will know. "Okay, cool. I know what's next and I can figure it out from here." And you were talking about how important documentation is. If you document, "All right, well, here's the line and here's what the project needs to take a step forward." Other people have exactly what they need to step in. And there are other people who are really strong at that maintenance and that steadiness. And so it's like by being self-aware, you're creating room for all different ways of maintaining. And I feel like it's so important for us all to understand that it doesn't have to just be one personality to do this.

Jani: Oh, absolutely. And I have some personality traits that make me particularly vulnerable to this situation where I end up getting a lot of people excited about something and then taking responsibility for them. I've also in my career as a paid professional software engineer, I've hovered between engineering and management. And it's only in the last couple of years that I realized that leadership and management aren't necessarily the same things just in the same way as leadership and open source maintainer ship aren't the same thing. So I've carried every single role that I've had in head of any team, whether it's open source or professional, as an inspirational leader, as a bit of a cult leader type figure.

But I've never really actually looked into what is the management practice and what are the good habits that I would need myself in order to be happy and successful and actually help the people that I'm there purportedly helping. So that's something that I'm now focused on in my professional career is just like trying to actually be rigorous about, how do we create good software? How do we create an environment for good software? And I think source projects are a perfect testing ground for this type of challenge.

Neha: Creating a healthy environment from which a team can grow and thrive is key. And it’s not easy to do. Jani believes that to build a strong team, you have to be human centered and have empathy for the people you’re working with. And it’s not just about the end goal. Alongside this work, Jani still has open source projects, and we spoke about FOAM.

Jani: It's basically an open source project that modifies Visual Studio code to be more like a network notetaking environment for people who want to use it as a tool for notetaking and sensemaking, and these higher pursuits of thinking-by-writing. This whole “tools for thought” genre of software has been very interesting to me for a long time. And last year Roam Research—which is a San Francisco based company that built a tool for this—finally, took the step from going from free and beta to going paid, and it closed.

And at that point I started to get this very uncomfortable feeling because I had spent quite a lot of time putting my—I don't want to call it intellectual property, but my thought eggs into that basket. And I didn't feel comfortable with that being a subscription-based pay service that I would have to continue to pay in order to have access to my own thoughts. So I figured how hard could this be? And that’s, of course… the answer is always much harder than you think it is.

But in this particular case, I was very lucky that a lot of other open source developers had already done a lot of good work in building pieces of this, and then big as VS Code’s extensibility system and interoperability system between extensions is so good. I was able to just within a couple of weeks and a couple of 100 lines of code build essentially what was a usable version of , like 30% of our Roam Research’s features. Which was for me… it was more than enough to shift using it in my daily workflow. And I put that on GitHub, I tweeted about it a little bit. And then Sunday morning, one day I got a message from a friend like, "Did you know that you're on the front page of Hacker News?" And I, my first thought was (and I don't know what your cursing policy is, but you can bleep this out) but my first thought was, “Shit.” I've been on the front page of Hacker News before, and it's a place that many people covet but like many other dreams when you get there, it turns out to be quite different. 

But in this case it went surprisingly well, I think a lot of people were very excited about it. And within days we had 5,000 GitHub stars and hundreds of people in our Discord just clamoring to contribute. It's been a journey that is very interesting, but like I said, I no longer maintain that project. I've pranced off from that project into fresher grounds. And now there's a dedicated team of people who are maintaining that piece of software. And I feel very proud of what I've created. But I also don't feel like I have the right to take the credit for the software as is because by now other people have done so much more to it than I have myself.

Neha: So I feel like this is a really interesting part of the story. You said that you no longer maintain the project and you realize that you needed to take a step back. Could you walk us through that process of when you figured that out and when you realize that and how you did that?

Jani: Sure. So, I mean, basically from the day that I created the project, I would say it took about two and a half months for me to have two things: millions of dollars on the table from a venture capital firm, wanting to make it into a real paid product and a complete unhinged burnout that I could no longer manage. So from that point, I decided to walk away from both tables. I just walked away from the money table and also walked away from the open source table. And I just took a break. I took a break, but not only from open source, but I took a break from working. I had gotten myself into a state and within like 10 weeks that I was basically ready to just finally commit to the plan of buying a farm and growing carrots.

So it was light that burned very brightly for a short time for me. And after that, I've given the project some thought and I've given the current maintainers some sort of ideas on where I think the project might be beneficial in the future, but fundamentally, it's no longer my project. It's other people who own it and I am completely happy for them to take it to wherever they want it to go.

Brian: Stepping away may be one of the hardest things one can do. Not only was Jani stepping away from what sounds like quite a bit of money but he was letting go of something he created. What was the tipping point that made Jani realize this was no longer working for him? 

Jani: A lot of people have this idea that the toxicity of open source is the fact that somebody comes into your GitHub issues and demands something for free and is really rude about it. And then that makes you feel bad. And that may be true for some people, but for me, what makes me feel bad is somebody who's really nice and lovely and dedicated and helpful. But also what they want is just another piece of my obligation that I need to carry on, on my shoulders. And especially open sourcing a project in its early stage like I did with FOAM. The problem was that I hadn't yet had the opportunity to build the infrastructure for people to independently contribute to it. A lot of it was still very much like, “Well, let's see where this piece might fit.”

And similarly, we hadn't really been able to define what this project is and isn't, so everybody who came in with a great idea, I was just so desperate to be inclusive of them. And make sure that they felt valued and that they wouldn't leave because if I get a contributor to my open source project, that must mean that I'm very successful. But fundamentally not every contribution and not every contributor drives the project to the direction where you want it to go. And you need to be able to say no a lot more than you say yes. And I've known this for all my life, but sometimes when the situation happens, it's very easy to forget these principles.

Neha: Yeah. Also, just because it's a familiar feeling doesn't mean it hurts any less or it's any less tough you know? If you don't mind going there, what was going through your head when you wanted to walk away? 

Jani: Oh, wow. Yeah. I mean, people who host suffer from depression or anxiety, they might know that the inner voice that you have in your head and your low moments is not always like the nicest or the kindest. So I don't think I will repeat verbatim what that voice was telling me. But I think it's fundamentally… a lot of it boils down to having internalized value systems or dreams that aren’t necessarily my value system or my dream. The fact that somebody comes to you and dangles millions of dollars in front of your face and tells you that, "Oh, this product of yours could change the world." It's very easy to get bought into something like that.

Or even in the open source sense, if one person comes in and tells you, you're doing a good job, it's very, very easy to want to take on board that validation and everything that it gives you. But fundamentally what it also does for me at least, it creates a sense of obligation. And I think it's a very good question to ask yourself as an open source maintainer or really any professional is like, "Why do you do the things that you do?" And for me, it was the voice in my head, what it was telling me is that, "Oh, you need to take this opportunity. You need to run with it because this could be the opportunity of your lifetime."

But then on the other hand, the other words on my other shoulder telling me “This is not you, you are not capable of doing something like this.” And I'm not talking about “capable” in the sense of not having the skillset to do it, but just not having the strength to carry all of that on your shoulders.

Neha: Stepping away also poses the question of, what happens to the project when you leave? Who takes it over? Or does it just end? Answering that is hard, and even harder when you’ve reached your max. 

Jani: I mean, I could try to tell us a glorious version of this story, where everything went really smoothly and I did all the right things. And future employers listening, this wasn't me at my best. But basically I just disappeared for a couple of weeks and then when one of the main contributors pinged me enough times, I—without him asking—I went on GitHub, I gave him admin access on everything. I went to the VS Code marketplace. I gave him publishing rights to the project. Then I said, “There you go, fucking enjoy it.” Turns out that the guy that I gave it to is a very, very trustworthy and an upstanding citizen. So his name is Ricardo Ferretti, he's an Italian software developer.

And for him, he was in a different part of his open source journey. He was looking for a community that he could shepherd, he was looking for a project that he was really, really engaged in. So for us there.. when we talk about the two roles of an open source creator and a maintainer, with some people like Evan You, for example, who has been on this podcast before, I think, in some people, those two qualities happened to coincide in the same brain, but between Ricardo and myself, we happen to be like the two brains that were required to do this operation. And we still talk every now and then, and I'm very, very supportive of the project and I'm supportive of him. But fundamentally he has the free hands. It's his project now. And he maintains his contributor community. And I look every now and then, and there's tons of people, old faces, new faces, coming in, contributing. But it's no longer my beeswax.

Brian: Yeah. Hats off to you for finding someone who could take the reigns of the ship. But did you have any concern in your head, I know you took a couple of weeks away, but concerns that perhaps Ricardo, whoever you chose to take the the project could have steered it to maybe the multi-million dollar contract or to something that wasn't advantageous for the community that was already established?

Jani: I don't think that was a huge concern for me. I mean, I think you could interpret that question in two different ways. Like, did I have the fear of missing out, of missing out on an economic opportunity that somebody else then would take the credit for my work and be rich and that I would be sitting at home crying into my low thread count pillow? And the answer is no, that never entered my mind. And because I had had many conversations with Ricardo before, I kind of knew that we were vibing about where that project should go spiritually. So I didn't really have a problem with that either. But it could have actually gone badly. It could have gone to become a total disaster, but thankfully sometimes you just have to trust people and be okay to ask for help and rely on others. And that's what happened in this case.

Brian: Yeah. So I'm curious, are you still using FOAM today as a product?

Jani: Oh, I'm literally using FOAM right now. I mean, I jotted down a few notes of things that I might want to say on this podcast. And I'm reading them from my FOAM project right now.

Neha: There's actually something that came to mind and something that I strongly related to. I don't actively maintain any open source projects, but I have been involved in the nonprofit world. And so I was on a board and I eventually took a step back and taking a step back was because I got to the point where I really believed in the mission, but I had nothing left to offer. And bringing it full circle. I got to go attend one of the events as a normal attendee. And so my question for you is do you contribute to FOAM every now and then when you get the inspiration or get excited? Do you get to sit in the seat of an attendee for FOAM?

Jani: I think the door is definitely opened for me to do so. I think I might've sent a couple of patches, somewhere around the time when I gave up the project, but that's been now I believe more than a year ago, and I don't think I've made a single commit to the project. I think my contribution to the project today is a lot more about a couple of writings I've done on the project then the conversation I've had with Ricardo is just like more as a shepherd or as a spiritual adviser if you wish. I no longer have any technical contributions to the project. And I also believe that in some ways there are people who are much better suited to do that because as I've identified, and as we've spoken on this podcast, I really don't have the maintainer mindset when it comes to open source. And for me to put myself in that position to do it, it would not be difficult, but it would also be opening a door that I'm not sure that I want to walk through.

Neha: You're thinking about the responsibility right? Around those contributions as well.

Jani: Yes, obviously. And it needs to be stated here that all of this responsibility that we talk about is purely inside my head. As far as I know, in my entire career of being an open source or creator, nobody's ever told me that I'm doing a bad job maintaining a project. It's a wonderfully inclusive community and everybody has the best intentions and the best goals of the project in mind. But it's very, also easy to internalize these goals and make them your responsibility. And maybe that's why I should not be an open source maintainer, although I'm pretty sure that one day I'll be on the front page of Hacker News again. And hopefully that time I'll have the better wisdom to build that community in a different and more sustainable way. So it doesn't become this cataclysmic event that could make or break something that I spent time creating.

Brian: Yeah. And on this podcast, we talk a lot about the evolution of an open source project. But what doesn't come up a lot is the evolution of the open source maintainer. Listening to this conversation in real time, I'm like, wow, this is something that… I'm super happy you're on the podcast talking about this, because it's something that people should consider—at what point people should step away? Or what point they should bring on other folks? At what point, XYZ? And I think you have the self realization of those points, I guess, in hindsight. And I'm just hoping that folks are getting all of these points. I'm just reiterating those again.

Jani: Yeah. I think it's a very lucky situation to be in where you even have somebody that you can hand the project over to. I mean, that's a privilege that I think most open source maintainers do not have. Unfortunately, I'm sure that both of you are familiar with Nadia Eghbal's book about working in public and where she categorizes different open source projects. That most open source projects are still in a bit of a category where it's usually like a solo maintainer. The software is being used in some real cases so there's a responsibility there to keep it working. But also there is nobody else who is really willing to take it on. 

And so when you lock out into a community that is actually keen to contribute, I think what I would do next time and what I hope that anybody in that situation would do is start divesting personal responsibility as soon and as quickly as possible. And create that system and structure in place where it's actually possible for people to meaningfully contribute without running the project into a deadlock of conflicting requirements.

Neha: What I really hear and what you're saying is that when we're looking at how the open source community, or the norms are changing, what I hear is passion. We want to make sure that people have a good experience. And so for us, we're thinking about what the consequences are of where things are moving. And if we look at for example, your website, something that you had mentioned in the context of teams is happiness. And so it's very clear to me that that's something that's really important to you. So I wanted to ask, what “happy” looks like for you? And what does that mean?

Jani: When I was younger, I used to think happiness was being great at what you do, being the best possible programmer and fulfilling your life's purpose by just practicing your craft and solving really hard problems.

And then after a couple of burnouts and a couple of little negative experiences, following that path, I started to believe that maybe it is true what people say is that you don't need to live to work, you just need to work to live. And I was in a privileged enough position not to have work all the time, so I didn't work a lot all the time. And what I found was that while it gave me a lot more opportunities to pursue my other passions and my creative hobbies, and spend time with my friends, there was something missing in what life ought to be. And I think it was a sense of purpose.

And for some people, that purpose comes out of community, comes out of your friends or your family, your children, your church, whatever it is. But for a childless heathen and Peter Pan Syndrome victims like myself, that purpose often comes from what you do. And so where I'm at right now is I'm towing the line of, is there a sort of, for lack of a better word, a spiritual role of work in a person's life? Is doing a good job and being really good at what you do without letting it become the governing value system of your life is that maybe what happiness looks like? And for me that is currently that. But if I look at, as a manager or somebody who guides a team, I can't decide for them if that is their happiness. They might not be at that part of their journey, or maybe they will never get there. They will have a different answer to it. 

So happiness at work and happiness in life, I think is just allowing people to cultivate the kind of life that they want to live. So providing them the opportunities to have the autonomy to make key decisions about their life, paying them enough money so they have the liberty to do things that they want in life. And then also encouraging their sense of craftsmanship and mastery that hopefully they can get some of this spiritual fulfillment of work as well.

Neha: Yeah. It's like you are saying, you've held so many hats, right? You've been a mentor, you've been a manager, you've been a creator. You've been a maintainer, you've been a contributor, you've been a consumer. What energizes you?

Jani: There's this really annoying voice in my head that says, "Wouldn't it be cool if?" If I could turn that off, I'm not sure if I would, but a lot of my rationale for decision making is what would be the funnest, coolest, thing that I could be doing with my life right now? And there have been periods in which it looks like a backpacking trip in Southeast Asia, but then other times it's sitting down in a computer and exploring a new world or an idea using my art, my art being programming in a way. Of course I have other arts as well. But the fact that I'm an open source creator is actually fairly little to do with open source and is a lot more about just being a creative. And so what drives me is the need to create. And where does that come from? I don't know. I mean, I think that's a question for the brain scientists, not just programmers like myself.

Brian: It was great  to speak with Jani Eväkallio and have him on the ReadME Podcast. To learn more about Jani and his work, please visit jevakallio.dev. That j-e-v-a-k-a-l-l-i-o-dot-dev. And if you want to hear more about deeper discussions on this topic and the balance of open source, definitely have a listen to the latest episode from our friends over at the Compiler Podcast. 

I am Brian Douglas, aka bdougie.

Neha: And I am Neha Batra aka nerdneha. The ReadME Podcast is a GitHub podcast that dives into the challenges our guests faced and how they overcame those hurdles. In sharing these stories, we hope to provide a spotlight on what you don’t always see in the lines of code, and what it took to build the technology that inspires us all. 

Brian:  It’s been really great spending time with you. The ReadME Podcast is part of the ReadME Project at GitHub, a space that amplifies the voices of the developer community: The maintainers, leaders, and the teams whose contributions move the world forward every day. Visit GitHub.com/readme to learn more and sign up for our newsletter. Each month this newsletter will highlight new stories, best practices and opinions developed for The ReadME Project, as well as share great listens and reads from around the universe.

Our theme music has been produced on GitHub by Dan Gorelick with Tidal Cycles. Additional music from Blue Dot Sessions. 

The ReadME Podcast is produced by Sound Made Public for GitHub.

Please subscribe, share, and follow GitHub on Twitter for updates on this podcast and all-things GitHub. Thanks for listening!