The ReadME Project // @GitHub

Here’s what’s in store for this episode:

• 00:00 - Martin and Neha reflect on their experiences and growth throughout the past season of The ReadME Podcast. They announce an end-of-season hiatus but promise new content in the future.

• 01:29 - First Commit: How necessity (and a little laziness) is the mother of invention.

• 03:50 - The Interview: The hosts interview Ricardo Mirón Torres, the technical coordinator and community manager for the Digital Public Goods Alliance, a UN initiative aiming to unlock the potential of open source to create a more equitable world.

• 18:20 - Feature Release: GitHub Senior Editor Klint Finley is back to discuss Laravel and why it has become a "secret weapon" for many developers.

• 29:20 - #askRMP: The tables are turned in this edition of #askRMP, and the hosts take the hot seat to share the lessons they've learned this season.

Looking for more stories and advice from the open source community? To learn more from the authors and experts featured on this episode, check out:

• Is Laravel the happiest developer community on the planet? By Klint Finley

• Realizing potential with AI by Anton Mirhorodchenko

• Accessibility barriers are bugs, not feature requests by Mike Gifford 

• Digital Public Goods Alliance

• Tell us what you want to hear more about next season! Send us an email to: thereadmeproject@github.com with your ideas and feedback.

• And, we hope to see you at GitHub Universe 2023 November 8-9! Subscribe for updates. 

Special thanks to Ricardo Mirón Torres for talking with us about the Digital Public Goods Alliance and how more people can get involved. To Mohamed Said for sharing his experience with Laravel, and to Senior Editor Klint Finley for his reporting on the Laravel community—and for turning the mic on our hosts for this episode!

Subscribe to our monthly newsletter to stay up to date with The ReadME Project!

---

Martin Woodward: The thing I’ve learned most about myself doing this show is how bad I am at pronouncing names. I mean what you don’t hear is the people behind the scenes who have to do all the editing to get pronunciation that’s nearly the most correct out of the thousands I’ve had to do in retakes. 

But apart from that Neha, probably just exploring these topics with you and actually getting to catch up with you every month and just chat with people and chat with some amazing guests. I’ve really enjoyed it thank you. 

Neha Batra: I think the thing I’ve learned the most through the last two seasons of the ReadME Podcast is actually about myself. I feel like I’ve become a lot more comfortable in my skin. I started out really uncertain. I’ve started to really enjoy my role on the podcast—not to do the explaining, it’s to do the encouraging, to shine a spotlight on someone else. And a lot of times I can relate to the listener—I am the listener—but I get that chance to hopefully ask the questions that other people are asking, or add a personal perspective to it that very relatable. I think that was the biggest gift that I got. 

This is the ReadME podcast, a show dedicated to the topics, trends, stories and culture in and around the developer community on GitHub. I'm Neha Batra and I lead GitHub's core productivity team.

Martin: And I'm Martin Woodward from the GitHub developer relations team.

Neha: Welp, first up Martin, we’ve got a bit of news to share: After an awesome year… we ARE going to be taking an end of season hiatus. 

Martin: Yeah we are, yeah.  

Neha: Obviously it’s been SUCH a fulfilling year … we’ve learned about everything from gaming development to nuclear fusion, accessibility in open source …to the secrets of the world’s top maintainers. And we’ve met some amazing people—which means that while we’re away, you should definitely check out any episodes you’ve missed! 

Martin: But before you do that, we of course have a whole lot of brand new content coming at you right now in this episode.

Neha: Yep. We're going to speak with Ricardo Mirón Torres on the Digital Public Goods Alliance and senior editor Klint Finley is here to talk with us about PHP, Laravel, and what makes us a happy community.

Martin: And for Ask RMP, we turn the tables a little bit and answer a question ourselves. But first, it’s First Commit.

Sound Effect: First commit jingle

Neha: Today, we'll start in 1991. In Great Britain, the University of Cambridge to be specific, the place was crawling with scientists, droves of scientists working to make groundbreaking discoveries that would change the world. And those scientists needed a lot of energy and inspiration. What helps with that?

Sound Effect: Chattering, typing, office background noise

Martin: Well, for me, it's a nice cup of tea, but actually I think this one involves coffee, doesn't it?

Sound Effect: Teacup stirring and clinking

Neha: Yep. You got that right.

