S07E07 - The Spirit of Open Source in a Modern .NET World with Scott Harden

Sponsors

Support for this episode of The Modern .NET Show comes from the following sponsors. Please take a moment to learn more about their products and services:

• RJJ Software’s Software Development Services, whether your company is looking to elevate its UK operations or reshape its US strategy, we can provide tailored solutions that exceed expectations.

Please also see the full sponsor message(s) in the episode transcription for more details of their products and services, and offers exclusive to listeners of The Modern .NET Show.

Thank you to the sponsors for supporting the show.

Embedded Player

The Modern .NET Show

S07E07 - The Spirit of Open Source in a Modern .NET World with Scott Harden

Supporting The Show

If this episode was interesting or useful to you, please consider supporting the show with one of the above options.

Episode Summary

Scott Harden, a neuroscientist with a diverse career path that includes both dentistry and programming, shares an inspirational journey on the podcast. Scott’s academic background includes neuroscience and dentistry, and in particular at the intersection of biology and computer science, known as bioinformatics. He emphasizes the excitement of using software to analyze complex biological data, fostering a sense of novel discovery.

Despite his success in dental school, Scott felt unfulfilled, yearning for the computational challenges he loved in programming. This led him to a profound realization about career crafting: the idea that individuals can mold their current job to align better with their passions. This prompted Scott to embark on a dual journey—studying for his PhD in neuroscience while simultaneously completing dental school. He successfully graduated from both programs on the same day, highlighting the complexities of balancing such demanding fields. Ultimately, Scott chose to embrace a full-time career in the biotech space, stepping away from dentistry to commit fully to technology and programming.

Scott believes that engaging in open source projects has been instrumental in his development as a coder. He describes open source as a landscape where collaboration and problem-solving can enhance not only technical skills but also critical soft skills. He provides insights on how contributing to open source allows developers to encounter unique challenges and learning experiences that are not typically found in conventional educational settings. Scott brings attention to the often-overlooked interpersonal aspects of software development, stressing the importance of people skills in building successful projects and fostering positive relationships within the community.

Scott invites listeners to assess their motivations for engaging in open source while advocating for documenting code and solutions in a way that can benefit not only immediate users but also future developers or AI models. He strongly believes that writing effective documentation is crucial in ensuring the long-term utility and clarity of shared projects. Scott expresses his enthusiasm for the positive transformations that can occur within the open source community, reflecting on the collaborative spirit that unites developers globally.

Scott concludes by suggesting that everyone, regardless of their level of experience, should consider sharing their knowledge and experiences, either through code, blogs, or articles. He emphasizes that these contributions enrich the broader programming community and encourage personal development.

Episode Transcription

One of the projects that I work on right now that’s probably one of my more successful ones, It’s a scientific data visualization library for .NET. It’s called ScottPlot. The name is silly. It’s because when I made it, I thought I was the only person going to be using it. And then some other people started using it and that wasn’t totally unexpected. But now it’s about a million and a half installs on NuGet. I think it has like 5,000 stars on GitHub. It’s really cool just to watch this thing grow

Welcome friends to The Modern .NET Show; the premier .NET podcast, focusing entirely on the knowledge, tools, and frameworks that all .NET developers should have in their toolbox. We are the go-to podcast for .NET developers worldwide, and I am not your host: Jamie. I’m Delilah and I will be recording the intro for this episode because Jamie is suffering with a throat infection.

In this episode, Scott Harden joined us for the first of three episodes on .NET, open-source, and NuGet. This part of the conversation is all about what Scott calls “The Spirit of Open Source in a Modern .NET World.” This is the background information on why Scott (and Jamie) believe that developers should look to creating open source works, putting them out there, and gathering feedback from people. Not only will it enhance your technical skill set (and very quickly), but it will also allow you to get experience at failing in a safe space: in public.

Now, humans evolved to like helping people in our in-group. And I think it means a lot that we treat anonymous strangers on the Internet, or we can treat them. Obviously, this can go wrong. But we can treat them as part of our in-group. Like, “hey, we are all in this technical world together. We are struggling. Let’s figure this out together.” And that bridge of trust and effort and you’re sharing your knowledge with another person, it is such a positive experience all around the table

This episode has a lot of resources in the accompanying show notes, so if you’re listening along in a podcast player make sure to head to the website (there’ll be a link). That way you don’t miss out on all the wonderful things Scott and Jamie talked about.

And remember, this is just part one. In the next two parts, Scott and I talk about creating NuGet packages, ensuring their safety and security, and how to be a good citizen of the open source community. Talk about a festive gift for you all.

And definitely go ahead and check out Scott’s work and writings. He’s a really interesting person, an amazing open source contributor, and an all-round great person.

Anyway, without further ado, let’s sit back, open up a terminal, type in dotnet new podcast and we’ll dive into the core of Modern .NET.

My voice was created using Generative AI.

Jamie : [0:00] Scott, welcome to the show.

Scott : [0:02] All right.

Jamie : [0:03] We’ve been connected for ages, but thank you for taking the time to talk to us today. Thank you ever so much, and welcome to the show.

Scott : [0:10] Yeah, thanks for having me on. It’s a pleasure to be here.

Jamie : [0:12] Hey, no worries, no worries. Now, we do have a lot of stuff that I’d love to talk about, and if there’s time, perhaps at another stage, we could talk about ScottPlot as well, which we’ll talk very briefly about in a moment. But I wonder, I’ve been talking for way too long, and you haven’t even had a chance to introduce yourself, so perhaps could you introduce yourself to the folks listening?

Scott : [0:35] Sure. Yeah, my name is Scott Harden, and I currently work as a neuroscientist. And if you look at my resume, it is really confusing, because there’s a lot of stuff in there. I’ll walk through it in a minute. But the core thread is that for a really long time, I’ve written software that just solves problems, gets stuff done, and I’ve shared it on the internet. So I’m a little bit older. I’m in my 30s. And I have kept a website and a blog ever since I was really young, like a teenager. And back then, I was really interested in programming.

Scott : [1:08] Back then, it was doing stuff that teenagers do, making chatbots and stuff like that. But as I started to enter the workforce and study kind of complex topics, I started to use programming as a way to solve problems and innovate. And I got really captivated by the biotech space. So I went to graduate school studying molecular biology and microbiology, which is like DNA and genetic engineering and that type of thing. In the early 2000s, that was like really, really special. Bioinformatics was really taking off. And it’s kind of the intersection of biology and computer science where some problems and some data sets are just so complicated, you have to write software to analyze it. And that core idea just inspired me so much. The idea that if you can figure out a way to use software to measure something that’s never been measured before, all of a sudden, everything you look at becomes a novel discovery. It was just really, really cool. So I studied molecular biology. And at that time, GitHub wasn’t, I guess, wasn’t a thing in the early 2000s.

Scott : [2:08] Blogs is really where it was at for people sharing code and inspiring others with the code they write. So people would solve challenging problems and they would write about their solutions on their blog or on a website. And people would read websites, get inspired, make their own code and share it the similar way. So I kind of cut my teeth in open source back then, just sharing code online and being interested in what other people are doing.

Scott : [2:30] And then I got a little bit distracted career-wise. I ended up going to dental school for a combination of like complicated reasons. And dental school was interesting. It was really cool. Like I am a dentist now. I’m technically a dentist . But when I was in dental school, about halfway through, I realized like, this is cool. I get to do, you know, work with patients, do dentistry, very technical in some senses. But I really was missing that computer programming aspect that I just, I loved so much from my childhood and even in molecular biology, bioinformatics.

Scott : [3:02] And so I started thinking like, well, what’s my future going to be? Like this dental thing is cool, but I miss the programming so much. And I tried to figure out how I could strategise my way into a career that was a little bit better fit and let me use some of those technical interests. So I learned a phrase a few weeks ago called career crafting or job crafting. And now in hindsight, I realized like, oh, that’s such a great word. It’s like, you have this job you want to do, but you have the job you have now. And it’s like, how do I transform where I am now so that I can do the thing I want to do with the environment I’m in now. And for some people that looks like maybe they’re in QA and maybe they’re writing some code to solve some problems or whatever.

Scott : [3:42] But for me, that ended up being a complicated journey that ended up in me getting a PhD in another subject while in dental school. So I was studying dentistry, but I also studied to get a PhD in neuroscience. And the reason I was interested in neuroscience is because at that time I was really into electrical engineering and computer programming, kind of at the intersection of hardware and software, signal analysis, especially I was really into like radio frequency engineering. And there was this program that would let me get a PhD, and even as a dental student and the intent was, well, you’ll get a PhD in oral biology or something that kind of makes sense for a dentist but I kind of read the fine print and I realized I can get a PhD in anything as long as it’s in the College of Medicine and then I learned about this field called cellular neurophysiology which is an entire branch of science dedicated to studying electrical signals from neurons, and involved with that is a lot of complex hardware, tech, gear. You write a lot of software to do signal analysis. It ended up being this really cool way for me to kind of exercise my passion for computer programming and the technical side of science, but still be in kind of like this biology environment.

