Changelog

Sometimes you wanna release some code, but you also don't want people getting the impression that it's any good. The GLWTPL was made for those times. The one and only term/condition: You just DO WHATEVER YOU WANT TO as long as you NEVER LEAVE A TRACE TO TRACK THE AUTHOR of the original product to blame for or held responsible.

Zed Shaw – creator of Mongrel, Learn Python the Hard Way, and more – joined the show to talk through a recent Twitter thread from Zed where he shared his thoughts on open source, making money in open source, corporate interests and involvement, developer culture, and more.

Daniel Stenberg joined the show to talk about 20 years of curl, what’s new with http2, and the backstory of QUIC - a new transport designed by Jim Roskind at Google which offers reduced latency compared to that of TCP+TLS+HTTP/2.

Bummer. I've been there. It's so tough to make iterative change to software when those who are "in charge" of what you do everyday keeps interrupting or changing the rules to the game. Sjoerd Nijland writes on the Serious Scrum blog: As Scrum is a framework for developing, delivering, and sustaining complex products, and, if your management isn’t actively engaged in this exercise, it indeed may not make immediate sense for them to adopt the framework. Scrum could thus be perceived to be for developers only. Or perhaps Scrum was introduced by and is still contained to the development organization. In this case it may make sense to talk about the definition of ‘Product’. Would it make sense for the Management Team, to consider the organization itself as a product? If your team does Scrum, you should 100% read this.

Saron Yitbarek, creator of CodeNewbie, says this is the one question that will change your life — it did for her. I encourage you to read this from end to end, and then truly ponder this question for your life. I don’t remember why he said it, but I remember the car we were in on our way to a fancy networking event full of important people doing boss shit when he looked at me and asked, "What are you optimizing for?" ... I don’t think he knew it was that deep. It was. If reading this makes a significant impact on your life, I want to hear about it. Tweet at us.

What do Rafael Avila de Espindola, Chris Lattner, Tanya Lattner, LLVM Foundation, Linus Torvalds, and Red Hat's Jim Whitehurst have to do with this question? They're all in the mix of a wide debate over whether developers of the software and open source community should be required to behave respectfully to each other. Re: Rafael Avila de Espindola... Last week, a software engineer publicly quit a very popular open-source project, setting off a firestorm of debate within the programming world. Re: Chris Lattner... Chris Lattner tweeted: "I am definitely sad to lose Rafael from the LLVM project, but it is critical to the long term health of the project that we preserve an inclusive community. I applaud Rafael for standing by his personal principles, this must have been a hard decision." He also followed up with a longer blog post about the incident. Re: Linus Torvalds... In 2013, Linus Torvalds was called out for profanity-laced rants on the Linux email lists, which set the tone for the open-source world. He and the Linux community did an about-face — sort of — in 2015, telling members that their work would be criticized but asking them to "be excellent to each other" and to feel free to report abuse. Re: Jim Whitehurst... Red Hat is famous for its "meritocracy," modeled after the Linux Foundation. Amid the #MeToo movement against sexual misconduct, especially in the workplace, Red Hat says it's doing several things to make sure its culture is more welcoming, including sending its executives on a "listening tour." Jim Whitehurst says he has also been encouraging the company's top female engineers to get out and be role models and to speak up in open-source communities about being nice to each other.

Jessie Frazelle: There seems to be some confusion around sandboxing containers as of late, mostly because of the recent launch of gvisor... There is a large amount of ignorance towards the existing defaults to make containers secure. Which is crazy since I have written many blog posts on it and given many talks on the subject. Jessie has been doing the yeoman's work of Linux kernel isolation and making containers secure for awhile now, but much of that work has been overlooked or disregarded by others in the community. I'm on the outside looking in at this situation, so it's tough to call exactly what's going on, but according to Jessie: When you work at a large organization you are surrounded by an echo chamber. So if everyone in the org is saying “containers are not secure,” you are bound to believe it and not research actual facts. That doesn't mean Jessie thinks containers are secure (click through to read her take on that). There's a lot to dig in to here and think about. I'll pull out one last point: I am not trying to throw shade at gvisor but merely clear up some FUD in the world of open source marketing. I truly believe that people choosing projects to use should research into them and not just choose something shiny that came out of Big Corp. Now that's a sentiment I can get behind! Oh, and listen to this related episode of The Changelog if you haven't yet. It's a must-listen for all developers.