Martin: You see, the problem was all those scientists had to share a communal coffee pot. 

Sound Effect: Coffee percolating

They’d be right in the middle of their experiments, maybe pulling an all-nighter, and you're desperate, you need that shot of caffeine. So you walk all the way through the office, you get there only to find the pot empty and slightly smelly. It's so disappointing.

Sound Effect: Person saying "ahh man!"

Neha: That’s the worst.  I don't experience that as much anymore because I’m working from home, but I DO have memories from being in the office and the coffee running out and it's devastating. When it’s done, you have to tell people! 

Martin: But ya know, give a bunch of nerds a problem that could be solved with human communication, where you could solve it with a computer, you know which option they're going to take. They set up a camera to monitor the coffee pot, and it was this really low-res, early 1990s camera. They put it in the computer lab, connected it to the local network, and then they actually created a live feed that showed you just what was happening if the coffee pot was running on empty and then it saved you having to run down the hall and take a look.

Neha: So, like so many groundbreaking technological innovations before it, necessity—and maybe a little caffeine withdrawal—was the mother of invention. This VERY FIRST WEBCAM was no different: It was invented because people didn’t want to walk down the hall if there wasn't coffee waiting for them.  

And fun story, when I was in college, they had monitors for the laundry machine so that we didn't have to go all the way down only to figure out that the laundry machine was still occupied. Best invention ever, especially for a college dorm.

Martin: That's genius.

Neha: One of the goals Martin and I have had throughout this year is to really share with you all of the cool things that people are doing in the open source community around the world. And one of those things we wanted to explore today is a community that has grown up around digital public goods, which includes open source code, open data, open AI models, Wikipedia, and a lot more.

Martin: Yeah. Our guest today is Ricardo Mirón Torres, who's a technical coordinator and community manager for the Digital Public Goods Alliance. That's a UN initiative that was created to unlock the potential of open source to make a more equitable world. There are more than 30 international member organizations, including governments as well as GitHub and other private companies.

Neha: We're going to hear more about the equity gaps that the Alliance is aiming to close, but first we wanted to hear a bit more about how Ricardo got involved.

Ricardo Mirón Torres: So my background is in software development, but I was pretty much involved on open source communities, and I started to get a little bit more of the interest in civic tech, which is mostly how we do technology to solve public problems. And I work in a lot of different things around human rights, around mobility, around transparency of government, stuff like that.

So when the opportunity came to join the alliance, it was pretty much a straightforward, for me, a place to be to play a role in how the conversation of open source was relevant to solve some of these challenges. And of course, it's a good place where not only civic tech, but other things like digital identity, like GovTech, a lot of the things we're hearing now with AI are also very relevant to this conversation. And I think this is what led me to Alliance and helping shape this global stage for open source.

Neha: Wow. I'm a tactical person, so now my interest is super piqued. And I'm really curious, because you went over a few examples initially and you just covered this wide breadth of themes that DPGA covers, but tactically, how does the alliance determine what kinds of challenges to take on? And, do you have any examples of initiatives or projects that you're excited about?

Ricardo: As you know, not all open source is made the same and when we're trying to solve some of the world's hardest challenges like climate change, misinformation, disaster relief, and so on, these digital solutions need to take into consideration not only putting the source code out there, but also consider things like data privacy and security, the use of open standards for interoperability, the legal side of things as well, like having a proper license, copyright adherence laws and regulations, and all of these kind of things.

And these solutions must be, I think, consciously designed to anticipate and prevent and do no harm by design. So this is what we think digital public goods should be. And actually the Alliance has created a DPG standard, which is this set of criteria that help us define what characteristics should a DPG have. And as you mentioned, it's not only for software, but for data content, AI standards and so on.

Maybe the first project I would like to talk about is open source digital healthcare information system that was created by the University of Oslo, and it's called DHIS 2. It's the backbone of digital healthcare in more than a hundred countries and serves almost a third of the world's population. So even depending of where you are hearing this, your government or you might be using this software.

So I find very inspiring a story of one of these countries, which is Sri Lanka, a small country in the south of Asia, that leveraged this open source platform, DHIS 2, to create on top of it a COVID-19 tracker. And they were able to create and deploy this app in just a couple of days from which they detected their first case.