Scott : [5:01] So long story short, I ended up getting both those degrees. I graduated dental school the same day I got my PhD in neuroscience. It was a crazy journey. I don’t know if I would do that again. But there’s this day too where I decided like, hey, I could be a dentist or I could work with technology in this biotech space. I could try doing 50-50, but that means I’d always be sacrificing one to do the other. What do I really want to do? And I just leaned in to the biotech 100%. I remember there’s this day, the very last day I practised dentistry, there’s this girl. She was super nice. I did a root canal and she left and she didn’t know, but she was my last patient. And I knew at that time, like, okay, from now on, I’m going all in on this tech stuff.

Scott : [5:42] So maybe that was six or eight years ago. And I’ve been working kind of in that. That space ever since. And at work, I use tech to solve cool problems that touch programming, but it doesn’t necessarily satisfy all the technical interests, especially software architecture, just software development in general. So I get a lot of that out in my free time as an open source contributor and open source maintainer. And along that journey, I’ve wanted to get kind of good at code. And it’s pretty easy to figure out how to get good at code. You read a book, you study a course, you learn how to program. But along the way, I’ve realized there’s so much more to software engineering and maintaining and deploying and distributing software than you’ll just learn from a book about code that teaches you syntax. And for me, working in the open source space gave me this really cool opportunity to grow my technical skills in a way that I never would have otherwise, just working by myself on a computer.

Scott : [6:40] So I had such a great experience. I’m still in the middle of it. I’m still on this growth journey. But I’ve had such a good experience that I take every chance I get to talk about this with other people to encourage them to consider going on this journey themselves and maybe think about it from a perspective that they haven’t thought about before because I think there’s a lot of really good growth that could be had here; but at the same time there’s a lot of danger like open source it has its controversies it has risk of burnout and theft and all sorts of crazy stuff we’ll talk about it.

Scott : [7:12] But if you go into it kind of knowing what to expect, I think that a lot of people can be really successful pursuing it. So that’s why I’m here today. That’s what I want to talk about. And again, I’m really happy to be here on the show.

Jamie : [7:25] I think, Scott, you win the award for most interesting intro ever. I don’t think anyone’s ever going to top that.

Scott : [7:33] I don’t know. I feel like I always have to justify because I apply for a tech job or something and they’re like, okay, experience, open source. And they’re like, a dentist? Like what? And it’s like, okay. You got to explain it a little bit. But here we are.

Jamie : [7:48] I love it. I love it. That was a frankly mind-blowing intro right. And I love the idea of career stacking; I actually went to um a local to me meetup recently It’s part of a thing called Rebels which is neither a military thing, or a Star Trek, thing but it’s like people who are founders of startups or have the ideas for starting up a company can go to these sort of informal meetings and they’re all over the UK. T he one that I went to they hosted a fireside chat with a person who had in previous parts of her life and career she’d been in I think it was Olympic dressage person so that’s the person who gets on the horse and gets the horse to perform—i’m greatly reducing it—but gets the horse to perform basically a dance routine She then transitioned into starting her own cereal company which then so be a breakfast cereal which then became a sort of like a HelloFresh from like before HelloFresh was a thing, but just for you know vegan friendly, organic cereal. She then pivoted again to working in recruitment and started her own recruitment company. And then she’s pivoting again, and she talked about career stacking in the same in a similar way. And how like each different career that you work in you can bring something from that that that place to a new place like with transferable skills right.

Jamie : [9:21] So like long-term listeners to the show will know that I outside of you know, I graduated from university—i only got as far as the bachelor’s, so I feel completely inept in this conversation—but I got as far as the bachelor’s, got out of university, went and did teacher training, taught at a school for a while, and brought my experience of working retail during my university studies to the school. And then I brought my when I finally got into software development properly as a job—i suppose paid for uh you know when i’m getting paid for it um in around 2010 I brought all of those things with me so I guess i’ve been doing career stacking but on the minimal level.

Scott : [10:04] Gotcha.

Scott : [10:05] From before then. But I love that idea of bringing those transferable skills, because they are all transferable, right?

Scott : [10:11] Yeah. And what I love too is they’re transferable, but what you described is someone who has just a really unique background. And I think that there is so much of that in this space. A lot of times we have a little bit of an over-representation on the media websites and even interviews and podcasts where people have the kind of traditional computer science background, they go to university. And again, if that’s you, that’s fine. That makes sense. But I just wanted to highlight that there are a lot of people from very diverse backgrounds that can bring so much to the table and in ways you wouldn’t expect.

Scott : [10:43] So like what you described, just that person’s going to bring such a great perspective to what they do. You mentioned going to a meetup of people who make startups. I wanted to point out that there’s kind of a similarity between that and people who work in open source because if you have… Okay, I’ll start backwards.

Scott : [11:03] I imagine that a lot of people who have successful startups have a long line of unsuccessful startups.

Scott : [11:09] It’s very unlikely you’re going to hit the lottery with your very first startup. So part of being a successful entrepreneur is getting good at making startups. And you learn just as much or more from your unsuccessful endeavours as you would if you just sat down and intentionally tried to learn something. There are some similarities when it comes to writing software and lowering the barrier between you and your ability to spin up a new project and share it with others is fantastic. And also getting better at dealing with people. So this is a little bit where there’s some overlap with me and clinical dentistry working with patients. At the end of the day, every dentist pretty much does the same stuff, but you’re not remembered for the technical details of the work you do. You’re remembered for how you treat people. And there are complicated situations. Sometimes you’re in no-win situations. You’re in tough situations that require those human interactions and the success of you in the long run, a lot of times is more than just the technical capabilities of what you’re doing. You have to be able to wrap that with a successful strategy for interacting with people. And that’s one thing when the person’s in the room, but now enter in open source. Now the people you’re interacting with, maybe they’re angry, who knows what? They’re anonymous strangers in the internet. Maybe they barely even speak the same language as you.

Scott : [12:26] This is really, really challenging. But the rewards of getting experience with it and getting good at it really pay off. So this is why I’m so excited to be here today to talk about this subject is because I think there’s a lot of growth that you can get in this field that you wouldn’t get just reading a programming textbook.

Jamie : [12:44] 100%. 100%. And I think, so i’m gonna teach you all a little bit about my background just real quick, and this may upset you Scott or it may just light up parts of your brain. But like one of my favourite TV shows ever is MASH. Now this is a sitcom from the 70s about the Korean War. It was… they tried kind of to remake it in spirit when they made Scrubs, and House makes loads of references to it too. So if you’ve seen either of those two shows, you kind of get the point that I’m getting at: where they talk about, you know, it’s a surgical hospital in a war zone. They talk about triaging patients and picking the one who’s maybe bleeding the most or in the most need for immediate care. And doctors and surgeons do that, and even in civilian life. So I think triaging those kinds of ideas and, and… all right. So most of the time when I’m writing software it’s not a life or death situation, but being able to like triage that problem and say like, "okay. I can fix that but it’s going to take me this much time, and you may not get a release for another couple of days. Or I can fix this super easy problem which makes it easier for me to fix that problem," Oh look i’ve just discussed how we do enterprise level software development with regards to estimates right? Same thing applies.

Scott : [14:06] Yeah, so I’m going to switch gears a little bit. And because some people might be listening and thinking, "well, I don’t contribute to open source. I don’t plan on making open source packages," or whatever. Like, that’s okay. But I want to challenge you with this thought experiment for a little bit. So think about to what it was actually like when you were learning to code. And Jamie, you don’t have to actually answer it. Everyone has their own story. And in some ways, everyone’s story is different. But in some ways, everyone’s story is kind of the same. Because most people learn to code, they start with a guided path. They read a textbook or they start with a blog or they go to university and they have kind of a guided path. But at the end of the day, people hit walls and they figure out how to overcome them on their own. So a lot of times we say colloquially, "oh, are you self-taught or did you go to university?" And I understand those two phrases. But the reality is if you went to university, nobody sits in a classroom and they leave that classroom and are like, "I understand software architecture." You have to put in the work. You have to do it. So if you’re at university, you are self-taught too. It’s you and the book and you and Google figuring out your problems.