Eric Holthaus writes for Grist: Bitcoin’s energy footprint has more than doubled since Grist first wrote about it six months ago. It’s expected to double again by the end of the year... And if that happens, Bitcoin would be gobbling up 0.5 percent of the world’s electricity, about as much as the Netherlands. I can't be the only one paying attention to Bitcoin's rise in energy usage... That’s a troubling trajectory, especially for a world that should be working overtime to root out energy waste and fight climate change. By late next year, Bitcoin could be consuming more electricity than all the world’s solar panels currently produce — about 1.8 percent of global electricity... That would effectively erase decades of progress on renewable energy.

The problem, as described by James Vasile: Open source is a broad term that encompasses many different types of projects. There is a wide range of open source approaches, and sometimes it helps to think through how your open source approach matches your goals, resources, and environment. In many places we look, we see open source used as a catch-all term to refer to every project. We don’t have a common vocabulary to discuss open source in ways that take account of important differences. Mozilla commissioned a report that attempts to establish that common vocabulary so we can describe open source projects with clarity. Although this report was tailored to advance open source strategies and project design within Mozilla, and with the organizations and communities we work with, we also believe that this challenge is not unique to us. We suspect there will be many other organizations, both commercial and non-commercial, who will benefit from the model. The resulting framework consists of 10 common archetypes. Click through to learn more.

Zack Whittaker writes for Zero Day: Apple gave me all the data it collected on me since I bought my first iPhone — in 2010. This is what has largely stood out to me in the ongoing discussion about what data the four have on me and how they use it... As insightful as it was, Apple's treasure trove of my personal data is a drop in the ocean to what social networks or search giants have on me, because Apple is primarily a hardware maker and not ad-driven, like Facebook and Google, which use your data to pitch you ads. Want to request your data? It takes just a few seconds...

Very insightful post from Anil Dash about the impact of network effects on JavaScript and coding culture. Anil writes on his Medium: What this suggests is that JavaScript may be reaching escape velocity as a network, and as an ecosystem of related technologies. To be clear, there’s no winner-takes-all here — domain-specific languages will always have their uniquely valuable areas of focus. But for general-purpose coding? Everything from spreadsheet macros to Internet of Things hardware seems to default to having JavaScript be one of the primary ways to make things programmable.

Adam is on location at ZEIT Day talking with Jessica Rose about burnout, Henry Zhu about his passions and pursuit of open source, and Simon Willison about data and his passion for interesting datasets in the world.

Julia Grace joined the show to talk bout about scaling all the things at Slack. Julia is currently the Senior Director of Infrastructure Engineering at Slack, and has been their since 2015 — so she's seen Slack during its hyper-growth. We talked about Slack's growth and scale challenges, scaling engineering teams, the responsibilities and challenges of being a manager, communicating up and communicating down, quality of service and reliability, and what it takes to build high performing leadership teams.

If software is eating the world, who is writing that software? You are. Hongli Lai, Co-founder & CTO of Phusion gave a talk at his local Amsterdam.rb meetup and shared his thoughts on the impending deadline of the EU General Data Protection Regulation (GDPR) and the impact of socially unaware software that's eating our world. ...I feel more and more convinced we (as Phusion and as ‘builders of the web’) have a responsibility to provide a framework for thinking about the ethical implication of our creations. Hongli continues: We've seen companies suffer recently for a lack of that social responsibility (data breaches at Equifax, Facebook, Uber, etc). Public outrage was strong but also burned out quickly as the news cycled. For a while, the same quick fizzle seemed to be happening with the Facebook and Cambridge Analytica scandal. It's up to us to fight back. That doesn't mean go on twitter and rant, but to actually go an do something. Give a talk in your local area to your developer communities to create with social responsibility in mind.

Laziness is one of the three great virtues of a programmer (laziness, impatience, and hubris) Larry Wall talked about in Programming Perl. The "deep thinking," as they call it, which is always required before even a small issue can be resolved, seriously turns me away from programming. Or did turn me away. Until I started to think differently and encourage myself to be lazy. Here is how. Iteration! It's so freeing to operate on the basis of iteration — knowing that today's version is shipping with flaws that can only be resolved through the feedback loop. In this case, incremental is an alias of iteration. Software development is perfect territory for cutting corners, being lazy and remaining calm, because our work is often discrete and can be very incremental.

How you define success influences how and what you build. With that in mind, Cate Huston set out to learn how we developers do. I started with the Stack Overflow survey. Caveat: I hate it and I think it’s riddled with bias. For example, women make up ~fifty percent of the population, around ~twenty percent of technical roles… and 7.2% of the respondents to this survey. The SO survey is imperfect in many ways, but unfortunately it's also one of the only quantitative datasets we have. Cate also asked her followers on Twitter (which she admits is also riddled with bias): Many of the themes from the Stack Overflow survey showed up here – shipping code, learning and developing, autonomy....Another theme, though, was the theme of impact. People using what was built, benefitting others in some way. That's just a few of her findings. Definitely read the entire piece as it's riddled (😏) with insights. Also check out part 1 in this series.