This allowed them to do contact tracing for COVID cases and they shared the source code of this app with the community just in a couple of months. And thanks to the fact that it was based on this already well-used digital healthcare platform, it was adopted by around another, I think 32 countries and probably helped save thousands of lives. And this is something that wouldn't have been possible at this scale if everyone was working on silos, for example, or with their own proprietary solutions, stuff like that.

This level of scale and adoption was of course not a coincidence. As I mentioned, it was not just because the code was open, but it was designed this way. It was well documented, it had the right license, it was interoperable with the system, and it was designed from the start to be a digital public good. And as important as this is that it had this global stage as a DPG with a strong community of maintainers, contributors, implementers and more.

Martin: Yeah. What's fascinating to me is why all government isn't done this way really because the taxpayers, the citizens, pay for the development of these things. And it almost seems strange that those should be proprietary. It's also fascinating how countries, you mentioned like Estonia and India who have high-tech populations are leading the way when it comes to some of these sorts of sharing and initiatives because they don't have existing kind of proprietary infrastructure in place and maybe don't have, or the state governments have the resources to be able to pay for proprietary products. So by being able to share them and in the open, you get to get those economies of scale as well.

So no, it is brilliant. But with all this stuff that's happening, obviously here at GitHub, we've been trying to do a big push to make sure all this open source is available to everybody, and that includes people with disabilities. Is there any specific tools within the Digital Public Goods Alliance to help with accessibility of these public goods?

Ricardo: There are many things that we consider, and some of these are more like we could say, best practices, and a lot of these best practices have to do, of course, with accessibility of the solutions in itself. We have a couple, for example, there's one created in Argentina that's made to assist with learning of children that have deaf disabilities. But there are several other examples, I mentioned with children, but also with refugees, with elderly people and so on. So this is definitely something that digital public goods take into consideration. 

Neha: That's really great to hear. And obviously from the GitHub perspective, one of the things that my mind goes to is it's such a privilege to be able to give tools and opportunities to people openly and transparently. And what comes with that is the fact that there's some maintenance work and there's someone behind the scenes that has to keep things up. So I was curious from your side, how do you ensure the long-term sustainability and maintenance with all of these digital public goods, and how do you measure the impact of them?

Ricardo: So it's really hard to actually measure the impact of an open source project in general, mainly because by design it's sometimes that way that you never know who's using that solution. But of course, sustainability is one of the key focus of the alliance. And part of what we do is we provide this support through our member organizations. We promote visibility of these resources, which in itself increases the likelihood of continued support, funding, contributions, and ensuring the availability and maintenance over time. 

It's also a great work that the projects themselves carry on, sometimes in ways they never could figure it out. There’s this really interesting project called RapidPro, which was developed I think even way back in 2005 or six or something like that, which was to start as a really small project with no real intention to kind of scale into what is right now.

And it got some funding from UNICEF to mainly be used to give assistance for organizations to use SMS services for not connected areas to facilitate communication between clinics and community health workers for food distribution and stuff like that. But then it got used in so many other use cases that they probably have never imagined.

For example, here in Mexico City where I'm from, they use RapidPro to alert and give notifications to citizens when we have earthquakes, which happens quite often. And I even personally worked on a project before joining the Alliance that used this open source tool to help guide families in Central America to report and search missing people and other human rights efforts.

So as part of this, we got to contribute back to the project as well, fix some bugs, and improve overall the open source project, which is in itself a digital public good. So it's a mix of the community actually using the project and contributing back as well as actual formal funding and support from organizations like UNICEF. But there are many others that are helping us achieve these goals to promote digital public goods and keep sustainability of these projects.

Martin: One of the important things as well is while some of these systems are relied on in times of crisis, that's also the worst time to be building them. So as the community manager, if people want to get involved now where things might be stable for them, how should they get involved with your communities?

Ricardo: So there are a couple of ways that you can join these different communities. One is directly through the open source projects that exist. And for this we have the digital public goods registry, which provides a single and easy accessible repository of all of these projects. And it has information surrounding where it's being developed, where it's being deployed, organizations that support these solutions. So if there's anything that's of your specific interest, that's a way that you can directly identify and discover these kind of projects where you can contribute to. 

But we also have some more formal community building initiatives that we have worked on. For example, last year we collaborated on Hacktoberfest to highlight some of these projects and for individual contributors to kind of participate in these activities.