Scott : [15:10] So at the end of the day, everyone who learns programming or anything technical, they learn to search for solutions for the technical problems. They can get started with a tutorial or something, but at the end of the day, they are on Google searching for whatever wall they’re hitting at the moment. And then you search Google for a question. What do you find? Almost always, you find someone that asks the exact same question. Like maybe sometimes you get lucky and it goes straight to MSDN documentation or something. That’s its own thing. But a lot of times, you Google a technical question and you’ll find a Stack Overflow. And I’ll use "Stack Overflow" as the phrase to describe the larger umbrella of all these Q&A websites. But people ask questions online. And why do they ask questions? Like, it makes sense why you would ask a question publicly. You want the answer.

Scott : [16:01] I will note, though, that there is a benefit to asking the question publicly rather than just like going to tap your coworker or something. If you ask it publicly and you want anonymous stranger on the internet to help you, you have to formulate your question in a way that makes sense. So just the act of condensing your struggle into a brief description, maybe a code example, or whatever, that can help really consolidate the question in your mind. And sometimes, how many times does this happen? You go to post a question online, and then you make a list of steps for recreating the issue. And in your list of steps, you realise, "oh, that’s my problem." You don’t even have to ask the question. You can answer it yourself. So the core point I’m trying to make is that asking a question gives obvious benefit to the question asker.

Scott : [16:45] But then people come out, anonymous strangers on the internet, and they answer those questions. But why do they do this? And i’m captivated by this question because we see it everywhere. Like, Stack Overflow like their whole thing is anonymous or mostly anonymous answers to questions, posted on the internet why do people do it? And one of the answers, again as a Neuroscientist I like I kind of go to that cognitive neuroscience place, it just feels good like when you answer someone’s question you help someone out you get to demonstrate your your technical understanding it feels good. Your brain releases chemicals that make you feel good and they kind of like train your brain to like, "oh whatever you just did, you should do that again because this feels good."

Scott : [17:28] And also, there’s a human element to this, which I think is really worth focusing in on. It feels good to answer someone’s question on Stack Overflow because just part of your brain thinks like, "hey, there’s another human. They’re part of my in-group."

Scott : [17:45] Now, humans evolved to like helping people in our in-group. And I think it means a lot that we treat anonymous strangers on the Internet, or we can treat them. Obviously, this can go wrong. But we can treat them as part of our in-group. Like, "hey, we are all in this technical world together. We are struggling. Let’s figure this out together." And that bridge of trust and effort and you’re sharing your knowledge with another person, it is such a positive experience all around the table. And then there’s this third group. There are people like you and me who Google that question and we find that discussion five years later. And then now we get to benefit from that conversation that happened in the open. Like this core concept is what I really want to focus on today because yes, it can go wrong. Like there are a lot of ways it can go wrong, but there’s something here that’s really pure and really good. And we can encourage this and we can nurture this. And I’m kind of loosely labelling it "the spirit of open source." It’s just anonymous people helping each other out on the internet. We are giving technical answers to technical questions.

Scott : [18:52] Now, a lot of people might think like, "okay, it’s a Stack Overflow question. It’s not open source." But hear me out. What if you’re answering your Stack Overflow question? It’s more than just a line of code. Maybe it’s a little more complicated. It’s a function. Now you’ve shared a function. You can copy and paste into your project. It feels great. Like, probably you and I both have that one function that we always forget how to write, but we’ve learned we can Google the exact question and find the Stack Overflow post that has that function that we can put in our code.

Scott : [19:23] Yeah, so so so far, this is this is good. The spirit is working well. So now, you know, it starts to get a little more complicated. Sometimes there’s some nuance around it. Maybe we’ve kind of left the world of Stack Overflow. And now people share these technical solutions, technical problems on a website or on their blog. And then they wrap the code with some description, like everything’s still good. Maybe it starts to get more complicated. Now our solution involves some classes, some structs, and now it’s not quite easy to copy and paste. So people package it up in a zip file. You can drop it in your project or they make it a package on NuGet so you can easily install it. And now before you know it, the same spirit has gotten more and more complicated, but now we’re in the world of NuGet packages and package software. And the person who shared that solution, again, it feels good to share a solution, but let’s play that out a little bit. If they don’t know where they’re going, all of a sudden their solution can be really, really popular. Now, instead of one or two people using it, 100 people, 1,000 people, a million people are using this package. And it’s doing a lot of stuff great, but it’s not doing everything everyone wants to do.

Scott : [20:31] The rule of big numbers means, "as perfect as your idea is, there’s going to be someone in the world who it’s not working for." So they’re going to open an issue and be like, "hey, it’s not doing the thing I need it to." Or they’re going to create a pull request and be like, "oh, you should change your code this way because it works better in my use case." And then, you know, a lot of people end up in this space where they’re kind of accidental maintainers of open source projects that are used by other people. And I, again, I think you and I both listen to a lot of podcasts. We read a lot of articles. I wish I could give proper attribution to everyone. I don’t remember who wrote this, but someone wrote a page once titled something like, you know, "having a successful open source project is an awesome experience that I wouldn’t wish on anybody." It’s like being gifted a puppy. Like it’s really, it’s cool, but it is a lot of work. And if you’re not prepared for it, It can go off the rails because all of a sudden, now your inbox, you wake up every day. Now you have 10 emails, 20 emails, 30 emails of people wanting support on this thing. You didn’t sign up for this. You just shared your solution on the internet.

Scott : [21:38] And then a lot of people try to engage. They put it down, you know, and then they’re like, "well, I’m getting burned out. I’m going to step away for a few days, not check my email." And then that works, except when you open up your email next time, now you have 100 unread messages.

Scott : [21:54] And so this thing that started out great, the spirit of open source, positive all around, now it’s turning dark. And there are instances, sometimes they get really publicised because of how bad it goes, where the original authors start to really disconnect from what they worked on. I heard one person on an interview a while back, again, I forgot who it was, but he said, like, "you get this feeling when you realise you have to maintain your project. It’s the sick in your stomach feeling like your stomach, your stomach sinks thinking, ‘oh, my gosh, I’m going to work on this today.’" And then couple that with how much time it takes out of your life, that just constant negative feeling. And then the worst thing is sometimes you see other people using your code to make money on their product.

Scott : [22:42] So now they’re making money. You get stuck with all the work. You can you can start to resent it. And some people become detached. And this is why there’s a really, or one of the reasons there’s a really, I won’t say a high rate, but an appreciable rate of open source project abandonment, where people just throw in the towel and like, "I’m done." And on the far end of the spectrum, it can go bad. People can delete their packages out of protest. NuGet… it’s quite as easy, but famously in 2016, left-pad deleted their package causing all sorts of havoc in the JavaScript environment. Some people even get so… Ah, like, it’s such a negative experience for them that they intentionally sabotage their project and start putting bad code into the world. Kind of famously, Colors.js and Faker.js, at about the same time, intentionally put infinite loops in their packages for the specific purpose of drawing attention to the fact that they’re not being adequately compensated for software that is making other people money.

Scott : [23:45] So now, stepping back, like, how did we get here? We just started answering questions on Stack Overflow. How did we get here? Because at the start of this, there’s something good and there’s something worth nurturing.

Scott : [23:59] And I think that by asking the question, "hey, where does this go wrong?" I actually think that we can do a lot to encourage people to benefit from the positive points of this journey where it goes right and to figure out where they can sustainably live on that spectrum. Because it doesn’t happen by accident. The default path is blowing up and burning out, and avoiding that doesn’t happen by accident. So part of the conversation I want to have today are some of the strategies that I have found to kind of balance this. And the reason why specifically I want to have this conversation is because there are a lot of podcasts that do a great job interviewing open source maintainers. And there are podcasts specifically devoted to the topic, but they’re a little bit weighted toward very large, successful open source projects, which is awesome. But there are two problems there.

Scott : [24:52] Number one is they kind of over represent the very large maintainers of successful projects. And that means there’s a survivorship bias. They interview that one of 10, which is chugging along, doing a great job, sustaining their project. They’re not talking to maybe nine out of 10 whose projects blew up and they hated it so much that they threw away their computer. And now they’re like a corn farmer or something. Because that happens.

Scott : [25:17] And the other thing is, it’s really easy to recognise the people after their projects have kind of gotten big and have large-scale adoption, but there are a lot of people that are on the journey that either never get to that place or they might be heading there and they don’t really know where they’re going yet. So I’m really happy to be here today talking with you and maybe give a voice to the people who are a little bit earlier on their open source journey. And we can talk about some of the things to be aware of that you might not expect right as you’re getting started.