I bet everybody has heard about popular lists such as awesome-python, awesome-shell, awesome-cms and such and find them incredibly valuable. Well... Awesome Dev Fun list is on the other side of that spectrum. It's a curated list of awesome funny libs/packages/languages that have no real value or purpose but to make a developer chuckle. If we can't have fun (and poke fun at ourselves), what's the point of it all? Also this list is embarrassingly short, y'all. Gentlepeople, fire up your PR engines...

Itamar hits the nail on the head: If you think of yourself as a Python programmer, if you identify yourself as an Emacs user, if you know you’re better than those vim-loving Ruby programmers: you’re doing yourself a disservice. You’re a worse programmer for it, and you’re harming your career. I've been preaching the gospel of generalization for many years. This industry moves fast. Today's new hotness is tomorrow's old and busted. Learn specific skills, yes. But always keep yourself above the fray. I am not a Rails Developer. I am not an Elixir Guy. Heck, I don't even consider myself a web developer. I solve problems; sometimes by writing software. Back to Itamar: The technologies you use, the tools you build with, are just that: tools. Learn to use them, and learn to use them well. But always remember that those tools are there to serve you, you are not there to serve your tools.

We're rebroadcasting the finale episode of the beloved Request For Commits on The Changelog. But don't worry, we'll be back with new episodes next week. In this finale episode of Request For Commits, we regroup to discuss the podcast from its start to its finish, lessons learned, community impact, and where the conversations around open source sustainability are taking place, now and in the future. It's the end of Request For Commits, but the conversations we've had will continue on The Changelog. We also have some guest-host appearances for Nadia and Mikeal planned in the near future on this podcast. So, stay tuned.

Do you wish you weren’t the only person slaving away on your open source project? Find out how to make your project pull request ready in this guide from our friends at Phusion. Floor Drees, writes on the Phusion blog: Newcomers to your project will turn to your issue tracker and look at (merged) pull requests, discussion forums, mailing lists or chat channels to form an idea of what your project is like and how and where they can best contribute. Optimizing these channels for on-boarding contributors will set you up for success.

Miguel Piedrafita –a 16-year old developer– is building a community for his likeminded-peers. CoderYouth is a teenager-only community, that is, you can only register if you are under 20. This community is exclusive by design. On its face that exclusivity cane be a bit off-putting, but I understand what they're trying to do. In short, when you learn to code at a young age, your friends aren't interested, so in CoderYouth you can connect with others with the same interests as you. Right now CoderYouth consists of just a forum and a GitHub org. The forum has a fair bit of activity happening, so he may be on to something...

Erica Lindberg, writes on the GitLab blog about preventing burnout: Set clear boundaries between work and home — I'm trying to limit how many days I allow myself to work over eight hours by either scheduling other activities in the evening with friends or my partner (it works better when you've committed to someone so they can help hold you accountable. These things can be anything from rock climbing to dinner or watching a movie) or simply blocking out my calendar and setting reminders for when it's time to shut off. And when it is time to shut off I'm come up with a "ritual" of shutting down my computer, turning off my keyboard, monitor, and light in my office – this makes it harder to come back to "just finish up one last thing" I really needed to be reminded of this. It's a shame when you know what to do, but you choose not to, and allow yourself to creep closer to burnout.

Carmen Andoh joined the show and talked with us about inclusivity, the 2017 Go Developer Survey, visualizing abstractions, and other interesting projects and news.

In this finale episode of Request For Commits – we regroup to discuss how we got here, lessons learned, community impact, and where the conversations around open source sustainability are taking place now and in the future. This might be the end of this podcast, but the conversation will continue on The Changelog. You should subscribe if you're not already.

Consumers of Stack Overflow content may not feel this way, but the developers who are engaging, commenting, and answering are being "lectured, down-voted, and leave with an empty feeling of wasted time." Constantine Murenin, writes in this OpenBSD mailing list thread: The StackOverflow company routinely deletes your comments, questions and answers, often for very superficial reasons (including automatically based on metrics) and without any regard to the individual quality thereof, and effectively without you having any control over the explicitly human-generated textual data that you entrust them with. (Most folks don't even know this, until they're already hooked and their questions/comments/answers are gone and unfetchable.) Who likes their own well-articulated notes randomly deleted for superficial reasons behind their backs? Why not let you see what got deleted, so you can decide whether it's worth reposting in another venue? The content you contribute to Stack Overflow is not guaranteed to be long-lasting immutable content. To dig deeper, click the headline, read this tweet, and read this post