But as an organization, you can also partner with us, with Alliance, or even join the Alliance. And since we’re a member base, there's a lot of strategy involved on how we host this community, how we push certain campaigns, for example, to highlight DPGs that are being deployed to address issues in particular sectors, or finally by engaging specifically with countries who are adopting these DPGs and kind of taking part on that digital transformation journey. So it depends if you are looking more for a technical contribution, then the DPG Registry is the great place, but otherwise if you're an organization with some other kind of interest, and you can easily reach out to us and we can collaborate on many things.

Neha: It's also really good to hear that there are so many different ways to contribute and it's not just the technical contributions. So I feel like that's a really good sign of a healthy open source project. Is there anything that you wish people knew or a common misconception?

Ricardo: On the digital public goods definition there are many views on what's a digital public good. And the work we do and for example, the standard I talk about is one of the ways that we help define through the organizations that are part of this Alliance create this common understanding of these kinds of projects. But this doesn't necessarily mean that only the projects on the DPG Registry are the only digital public goods.

We're always trying to search for new projects, new initiatives, especially those that are not necessarily software. This is an ongoing conversation in itself. The DPG standard is an open project that anyone can contribute and help shape this definition, and also help even nominate or promote some of these solutions. So it's not a super strict thing where everything’s set in stone, but rather that it’s an ongoing thing and something that’s really on the works with many topics like AI also changing a little bit of the landscape of what we think of open source.

Neha: Yeah, I like that. Like a living and breathing definition.

Ricardo: Yeah, exactly.

Neha:  Ricardo Mirón Torres, technical coordinator and community manager for the Digital Public Goods Alliance, thank you so much.

Ricardo: Thank you very much for inviting me and excited to see if some contributions come along to these digital public goods.

Neha: And to learn more about DPGA, check out digitalpublicgoods dot net.

Martin: So Neha, have you used PHP or Laravel at all?

Neha: Kind of. My first job, we were moving from Drupal, off of Drupal and PHP onto a Java backend and moving things into middleware and backend and separating things out. So I had a brief brush with it. What about you?

Martin: So remember I'm old and there was a time before Hotmail existed and Gmail and things, and I wanted to access my email from work, which was not allowed because like Port SMTP, whatever, and IMAP ports you couldn't access. So obviously I built myself a web client for IMAP using PHP at the time it was that I just ran on my own little web server so I could access my email from work.

That was my experience. And it was back before anything fancy like Drupal or Laravel actually existed. It was like raw PHP. And I think there's this bias still that exists in a lot of the dev community around PHP from the old days of creating unreadable regexes and things. But also now, especially with things like Laravel making things so easy, actually, I think there's some pushback against that, I guess at least that's the sort of sense I'm seeing. But we're going to talk today about how simple could actually be better for many people and just how happy and vibrant the Laravel community is.

Neha: And to do that, we'll be joined once again by The ReadME Project senior editor, Klint Finley. Hey Klint.

Klint Finley: Hey Neha. Hey Martin.

Martin: Hey. So Neha and I chatted a bit about this already, but why do some people kind of think that Laravel is their secret weapon?

Klint: Yeah, well, I mean, like you said, it just makes things really simple for people. So I heard from Fathom Analytics CTO, Jack Ellis, that it just makes them really efficient. They can write code very, very quickly. He says it saves them hundreds, maybe even thousands, of hours of development time.

And the reason for that is just so much is built into it already. He was so enthused about it that he rebuilt their product from Go into PHP, which just seems really counterintuitive. Like Neha was saying, they migrated from PHP to Java, and that's sort of the expected move is that you would go from something like PHP, a dynamic language like that, over to a compiled language like Java or Go for the performance capabilities.

But what Jack Ellis was explaining was that they didn't really need that infrastructure level performance. And if he did, he would've stuck with Go or he would build it with Go. But even for the hundreds of thousands of API calls that they process, PHP was still more than adequate for that. And they were able to work again, just much more efficiently, much more quickly using PHP than something that was less familiar to him, like in this case, Go.

Neha: And I think familiarity for sure, and making sure that the language suits the basic needs that you have, those are a few pieces of why someone would use it. But there must be something different about Laravel and why someone would want to choose it over anything else. So what are the unique features about it?