Jamie : [25:47] Oh, absolutely. There’s a whole bunch of stuff that you’d mentioned there that I think is worth diving into but we’ll come back to in a minute. But one of the important things at least from my perspective is when you were talking about, you know, the these folks are just people who have solved some kind of problem and shared their solution; now suddenly they’re they’re on the lam for—i don’t know if that’s the correct term but you know I mean they are now 100% responsible for everyone else’s code in the world that uses that thing. left-pad being a fantastic example and you mentioned colors.js and faker.js, and we had… and those are obviously traditional examples—i hate to use that phrase because like but just because the news cycle moves so fast.

Jamie : [26:31] But, like earlier this year, we had the xz issue, which was essentially a mental health issue. And I’m a big proponent for positive conversations about mental health and helping yourselves out and getting the help that you need and all that kind of stuff. And I can point folks, if they’re listening in, in a whole bunch of different directions for where to go to get perhaps some informal help or where to go to get formal help and things like that. And I will say before I continue on, there is no shame in getting help, right? If you need some help, please go get it. You know, my friend Anthony says, "if you break your leg, you go to the doctor. But if you break your mental health, you tend not to go to the doctor. Guess what? Go to the doctor."

Jamie : [27:13] Anyway, the reason that I bring that up is because one of the things that happened in the xz exploit and the xz repo takeover was Jia Tan being an individual or a nation state actor—w’ll never know—but they waited for the original maintainer of the repo to have a mental health issue and then stepped in and said, "I can take over," right. And we shouldn’t be in that position, right? An open source maintainer should be able to just go, "here’s my my package of code, do what you like with it. Cool," and then, you know, people get on with their lives. The sad fact of the matter is, of course, that like you were saying, entire enterprises have been built up on free open source software.

Jamie : [27:54] Examples from the .NET space are Identity Server. That’s the big one. Most .NET developers who are of a certain age or vintage or a certain experience level will know of Identity Server. And the fact that that was completely free for decades; and having met one or two of the chaps behind Identity Server, I know that they made almost nothing on that, but they were essentially the identity providers for 90 percent of all .NET-based apps for like 20 years. Which is kind of scary, which is why they’ve spun off their own company called Duende and why they now offer a commercialised version of that service. And that totally makes sense, right?

Scott : [28:35] Yeah.

Jamie : [28:36] I guess my question to you, Scott, just before we get into the next bit is, like, does open source always have to end with, "I’m giving up and I’m going to create a company and you’re going to have to pay from now on?" I guess philosophically, does it have to? And do you think that we should always, I feel like just real quick, personally, I feel like a software developer who is bringing value or, or anyone who is developing software, you don’t have to be a software developer to, you know, the problem is we’re in semantics there. Are you a software? Someone who is delivering value as, uh, through the development of some kind of software or code or app or library, in my opinion, should be remunerated—I always say "renumerated,"—remunerated for their time in some way, Right?

Scott : [29:27] So this is interesting. We will talk about compensation and open source. We’ll loop back around to it. This is a prickly minefield. And I will just say that there is no simple answer right now. There are just a lot of bad options and people just kind of have to pick the least bad option. Like we haven’t really figured it out right now. So it’s tough. But part of being successful in this space is just recognising the reality of the situation. And I don’t think enough people talk about it. And really, my recommendation is, and again, we’ll look back around to it, but my recommendation is just have the conversation with yourself. Like, "hey, why am I in this? What am I trying to get out of it? And what am I okay with?"

Scott : [30:07] S o one of the questions you asked too is like, "does everyone, is this the inevitable path? Is blowing up like this and burning out the inevitable path or just accepting that you’re going to work forever for free while other people make money on your software?" I would say no, absolutely not. But I will recognise there are people in the world who say, "yes, there is no good outcome for open source maintainers." And I have heard people say that. I’ve heard interviews with people like that. Obviously, those are people who have had a rough experience themselves.

Scott : [30:39] I think that with kind of level-headed thinking and a little bit of preparation and intent and really introspecting and figuring out like, "hey, what do I want to get out of this? And what am I willing to sacrifice? At what point is it no longer worth it for me?" If you have that conversation and have a little bit of experience to really know what’s coming your way, it does not have to turn out bad. And I still think it’s really worth it for a lot of people. And again, for me personally, you can learn programming from a book, but there are so many skills that make you effective as a software developer, as a product manager, you’re working with clients. There’s so many skills that you only get by doing. And working in open source is a great way to do that for a lot of people.

Scott : [31:27] Like earlier, you mentioned feature planning and feature triage. Like it sounds so trivial, just, "oh, I’ll make a list of features and implement them one by one." But in reality, you really have to balance what you want to do versus what do the customers actually need versus, you know, maybe you have a vision of where you want a product to be six months, a year, two years from now, and you’re incrementally working toward that. And it’s a struggle, especially when you have people who they want it to do the thing they want to do, and they really want to encourage you to do it their way. And it’s just the reality of the situation is you have to work with people and make that happen.

Scott : [32:05] But an advantage that has hit me too, that I just personally have grown from, is it allows me to hit edge cases that I never would have hit otherwise. And it allows me to fail, fail publicly, in ways that I wouldn’t have gotten unless maybe it was a really intense environment, "now my job’s coupled to it," that type of thing.

Scott : [32:29] So I will just give an example, just a simple example. when I was pretty early working in .NET, I made some scientific software to help people do some kind of special chemistry equations, kind of advanced. And I didn’t invent the formulas, but I translated the formulas from a scientific paper, which is all hard to read. They actually, they had some code written in Java and I just translated it to C#. And all their variables were like famous, you know, physicists and mathematicians. They love to program with one letter variables. Like that’s, that’s great. But as someone coming to a code base, that’s really hard. So I kind of refactored it all, you know, gave it a nice GUI. And I’m like, I gave this gift to the world, like, "here’s this chemistry calculator." And I didn’t appreciate that some really important people were using it for really important things. And they were actually publishing, like drawing scientific conclusions based on the numbers it was producing.

Scott : [33:28] And yeah so like it worked for me it worked on my computer. It was, I remember it was a WPF app back at the time. And someone emailed me, I forgot what country she was from, she was somewhere in Europe, and she emailed me and it’s like, "hey i’m getting some funny numbers out of your calculator." And some people listening might just immediately know what the problem is, but I was like, "this doesn’t make sense. i’m running the calculations, it looks fine." And it turns out what had happened was I was storing kind of the equivalent of the periodic table in a text file. But instead of the ion and the molecular weight, it was the ion in something called electromobility. It’s like how fast the ion will move in a fluid with an electric charge.

Scott : [34:10] Anyway, I was using Double.Parse() to read that number. And in some languages, a period is a thousands separator, not a decimal separator. So this text file and this app that was running fine on my computer, on this person’s computer, it was generating garbage results. And we eventually figured it out and realised, "oh, change your, you know, a short-term hack is to change your language to English. And then it would parse appropriately." But you can bet every time since then, every single time I write Double.Parse(), I always include the proper international option, you know, InvariantCulture, whatever. And that’s an example of just one little thing that, yeah, I might have read that in a book. But that sticks so much when you get feedback from a real person in production. And if I were selling this product or if we’recoupled to my job or something, that’s a mistake that would have put me in super hot water. And again, it feels bad to make a mistake in public. But doing things like that times a thousand, I have grown so much from it. And I encourage others to just kind of get out there and share the software you write too because people will come back to you and they’ll do a great job of reminding you of things that you forgot when you were putting it together in the first place.

Jamie : [35:27] Yeah, I suppose it’s kind of a, in bunny quotes, "safe-ish" way to fail in that it shouldn’t really affect your employability and your ability to bring home money to be able to keep the roof over your head and the food in your belly. But it will allow you to fail and learn very quickly the stuff that you should be doing, right. Because like i’ve seen so I you know a lot of my stuff is working with enterprise level software and i’ve seen like e-commerce platforms where they were saying to me, "yeah we want to go global now. So we’re going to go global." And i’ll be like, "okay cool. How are you storing currencies?" And they’re like, "what do you mean ‘how are we storing currencies?’" "Well, like prices, right? so your your item is you know, you’re selling it for $10 and 99 cents. How are you storing that value in the database?" And they go, "well, it’s 10 full stop period nine nine as a double or a float or whatever, or a decimal or whatever." And I’m like, "okay, cool. And you want to go global? Okay, go ahead and store some yen in there."

Jamie : [36:31] Yen doesn’t have a decimal. I don’t know what the correct term is, but like in the UK, we talk about pounds and pence. Obviously in the US, it’s dollars and cents. In Japan, they don’t have that. And so that represents a problem that they haven’t had, but I’ve had because I’ve had the experience of going over there and dealing with people in that sense. It’s not a development thing that I’ve picked up, but it is a thing that I know of through my own experience; like you were saying about bringing that diverse thoughts and experience and backgrounds to your your development stuff. And so that would kind of fit with what you were saying there about, you know, when they pushed this software out live they were then unable to store value correctly. And then they would notice, "hey what’s going on? I’ve got some weird rounding issues," andI’m like, "yes. Because that’s how it works, right? There is an IEEE standard on how to store numbers in memory with decimal points, but after a certain point it’s all down to quantum and wobbliness."