Klint: The big thing that people bring up again and again is just how it's essentially a battery-is-included, very opinionated framework. So there's not a whole lot of decisions that you have to make. A lot of things are already there for you, authentication obviously. So that's kind of the story for a lot of software though, that's the exact same thing that people who like Ruby on Rails will tell you. Though, I guess with JavaScript that's a lot more fragmented. So there's a big appeal for somebody maybe coming from the JavaScript world to see that, you know, can have it kind of everything already done for you and not have to cobble things together.

But even compared to Ruby, Laravel has a lot of, I guessm perks. Queues is something that a lot of developers told me they were excited that is just built right into Laravel, whereas you might have to pay for that as an add-on feature in another platform. Laravel does a lot to make deployment easy, which is kind of a tradition I think in PHP is just the deployment story there is really appealing.

Another aspect, Martin mentioned, is that there is a lot of prejudice against PHP that stems from the earlier days of it. And something that came up a lot is that PHP is just a lot better than people think it is, that it's evolved significantly over the last several years, over the last, I guess decade, where there was kind of a period where it stagnated in maybe the late aughts, early tens. But starting maybe around 2012, it really started to catch up and possibly even surpass other languages. So a lot of the things that we've talked about on this podcast before, type SADiE, pure functions for functional programming, those are things that PHP has now.

And then just going back to Laravel, Aaron Francis, who has been on this podcast before as well, just talks about the developer experience as being really, really solid. There's great documentation. He says, Taylor Atwell just really puts a lot of focus on things like just fixing what he describes as sort of paper cuts, just the little things that annoy you that he puts a lot of time and effort into fixing those sorts of things so the developer experience is just really smooth. And then the other thing is just the community is just happy. That's what really put me onto this story in the first place.

Martin: Yeah, I think if it hadn't been for Facebook, it felt like PHP would've died a long time ago. And then things like Drupal as well seemed to be keeping them alive. But when Laravel came and started becoming a lot more popular, it definitely seemed to see a new resurgence. And the community around Laravel in particular is just phenomenal, isn't it? It's a massive community out there.

Klint: And again, just a community that isn't doing a lot of infighting all the time. And I noticed, I would talk to people who were, would say, I love Node, but I wish JavaScript had a standard library or I remember the big fights over callbacks in Node, I think, or generics in Go, a lot of issues with packaging in Python that are starting to finally be resolved. Just all these little things that cause dissatisfaction or arguments and things like that.

Whereas in Laravel, I mean, it's not always an apple to apples comparison because a framework and not a language, but people were just really pleased with it and just really happy to be using what they're using and not interested necessarily in jumping around and doing stack hopping, which something else I tend to see a lot. They're just really kind of in love with PHP. I spoke with Mohamed Said about this, and he's a former Laravel employee who's now the VP of infrastructure at the Dubai cloud-based restaurant software company, Foodics.

Mohamed Said: Well, for starters, everyone in the core team is reachable. You can reach out to anyone on the core team and ask them questions. Show your pain points, what things you are working on, and how you think the framework can do something specific in a better way. People are reachable. It’s very easy to reach them and talk to them and they are always helpful. They are always engaged with all the concerns that people have. And that makes the person feel safe. As a developer when you know that the maintainers of the framework or the tool you are using, you know that you can reach them anytime, it makes you feel comfortable using the tool.

If you're stuck with something like it's very difficult for you to figure it out, you can reach out to anyone in the community either in the core team or in the community itself, and people are really helpful there. And that's something like I haven't seen in other communities, something that's special about the Laravel community.

Neha: I think what's really interesting about what Mohamed said was that the community is a very important key aspect to someone being comfortable with a language. And especially for a language that's as old as PHP, it's gotten the chance to learn a lot of the lessons through the different hype cycles as they've come and gone, and really hone in on what it wants to be good at.

And as someone who over time, I have to make so many decisions on a day-to-day basis, having a language that really intimately understands which ones I want to have autonomy over and which ones it wants to take that away from me and just make it easy and make it happen. There's something really special to go back to those basics and see those old languages that have survived this long and how they've evolved and are serving our needs today.

Martin: Yeah. So I mean, Klint, why do you think if people haven't looked at PHP in a while, and if people haven't really played with Laravel, why does this matter to them? Why is this important?