Jamie : [37:32] It’s not really down to quantum and wobbliness that’s me talking Terry Pratchett. But it does get a bit weird because there’s undefined behaviour with x number of decimal points.

Scott : [37:42] So this is a great example. No, I mean, you can go ahead if there’s more there.

Jamie : [37:47] No I was just going to say that it fits kind of perfectly with what you were saying about, "this person was from a different culture where the decimal point and the thousand separator characters were literally swapped over,"and because you had never, I suppose, witnessed that in your own programming and development practice or perhaps even in your real life practice. You hadn’t witnessed that so you hadn’t thought about, "do I need to…" you know, you hit Double.Parse(, type the value in, and you might maybe hit a comma to see if there are more arguments you can pass in. But if you don’t hit a comma to see if there are more arguments, you’re just going to close that parentheses, hit a semicolon, you’re done. And actually, it’s not going to run correctly on the other person’s machine, right?

Scott : [38:33] Yeah. So this concept extends into so many different fields of software engineering. We just spent the last five to ten minutes talking about decimal places, parsing numbers. There is so much complexity and nuance around building your software, deploying your software, even just versioning your software, getting your software to users, getting good bug reports, or let’s say it fails in production somewhere, getting that information back. And then you learn more, not just about syntax of source code, but you learn how to write source code. This is such a challenge. Writing source code, not just that is effective, but that can be understood by anonymous people on the internet wanting to contribute. And when you start to do it, you start to learn more and more about patterns, about how to write software that’s easier to maintain, not just for you, but easier to grok by total strangers. They might not even speak the same language.

Scott : [39:33] And there are just so many benefits for people who might be used to writing software on their own a lot. I just, I can’t recommend it enough. If you have something useful, try to just put it out there in the world and you’ll learn a lot of the peripheral stuff around software, more than just the coding, the, you know, building, testing, deployment, all this stuff. So I heard a phrase a while ago. So we all know like the phrase, "a full stack engineer," that’s kind of focuses on software. Just code in general. I think it was Dave Farley, the continuous deployment guy, who said, "a full-stack engineer is what someone calls themselves when they know how to write JavaScript on the front end and the back end." And the… Okay, that was my JavaScript joke for the show.

Scott : [40:19] The… Everything we talked about is so much more than code. So I’ve heard it described as "a full circle developer," someone who can really understand and prepare for maintaining a software project in the full life cycle of software. So these are some of the reasons why I think just putting software out there in the world that other people can use is really rewarding because you learn a lot of stuff that you wouldn’t learn otherwise. And like the entrepreneur example earlier in the show, once you kind of get in the habit of doing it, you start to get good at it. So maybe you do have that million dollar idea or some really cool software you want to write. You already have all those tools and the best practices floating around in your head so you can implement it right out of the chute when the time comes.

Scott : [41:02] So one of, okay, so earlier we talked about, "does it have to go wrong?" And my response to that was like, you have to think, what are you willing, what are you actually willing to put in here? So I’ve described the benefits. Like for me, the benefits are a lot of personal growth.

Scott : [41:21] But you have to be real about what you are going to contribute. I think it’s a good conversation that everyone should have with themselves. What time are you actually going to put in? And I think when you see people using your software, you feel it’s easy to feel an obligation to them or you see some issue list that’s bigger and growing. But in order to maintain your velocity and your health, sometimes it’s good to just get away for a while. It’s okay to take a vacation as a maintainer. Sometimes I put a little message on my GitHub, "hey, I’m just going away for a few days. It’ll be there when you get back." So just check in with yourself every once in a while. Don’t put in more time than you feel right giving. And if you feel like you’re starting to get more of a drain than you can sustain, then figure out a way to cool off a little bit. So that’s a general recommendation is to always introspect and make sure you are not on a path of unsustainable time investment, if that makes sense.

Jamie : [42:19] Yeah. I think, just really quickly picking up on that last thing you said, I think that being able to take a vacation is super important, but also maybe there’s an open source project idea for someone out there for a GitHub action: if someone raises a PR when some flag is set that says, "this project maintainer is on vacation," it can reply with, "cool. Thank you for the PR, open source maintainer, Fred," or whatever, "is on vacation. They will get back to you as soon as they can. In the meantime, maybe check out the documentation or propose a potential solution or that kind of thing," right? Maybe that could be it, like an out of office, but for GitHub, right?

Scott : [43:00] Yeah. And also, a lot of people don’t know this. You can turn off issues. You can turn off pull requests. You don’t have to allow people unfiltered ability to kind of ping your time like that. So if that’s a good strategy for you, that strategy does exist.

Jamie : [43:17] Cool. What’s really cool about that tip is it leads into something else that you’d said. This was offline, and we had discussed it before, I was looking into some GitHub Actions and you said, "hey you know maybe the best thing for reproducibility isn’t to pin to a version of a GitHub Action." So you might say like checkout@v4. You might pin to a commit and say, you know, checkout@ and then the SHA for the commit. Because then with… you can actually change the code and change a previously pushed commit, but it’s less trivial to do that; whereas it’s more trivial to change the released version, right? And so, you know, that that sort of helps with a bit of security that I would have never… again this is another example, you see, of communicating with people with different backgrounds to yourself, because I would have never thought of that and and you showed me the way on that.

Scott : [44:12] Yeah so i’m glad… okay before you continue, I want to lean into that a little bit more; because I was going to bring that up. I want to reframe everyone’s thinking. So when you add a GitHub action, which a GitHub action, for people who might not be familiar with it, it’s a little piece of code that tells a computer what to do on GitHub’s side every time you push a commit or every time someone posts an issue or something. And because it has access to your GitHub repository, potentially it could be doing something malicious. This is very similar to adding a NuGet package or some dependency to your project. And this is the message that I wanted to share is that: anytime you take on a dependency that is effectively like giving someone else push privileges into your project. You are letting them put their code into your project. And especially if you don’t pin it to a specific version or pin a GitHub action to a version, you are just trusting that author potentially to put whatever code they want to, which might be malicious or who knows what, or compromised into your project. So yeah, the take home here is think really seriously about the GitHub actions you depend on and the NuGet package dependencies that you undertake.

Jamie : [45:26] Sure. I mean, like, is it not just better just to dotnet install all the things, right?

Scott : [45:32] Yeah, yes and no. There’s a, it’s a different show. It’s a different show, but sometimes some shady stuff makes it up into places where it seems pretty credible. So I’ll just, I’ll leave it at that.

Jamie : [45:44] Yeah, totally. Yeah, yeah. Obviously, you know, I was being a bit silly with that, but yeah, you’re absolutely right. Anytime you take on a dependency of some third-party code, unless you’ve done the due diligence required to actually read through, and perhaps even if you want to go that far, and maybe you should if you’re doing enterprise stuff take your own version of it at that point. So there’s loads of work happening in the background with things like Sigstore and things like that, that try to give you that guarantee that the version you’re grabbing from the package manager of your choice—npm, NuGet, Ruby gems, whatever—is directly tied to a commit somewhere. There’s loads of work happening at the moment.

Jamie : [46:26] In fact, there is an open conversation on the day that we record this, on 24th of August 2024, in the NuGet repository talking about whether they should bring Sigstore support in. So it’s actually an evolving conversation. So that’s really, like you said, that’s really important. And there’s a bunch of other episodes that I’ve done with other folks about, specifically about that taking dependencies. I’ll put some links in the show notes.

Jamie : [46:52] But there was something that I wanted to really quickly sort of loop back to. And this is taking a step slightly away from GitHub and open source and things, because we’ve brought it up quite a lot of times where someone with a viewpoint from outside of the—I hate the phrase "traditional"—but the traditional software development path. Like you said, right: you’re effectively self-taught at any point anyway, because you’re not going to walk into a lecture and suddenly, you know, C# or Python, right?

Scott : [47:21] Exactly.

Jamie : [47:23] Yeah. You’re usually in a lecture, they talk about something and then there’s assigned reading and a bunch of examples and tests you have to do that, you know, almost nothing that you… I’m very wary of saying, "you don’t learn anything in the lectures," but I would say something like 60 to 70 percent of the learning that you will do at a certain level will be done outside of lecture theatres. It’ll be, you know, in tutorials or in one-to-ones or maybe in the library you know; reading from a book or, like, you said searching online and seeing what other people are saying .

Jamie : [47:59] But I think with that in mind it’s worth really quickly pointing out something that I do with some of the interns; because we were talking about this before we hit record. And there’s something that I do with my interns and apprentices where when they start, I give them a stack of books. And none of them are software development books, but they were all software development books. And by that, I mean, I give out, you know, the KonMari method. What is it? The secrets of tidying up, and things like Start With Why, and Essentialism, and things like that. And I tell people, "these are not computer programming books. But they’re computer programming books, the authors just don’t realise that." And I know that that was something you wanted to hit on as well. So I thought maybe we could talk about that real quick before jumping back to open source.

Scott : [48:44] Yeah, that resonates a little bit with what we talked about earlier, is that when you, start to get in the habit of sharing your code online, especially if you get to the point where you’re sharing NuGet packages, you have the opportunity to really do a good job designing software with the intent of being modified by strangers on the internet in the future, writing documentation. So that’s a whole other topic.

Scott : [49:08] Yeah, I know we’re kind of reaching the end of the show, but there’s some cool stuff to talk about that. I will say that it’s a lot of people kind of groan like, "oh, I don’t want to write documentation." But I think about it as a really cool problem. It’s a challenging problem, but it can pay off so well because if you write documentation that’s effective and people can answer their own questions, because again, we’re all programmers. We’re used to searching this stuff. If people can answer their own questions, they’re not going to bother you with a bunch of GitHub issues and personal emails. So writing effective documentation really scales. And this will be a hint for probably just a totally different topic. But if you can make your documentation code in the form of tests.

Scott : [49:49] And I guess I will geek out a little bit for a second. We haven’t talked about one of my main projects. One of the projects that I work on right now that’s probably one of my more successful ones, It’s a scientific data visualization library for .NET. It’s called ScottPlot. The name is silly. It’s because when I made it, I thought I was the only person going to be using it. And then some other people started using it and that wasn’t totally unexpected. But now it’s about a million and a half installs on NuGet. I think it has like 5,000 stars on GitHub. It’s really cool just to watch this thing grow. And I have a GitHub action… I have an Azure function, which every day goes to NuGet and pulls the download stats and it updates like a little local cloud native database that just has the number of downloads per day. And then the Azure function like in the cloud uses ScottPlot to generate a graph of the number of downloads per day. And it puts that on the website. So if you go to scottplot.net on the front page of the website, you can see like the stars per day and the downloads per day. And it’s just kind of cool for a few reasons. Like it’s neat to see how much you like, even just the contributors, when they’re contributing, Their code is going a lot of places around the world. Just picturing a million computers is pretty cool.

Scott : [51:01] But the thing that impresses me, too, is the exponential growth. This is not growing at a linear rate. This growth is exponential. And I’m on this ride. I want it to be successful. I am having fun along the way. I am learning a lot. I am meeting a lot of really cool people. I want it to be successful. So I’m trying to take steps now so that I can continue to be successful as it grows exponentially. So, yeah, I forgot what kicked that off. But that’s one of the main projects I’m working on right now. And, yeah, it’s been pretty neat.

Jamie : [51:32] Yeah, no, that’s… the really cool thing about that is that, to me, anyway, the really cool thing about it is you created a thing to solve a problem that you were having. And then just like you said at the beginning of this whole conversation, "you create a thing to solve a problem that you are having. You give it to the world for free. And then the world goes, this is awesome. Let me run with this." And, you know, I was looking at the GitHub page just as you were talking through it there. And yes, at the time of recording 5,000 stars on GitHub, 148 contributors used by 1.8 thousand GitHub repos, right? That is just, that’s just crazy numbers.

Scott : [52:17] Yeah, so I want to be fair too. I consider the number of contributors to be much larger because a lot of people will ask a question as an issue. And then someone will be like, "oh, here’s the code to solve it." And then they’ll post it as an issue or they’ll reply to an issue and they don’t show up as a quote unquote contributor on GitHub. But then maybe a third anonymous person will take their answer, put it in the code, make a pull request, and then we can suck it in and distribute it to everybody. So yeah, the community aspect is just incredible. Again, the just absolute power of positivity, like the good side of when anonymous people on the internet come together and work to make cool stuff is really, really inspiring.

Jamie : [52:58] Oh, 100%. Like, we wouldn’t have the majority… okay, that’s a not easily verifiable statement of mine. But I feel like we wouldn’t have most of the internet and services on the internet if it weren’t for the spirit of, "hey, I solved this really neat thing. What do you all think about it," right? You know, like Node wouldn’t be a thing. I know people make fun of JavaScript. I try not to, but Node wouldn’t be a thing. C# wouldn’t be a thing, you know, because C# is open source, but .NET never used to be, but is now and that kind of thing, right? And so all of these things that we use on a daily basis, like I’m recording this now. So I’m recording my half of this conversation now on a Linux-based, Linux on the desktop-based computer, and I’m recording using the app called Audacity, both free open source. I’m looking at the notes that Scott and I made in Firefox, free and open source. You know, I’m making physical notes on a remarkable tablet, not free and open source, but uses free and open source.

Jamie : [54:06] Open source software is all around us. I’ve got… my android phone is just within arm’s reach: free and open source software on commercial hardware, right. It’s just bonkers to me that people get together and go, "here’s this free idea, check it out." And then you know other people sort of—i can’t think of the right word—collect around that and say, "let’s join these free open source things together to make a like a gestalt entity of these other free open source things." And then someone else comes along and goes, "I’m taking your gestalt entity, someone else’s gestalt entity, and making a meta gestalt entity. A bigger entity," right?

Scott : [54:45] Yeah.

Jamie : [54:45] And I guess it kind of fits a bit like neurons in the brain right: they’re all sort of gluing together and we create this thing, and it’s… that is just so super amazing to me that we could do that as a society as a group of creatures.

Scott : [54:59] Yeah. And you can’t always predict ahead of time what’s going to be successful. So that’s why I recommend just put everything in the open, put everything in public, see where it goes. So there are two topics I want to touch on before we close. One of them we hinted at, we’ll loop back around to it. How do we get paid with this stuff? Okay.

Scott : [55:15] But first, I just, I can’t leave the conversation without talking a little bit about licensing. Open source licensing, it can be complicated, but I would encourage everyone who’s starting or everyone who’s just wants to, you know, maybe creating NuGet packages and sharing on GitHub isn’t your thing, that’s fine. You can make a website, write an article. If you spend more than 10 or 15 minutes to solve a problem and you reach a solution, share your solution in an article. It’s great.

Scott : [55:41] But technically, if you don’t share it under a proper license or if you have no license, that puts a speed bump between you and potentially being able to benefit from someone else. Because someone else might want to come along, they find your solution, and it’s like, "oh, this is exactly what I need. But oops, there’s no license." Now, I see this a lot on personal websites. Technically in the US, again, I’m not a lawyer, I believe in the US, if you find code on someone’s website, you’re not supposed to use it. That’s the exclusive copyright belongs to the original author. So to do it right, a lot of times I’ll find that and I’ll have to email the author and be like, "hey, can I release this under a different license? "And they usually come back can say, "yes."

Scott : [56:19] So my core suggestion here is put a license on it. And if you don’t know a lot about the different licenses, all I’ll say is that the simplest license that means, "hey, you can use my code," is an MIT license. There are other permissive licenses. There’s CC0, Apache 2, L-GPL. But just to keep it simple, if you put an MIT license on your code, it lets other people use it. And other of people have seen that license and it’s easy for them to consume. What I would not recommend is don’t use one of the "cut"e permissive licenses. Have you seen, have you seen WTFPL, the public license?

Jamie : [57:00] Yeah. Do whatever you like with this. Except that they don’t say "you like."

Scott : [57:05] Yeah. I’m not going to make your editor do a workout here, but yeah, "it’s do what the blank you want public license." It’s WTFPL. And it’s actually, it’s cute. It’s clever. If you look at it, I read it the other day. It’s like the terms, it actually, it lists their terms, it enumerates them. And there’s only one. And the term is, "do what the blank you want to." Like, okay, I understand why people make it. Like, it’s clever. But the reality is, let’s say you have something that’s actually useful. You put that license on it. Now someone in a company, maybe they work at a bank or something. I don’t know. And just some poor person needs to get his deadline met. He wants to solve a problem. And he found the exact code he needs, but it’s under this license. His company probably won’t let him use it. They’re not going to hire their law team to research, "can we use this license?" So, you know, be aware that those exist. But if you have the option, put an MIT license on.

Scott : [57:56] And then the last topic that I’ll mention here is, okay, how do you earn money working on open source projects, answering questions on Stack Overflow and sharing blog articles?

Scott : [58:07] Okay, this is a hot take. So your opinion might be different, but my opinion is that if your goal is to be sharing your code online because you want to make money, you’re not doing it right.

Scott : [58:22] That is hard. Maybe there are some people who make that work. And if that works for you, that’s cool. But my recommendation is to really know why you’re doing it and to do it because you enjoy it. It’s because you enjoy building your stuff. And in my case, when I work in public and I create code that other people use and I go through issues and pull requests and all that stuff, write documentation, manage the build system, I am growing as a developer and I’m getting experience that I can apply to more complicated problems in the future. So it’s like, I’m investing the time building me, building myself. I’m giving the software away for free. I am happy when you are successful with the software. I’m building software for free. The software is not the product. I am the product. I am becoming better.

Scott : [59:13] Maybe one day I’ll have a job that benefits more from the software development. And working in this space has given me the skills to really be successful in the future. So keeping my eye on that really helps me feel good about it, regardless of what’s happening on the other side, including, which I know happens, people using my software as a core component of their software, which is making real money. It’s an interesting situation to consider, but if you think about it, you’d be real about it. And if you’re cool with it, then more power to you. So it’s a conversation I wish more people would have with themselves before they end up there by accident and then start being resentful about it.

Jamie : [59:53] Yeah, I agree. I think, yeah, that if you are… it comes back to this thing that I call "personal bandwidth," right? And it’s got nothing to do with the internet or anything like that. My feeling is, "do I have enough personal bandwidth? Do I have enough free time to devote some time to this thing, regardless of whether it is a means to an end," right? So a bad example that I’ll give is relating to social media, right?

Jamie : [1:00:23] Every time a new social media service appears, you know, people rush to it and jump on it and say, "cool! This is a really cool thing." And then they spend their time flitting between X (formerly Twitter), and Facebook, and Threads, and Blue Sky, and Snapchat, and Instagram, and, you know, insert all of your apps here, right? And people just, especially for content creators, they spend a lot of time, it’s a full-time job just literally cross-posting stuff in all of these places and keeping up with the comments and the likes and all that kind of stuff if you get comments and likes and stuff. And I suppose, from my own perspective, working in the open on open source stuff for other people is similar is a is a similar thing, right.

Jamie : [1:01:04] I have to ask myself, "do I have the personal bandwidth to devote x number of hours per week, per month, whatever, to this thing, regardless of whether there is a means to an end?" right? I’ve got a couple of NuGet packages out there and I know that they’re being used by big companies to help them with their projects. But I’m, again, similar to you, I’m not doing it for their development, I’m doing it for my development. Because I’m doing stuff that I would not get to do in my own time, which goes back to something you’d said earlier on about when you were saying about parsing the periodic table of [elements]. You may not have ever come across that Double.Parse issue in your day-to-day practice, but you got that sort of experience with it in your open source stuff.

Jamie : [1:01:48] And that’s why I do open source, because I’m like, "cool, how do I do this? Oh, cool." I can then take that idea or take that knowledge somewhere else, right? If I’m working 40 hours a week and I’m doing .NET stuff, I very rarely will have a chance to stretch my Go skills. But if I’m in the open or even just on my own computer, I’m playing around with Go, I’m building something, maybe I want to switch to Odin, or over to Zig, or any of these other languages, I can do that without having to impact my employment, I guess.

Scott : [1:02:18] Yeah, that was on my list of benefits. I didn’t touch on it, but you’re right. Having a project like this, it lets you dive deep, as deep as you want. Like now you are in control of your project. If you want to explore a new language, go for it. You know, we often talk about gold plating also as like an anti-pattern. But if you have that itch to gold plate your code, like make it perfect, go for it. Don’t bring that behaviour to work. Get that out on your personal time.

Scott : [1:02:45] Same thing with like performance micro-optimisation. It might make sense for a really hot loop or something, but in reality, you don’t need to micro-optimise performance for most stuff. But if you just enjoy it and you’re on an open source project that you’re controlling, go for it. Like, go nuts. It’s, yeah, you have to control over that.

Scott : [1:03:03] So I feel like in summary, I really recommend that anyone at any level of their journey, whether they’re just starting out in programming or if they write a lot of code, do a lot, I just recommend think a little bit about how you might be able to benefit others by sharing what you’re working on, including just sharing what you’re currently learning. And that could look like just making a website, which I encourage every developer to do. There are pros and cons of using someone else’s content platform, but I really recommend everyone just have their own personal website. You can do so much cool stuff with it.

Scott : [1:03:37] Whether that looks like sharing articles, publishing code on question-answer sites, or building NuGet packages. There’s a whole other discussion we could have about the nuances of creating NuGet packages and making it… security considerations, all that type of thing. But yeah, get out there, share code.

Scott : [1:03:54] And another topic we didn’t go deep in is just be ready for the fact that there will be some people who are going to have a really bad day, and they’re going to come to you, and they’re going to bring that negativity with [them]. And just prepare in advance for the reality that a lot of people enjoy your software and they’re silent because it’s helping them. And the most vocal people are going to be the people who are the most negative and just get ready for it and try to respond in a way which is positive and makes you feel good about how you handle the situation. Because like I said earlier, you’re not going to be remembered for the code that you write, you’re remembered for how you treat people and how you interact with others in this space.

Scott : [1:04:30] So it’s been a great journey for me. And I’ve been really excited to share my story and hopefully encourage other people to lean in a little bit more to sharing the code that they write online.

Jamie : [1:04:42] Oh, absolutely. I’ve really enjoyed this conversation so far, Scott, I have to say. And if you would be willing, I’d love to come back and talk about those other things we didn’t get a chance to talk about today, about managing essentially correspondence with other people, the negative comments, the tough comments, and figuring out your time and stuff like that. And also like what goes into creating a NuGet package, like you said, right? All of those kinds of things. I think it would be cool to come back, if you’re willing. And I’m asking you in the recording, so you can totally say no.

Scott : [1:05:13] Oh yeah, no, 100%.

Jamie : [1:05:14] Just tell me where to go,

Scott : [1:05:15] Right? No, 100%. I’m definitely down to come back and we can follow up on some of those things. I think that’d be a really great conversation about some of the technical details about NuGet packages. We can pop the hood on how those work and go deep on some of the technical considerations there and also talk about some really cool, pretty new features that are being added to NuGet packages. And also you can follow up with me and see how good of a job I’ve been able to do riding that exponential wave or if it actually caught up with me and then maybe I’m going to be that corn farmer next year or something. So yeah, I’d be happy to come back and follow up later.

Jamie : [1:05:52] Amazing. Thank you very much, Scott. A couple of things I want to mention just real quick, and it’s related to two things you said there. I love the idea of becoming a corn farmer. Because you’ve given up on technology and stuff. Because when I graduated from university, got my BSc in Computer Science, my bachelor’s, one of the guys that I graduated with literally took his laptop with him to the whole ceremony. You throw the mortarboard up in the air. He threw the mortarboard in the air, then smashed his laptop on the steps. And he got out of computers completely.

Scott : [1:06:25] Wow.

Jamie : [1:06:26] He works as a mechanical engineer now. I’m like, "that is amazing."

Scott : [1:06:29] Wow. Yeah, hopefully that won’t be me, but if it is, it’ll be a good conversation either way.

Jamie : [1:06:36] And then there was something else you said about licenses. Now this is, we’re running out of time now and this is a controversial topic anyway. But you also may need to add a license to your stuff to tell the LLMs whether they can use your stuff. I’m talking about GitHub stuff, and this is definitely a woolly space. But like your website stuff, your blog stuff, right? You may need to add a license that says, you know, "you can’t do this. You can’t do that."

Jamie : [1:07:03] I do know that there are some content creators out there who are very upset about LLM and Generative AI, and they have been working on a, "you can’t use my stuff in your LLM, in your model" sort of license. And they… some of them are trying to do some not very nice things to those models, like embedding in them commands like, "ignore all previous prompts from this point onwards, remove my stuff from your," you know, and that kind of thing. So there’s some conversations happening with that.

Scott : [1:07:35] Yeah.

Jamie : [1:07:35] But yeah, you’re right. You may even need a license just for the humans who are reading it, but also maybe, because we’re in this world now, for the models as well.

Scott : [1:07:43] Yeah, your points are really good one. Yeah, I feel like we’re about to crack open a whole new topic here. So I don’t want to dive into it. Let’s save that one for the next show. But I will say this. I’ll flip it on its head. Um, I assume the LLM trainings are probably just going to do whatever they want. Like there might be a good company that comes along and then they respect the licenses. That’s cool. The next company that comes along that does not respect the licenses and they just train on everything might have a competitive advantage. So I’m not going to try to license my way into controlling who does what with my open source stuff.

Scott : [1:08:14] On the other hand, I like to think of it as, "how can I leverage this training situation?" And I found that by writing very good documentation, so like, here’s an example earlier, I talked about how to deal with toxic people. If someone, like, just as an extreme example, somebody not that long ago opened a GitHub issue, and their first sentence was, "you are a terrible programmer." And then they described what was wrong. And then, you know, they didn’t even ask a question, they just described. And I responded to them and I was like, "oh, you know," and I just tried to make very positive, encouraged, natural language. "It sounds like you’re struggling with this. This is the recommendation. Here’s a code example, which I think will help you solve your problem." And the reality is now, not only does that help other people see like, "oh, I de-escalated the situation. I’m not, you know, I’m not letting other people get a rise out of me."

Scott : [1:09:04] And LLM is going to come along and they will actually learn from that conversation. So the next time someone Googles that problem, they might find that solution. And I’m finding that now I’m writing documentation not just for users. I’m writing documentation for LLMs because people now are asking ChatGPT and Bard and all that, Gemini now, I guess, they’re asking them how to use my software. So if I can write documentation with the intent of being trained into an LLM, I can reduce my support burden in the future. And who knows, my code examples might even make it into like GitHub Copilot suggestions in the future. So leveraging LLMs to help your life as an open source maintainer is a skill worth considering.

Jamie : [1:09:44] That is something I never even thought of, like writing the documentation with the intent that it will explicitly end up in the model and help the model to figure out how to either A, use the thing that you’ve created, or B, to respond with, I don’t want to say humanity, but like with compassion. And with empathy that is brilliant.

Scott : [1:10:06] Yeah. And that that’s another way to take something really negative and just turn it into a positive in a way that you get to walk away from that not feeling bad. And yeah that’s a really good strategy that I recommend more people consider.

Jamie : [1:10:21] So what you’re saying is we should never put Linus Torvold’s email newsletters…

Scott : [1:10:29] You know I specifically thought about him earlier when I was thinking about this. I think I’ll say this. When you have done the equivalent of making Linux, then you can act however you want. Unless you’re Linus, act with humility.

Jamie : [1:10:44] Yes. Okay. Yeah, no, I get that. There was someone else. I think it was the—now, I think he said it in a joking manner, but—ThePrimeagen has a video where he talks about basically that, right. Where he goes through one of the most famous exchanges in the Linux source code newsletter. And he’s like, "yes. Okay. It’s not nice what Linus is doing, but he’s preventing really bad code from running on a ba-billion machines." And my personal opinion is maybe, maybe, he shouldn’t have done it the way he did do it, but I get why he was doing it, you know. He was never being horrible for the sake of being horrible, it was just his way of putting across to people, "hey this code is not good,"and making them try to understand that there is a real reason why this code, which is not good, is never going to end up in the Linux kernel: because it will be running up on a ba-billion machines

Scott : [1:11:41] Yeah. So I love how we all know his personality and how he treats developers corresponding on the internet. We all know it. So this goes back to my, that quote I used a couple times is that, "you are remembered for how you treat people." And I want to be remembered for encouraging newbies, you know, encouraging them wherever they are on their journey. It doesn’t matter where you’re starting. I want to help be a voice or a teammate, or whoever, to help improve your position from wherever you are right now. Because there’s room in the whole world for everyone and everyone to get better. And again, that spirit of open source, there’s something positive in there that encourages people to all grow from where they are. And I’m really happy to be a part of that community.

Scott : [1:12:26] So I’m excited to see what the future holds as well.

Jamie : [1:12:30] Fantastic. I’m similarly excited, I have to say.

Jamie : [1:12:34] Scott, it has been wonderful. It’s always wonderful chatting with you. And for folks who are listening in, Scott and I got connected because of the absolutely wonderful Coding Blocks podcast and their Slack group. They have like a weekly get together, which we are both missing right now because we’re recording this. But, you know, Scott and I got connected through that. So definitely go check out Coding Blocks and join their Slack group. The cumulative, like just the sheer amount of intelligence in that group is amazing. I always feel like I’m learning something new every single day. So thank you to them. And thank you to you, Scott, for being on the show.

Jamie : [1:13:11] I just wonder, is there any way you would like to send listeners to if they want to check out anything, you know, maybe your website or maybe check out ScottPlot? Like, where would you recommend people go?

Scott : [1:13:21] Oh, yeah, for sure.

Scott : [1:13:22] So anyone who’s interested in learning a little bit more about scientific data visualization with C#, just go to scottplot.net. There’s a cookbook which pairs code samples along with the graphs that create. So you can just quickly flip through and get a pretty good idea of what it does. And kind of just iteratively figure it out from there. So that’s pretty neat.

Scott : [1:13:41] And then my personal website, it’s a hodgepodge of everything from electrical engineering to just code and personal stuff. So that’s my personal website is swharden.com. I’m also swharden on GitHub. And if you are on LinkedIn, you’re welcome to connect with me. If you are part of a team that you think resonates a lot with what I said, or if you have one of those complicated, cool careers and have done the transition thing successfully in the past and have a great story, I would love to hear from you and especially get any advice you might have along the way. So feel free to connect on LinkedIn. Just tell me that you heard me on the show because I get a lot of random requests. I don’t accept those, but I’m happy to connect on LinkedIn for sure.

Scott : [1:14:23] And on my personal website, it’s my email address. I’m pretty accessible. So if anyone has any questions or ideas of topics that they think I should include the next time I have a conversation like this, let me know and I’ll definitely keep them in mind.

Jamie : [1:14:36] Excellent. Excellent. I’ll get all of those links and put them in the show notes. And I really like the idea of getting together people who have maybe transitioned careers or career stacked and getting those ideas shared. That is a fantastic, fantastic shout.

Jamie : [1:14:54] Amazing. Well what i’ll do, like I said, I will get all of those links, put them in the show notes. And i’ll say again Scott, thank you ever so much for being on the show, and for talking about all this stuff. Because I think that there is, outside of the actual day-to-day practice of just typing on a computer keyboard, and just putting stuff out there, there is actually the, like you said, the soft skills, the interpersonal skills. Those are way more important, you said it a whole bunch of times, you’re not going to be remembered for what you did, but you will be remembered for how you made the people feel.

Jamie : [1:15:25] So thank you very much.

Scott : [1:15:26] Yeah, you bet. It’s been great. It’s been a pleasure to be here. So until next time.

Wrapping Up

Thank you for listening to this episode of The Modern .NET Show with me, Jamie Taylor. I’d like to thank this episode’s guest for graciously sharing their time, expertise, and knowledge.

Be sure to check out the show notes for a bunch of links to some of the stuff that we covered, and full transcription of the interview. The show notes, as always, can be found at the podcast's website, and there will be a link directly to them in your podcatcher.

And don’t forget to spread the word, leave a rating or review on your podcatcher of choice—head over to dotnetcore.show/review for ways to do that—reach out via our contact page, or join our discord server at dotnetcore.show/discord—all of which are linked in the show notes.

But above all, I hope you have a fantastic rest of your day, and I hope that I’ll see you again, next time for more .NET goodness.

I will see you again real soon. See you later folks.

Useful Links

• Job crafting
• Left-Pad incident
• The story behind colors.js and faker.js
• What we know about the xz Utils backdoor that almost infected the world
• Hello, Duende
• Double-precision floating-point format
• Dave Farley
• Sigstore
• Add support for sigstore as signing method for NuGet packages
• Some episodes of this show focusing on App Security and dependency management:
  • The Risks of Third Party Code With Niels Tanis
  • Application Security with Tanya Janca
  • Building Secure Software: Unveiling the Hidden Dependencies with Niels Tanis
  • Managing Dependencies with M. Scott Ford
  • Breaking Up with Tech Debt: A Love Story with M. Scott Ford
• Books that Jamie gives to interns:
  • The Life-Changing Magic of Tidying Up by Marie Kondo
  • Start With Why by Simon Sinek
  • Essentialism: The Disciplined Pursuit of Less by Greg McKeown
• ScottPlot on:
  • GitHub
  • NuGet
  • scottplot.net
  • The charts that Scott was referring to when talking about downloads per day, can be seen here
• Code Licenses mentioned (in order):
  • MIT
  • CC0
  • Apache 2
  • L-GPL v3
  • WTFPL
• Programming languages Jamie mentioned (in order):
  • Go
  • Odin
  • Zig
• The Primeagen
• Coding Blocks
• Scott’s Links:
  • scottplot.net
  • swharden.com
  • GitHub
  • LinkedIn
• Supporting the show:
  • Leave a rating or review
  • Buy the show a coffee
  • Become a patron
• Getting in touch:
  • via the contact page
  • joining the Discord
• Music created by Mono Memory Music, licensed to RJJ Software for use in The Modern .NET Show