Klint: If you already know PHP, then definitely give Laravel a look. Especially if you haven't looked at PHP in a long time. You might be pleasantly surprised. But I mean, even developers who are only aware of Laravel's strengths can benefit. Maybe learn some lessons from how it works. Here's what Mohamed had to say about that.

Mohamed: The most important thing is that an open source contributor or an open source maintainer needs to think about building something for the people, not the code itself. So a lot of people get stuck into thinking that I'm going to write the perfect open source tool, I'm going to provide the perfect code and everything, but they forget about writing good documentation. They forget about showcasing how their tool works, what problems it does solve.

So that's something that Laravel does differently. It focuses on the use cases first and puts a lot of effort into the documentation. And even though the code is really good and it's well organized and performance is important, but Taylor focuses more on writing code for the people more than for the machines. So I think that's something that other open source contributors can learn from.

Neha: I love that people-centric view. Klint, thanks so much. And before you go, can you let us know what's coming up on The ReadME Project?

Klint: Sure. This month, Anton Mirhorodchenko shares his story of learning to program as a developer with cerebral palsy and how he uses GitHub Copilot and other AI tools to accomplish more than he could before. Then we have a guide by Drupal contributor Mike Gifford, on what you can Learn from Drupal's accessibility journey.

We also have Niek Palm’s guide to using the open source self-hosted GitHub Actions Runner created by Philips. And finally, as you noted at the top of the show, The ReadME Project is taking a little break. We're doing that in part because we're going to be developing new content and formats and newways to serve you as an audience. Tell us what you loved, what you'd like to see, and what we could do differently. Send us an email at thereadmeproject@github.com with your thoughts.

But… Martin, Neha, before I go, and while I still have the mic, I'm thinking this is my chance to do something I've been holding back on all season: Turn the tables and focus on the two of you for this month’s Ask RMP.  I’d love to know, what’s the coolest thing you experienced or your most memorable moment of the season?

Martin: Oh, without doubt, my favorite moment was talking with Professor Annalu Waller. That episode was just amazing for me, just learning all about the work that she did and just the pride that she had in her student. It was just wonderful to see. And probably seeing you meltdown as well, Neha. That was a good one in a different episode.

Neha: Oh, yeah, that was going to be my one… and also the interview with Kelsey Hightower where I absolutely just broke into shambles during his response to the question around one of his most memorable moments speaking at a conference, and hearing him talk about representation and the value of it. I don't think I've been the same since that episode, and it was exactly what I needed to hear. It was absolutely wonderful. Definitely most memorable moment was that, and then choking through the ending of that and trying to say thank you while being in tears.

Martin: Like any narcissist, I listen to the show and so I was listening through to the show later and listened to that part of the episode, and I was blubbing in tears thinking about your reaction while out for a walk in the countryside. So there we go.

Neha: That's it for this episode of The ReadME Podcast. We're so glad you joined us this season. Thank you to Klint Finley, Mohamed Said, Ricardo Mirón Torres, and all of our guests this season whose stories, expertise, and insights are what bring the ReadME Podcast to life. And to you, our listeners, we look forward to bringing you more soon and hope you'll keep in touch. Send us an email at thereadmeproject@github.com and be sure to subscribe, rate, and review wherever you listen to your podcasts. You can also learn more about what we do at GitHub by heading to github.com/readme.

CREDITS: The ReadME Podcast is a GitHub production. A huge thank you to our hosts, Martin Woodward and Neha Batra for bringing the season to life with their experiences, perspectives, and humor. Thanks as well to our senior editors, Klint Finley and Mike Melanson for their incredible stories and reporting.

Additional thanks to our production team at Reasonable Volume, Mary Dooe, Rachel Swaby, Elise Hu, Percia Verlin, Mark Bush, and Scott Summerville. The producers of The ReadME Podcast are Robb Mapp, Melissa Biser, and Virginia Bryant. Our staff includes Stephanie Moorhead, Kevin Sundstrom, and Grace Beatty. Theme music by Xander Singh. Please visit github.com/readme for more community-driven articles and stories. Join us again soon, and let's build from here.

Neha: I was hoping in post editing that they would make me sound a little bit more normal. But no, I...

Martin: It sadly hasn't worked yet. There's no AI that makes us sound normal.

Neha: It's not magic.