Medium

Adam Jacob (co-founder and creator of Chef) tldr’d his ideas to create sustainable free and open source communities by saying, “we should stop focusing on how to protect the revenue models of open source companies, and instead focus on how to create sustainable communities.” He says this will lead to better software, and that it’s also better for business. In addition to this post, Adam also wrote a short book. When I say “Sustainable Open Source Community”, I mean the following: A unified body of individuals, scattered throughout a larger society, who work in support of the creation, evolution, use, and extension of free and open source software; while ensuring its longevity through meeting the needs of the present without compromising the ability of the community of the future to meet its own needs.

In an attempt to confirm Kubernetes’ move beyond hype to widespread enterprise adoption, Francesc Campoy and Victor Coisne used source{d} Engine to analyze all the Kubernetes git repositories through SQL queries. Here’s a snapshot of what they learned. At its outset in 2014, the Kubernetes project had 15 programming languages, a number that quickly increased to 35 by the beginning of 2017. Given that Kubernetes came from Google, it’s not surprising to see that Go is by far the dominant language followed by Python, YAML and Markdown. The analysis shows that other languages such as Gradle and Lua have been dropped while some others like Assembly, SQL and Java made a comeback. The full results of the analysis are available upon request via a link shared at the end of the blog post.

Eran Hammer makes the case for hapi as your Node web framework of choice. We’ve been talking about dependencies a lot lately due to recent events. In light of that, think about this: hapi was the first (and still the only) framework without any external code dependencies… I personally (and manually) review every single line of code that goes into hapi (excluding node itself). I review every pull request on every dependency regardless if I am the lead maintainer. That’s quite the selling point! He has a lot of great reasons why hapi is worthy of your consideration. Click through for the hard pitch.

unified –for the uninitiated– is an interface for processing text with syntax trees and transforming between them. Maybe you’ve never heard of it, but you’ve probably relied on it as part of your software infrastructure: [unified] has been OSS for years, but has recently gotten more traction. It’s used in fancy technology such as MDX, Gatsby, and Prettier, and used to build things like Node’s docs, freeCodeCamp, and GitHub’s open source guide. Project’s like unified are crucial to the JavaScript ecosystem, but they’re difficult to fund and support toward sustainability. Hence, the unified collective. Today, we are pleased to announce the creation of the unified collective. It’s an effort to bring together like-minded organisations to collaboratively work on the innovation of content through seamless, interchangeable, and extendible tooling. We build parsers, transformers, and utilities so that others don’t have to worry about syntax. We make it easier for developers to develop. Let’s show these maintainers some 💚 and share this around to those who should be supporting it.

The next big thing for Gitcoin might be coming out of their announcement of Gitcoin Labs. In their words, Gitcoin Labs is “R&amp;D for Busy Developers.” We are excited to expand upon Austin Griffith’s work in the ecosystem, and to formalize it into Gitcoin Labs, which will be a service that provides Research Reports and Toolkits for Busy Developers. Kevin mentioned that they’re “going to continue Austin’s work in the ecosystem” and the first thing listed on their roadmap was “burner wallets”— consider me intrigued.

Tanya leads with this as a disclaimer “This article is for beginners in security or other IT folk, not experts.” — which means this is a 101 level post BUT is a highly important topic. Share as needed. Passwords are awful … software security industry expects us to remember 100+ passwords, that are complex (variations of upper &amp; lowercase, numbers and special characters), that are supposed to be changed every 3 months, with each one being unique. Obviously this is impossible for most people. Tanya goes on to say… If you work in an IT environment, you absolutely must have a password manager. I strongly suggest that anyone who uses a computer regularly and has multiple passwords to remember to get one, even if you don’t consider yourself tech savvy. I fully agree. I also use 1Password and have done so for as long as I can possibly remember.

Hold on to your seat! This is a deep dive on improving time-to-interactive for Netflix.com on the desktop. Addy Osmani writes on the Dev Channel for the Chromium dev team regarding performance tuning of Netflix.com. They were trying to determine if React was truly necessary for the logged-out homepage to function. Even though React’s initial footprint was just 45kB, removing React, several libraries and the corresponding app code from the client-side reduced the total amount of JavaScript by over 200kB, causing an over-50% reduction in Netflix’s time-to-interactivity for the logged-out homepage. There’s more to this story, so dig in. Or, share your comments on their approach to reducing time-to-interactivity and if you might have done things differently.

The Linux Foundation is essentially a foundation for foundations, and the newest member to join the ranks is the GraphQL Foundation. We’ve been tracking news and talking about GraphQL for some time now. Back in 2012 Nick Schrock, Dan Schafer, and Lee Byron got together at Facebook to build the next generation of Facebook’s iOS app powered by a new API for News Feed — what they arrived at was the first version of GraphQL. Lee Byron has this to say about today’s announcement: Today, GraphQL has been a community project longer than it was a Facebook internal project — which calls for its next evolution. As one of GraphQL’s co-creators, I’ve been amazed and proud to see it grow in adoption since its open sourcing. Through the formation of the GraphQL Foundation, I hope to see GraphQL become industry standard by encouraging contributions from a broader group and creating a shared investment in vendor-neutral events, documentation, tools, and support. So who’s involved? Well, GraphQL Foundation is being created in partnership with the Linux Foundation, Facebook, and nearly a dozen other companies. Those “other companies” are likely large scale companies who’ve contributed to or are using GraphQL in production and have a vested interest in its future.

The fight against complexity is analogous to the fight against contentment. Find contentment and you will find yourself at the end of a project. Hint: we will never be fully content. We live in a dynamic world of infinite, and never-ending change. There will always be a critique to offer. Perfection is an illusion. We’ve all worked on projects that never seem to end. Every time you think you’re done, you realize you’re not. There’s “one more thing” you or your client wants to add. Somehow, you get exhausted and your work suffers. Sometimes you simply burn out and move on to something else. Why does this happen? Why do we consistently underestimate how much extra work it is to do “one more thing?”

Tomasz Jakut takes us through a proof-of-concept where he rebuilds Vue’s single file components from the ground up with nothing but browser-native technologies. It takes a few ‘dirty’ hacks to get the job done, but the journey is quite enjoyable and you learn a lot along the way. A great read! 💯

Brad Armstrong lays it all out there about how to transition from an engineer to a manager: There are decades of books and thousands of blogs dedicated to trying to answer these questions, so I‘m not here to pretend that I’ve got the secret to success. But I do know a few ways that I’m pretty sure can guarantee you’ll fail. He takes you through 8 easy steps to failure. I’ll disappoint you now and spoil that step 1 is to keep coding 😱

In response to a recent Twitter poll from Kent C. Dodds, Eric Clemmons shared concerns about how organizational boundaries are impacting where development happens. Kent tweeted… Hey folks who have a decoupled client-server application (no server rendering, server is just an API server). Where is your client code and server code located? (#) Together in one repo? In separate repos? Eric writes in his response on Medium: Software is like Jello: poke it in one place, and another place jiggles. In my experience, a repository should house all of the code necessary to make developing &amp; shipping features relatively frictionless. This isn’t an exact 1:1, but this was a big part of the reason why Segment transitioned back to a monorepo.

In response to the post from Paul Dix on the misunderstandings going on around Redis and the Common Clause license — Matt Klein tweeted: Won’t defend Redis Labs, this is a dead end move, but there needs to be more recognition that the economics of OSS are fundamentally broken. In his post he starts by saying… I want to provide a long form discussion of my two Twitter threads as this topic is nuanced and quite interesting. Note: this post is heavy on opinion and light on facts/references backing up those opinions. Thus, preface everything that follows with “IMO.” Matt goes on to share some history of open source software and his opinions on modern expectations of software being free and open, startups and open source, and who pays…

How do you develop an idea for a talk, determine the conferences to pitch, actually deliver the talk, and whether or not it’s even worth doing? Joshua Comeau writes on Medium: I’m still very much at the beginning of my career. I’m only ~5 years into what will likely be a 40-year career, so I’m only about 1/8th through! That thought is simultaneously liberating and dizzying; it means I don’t have to feel rushed when it comes to making the most of every available opportunity, but it also means I have no clue what’s ahead. Conference-speaking is a worthwhile endeavor, but it’s one heck of a bumpy ride, and not always worth it. I’ll continue to prepare talks — as long as folks still want to hear what I have to say… Joshua ends with an invitation … 👏 I encourage you to give it a shot. Feel free to reach out to me, I’m always happy to give your proposal a quick read :)

If you’re building a serverless application to run at scale, then read this post from Paul Johnston on Medium… Within the community we’ve been debating the best practices for many years, but there are a few that have been relatively accepted for most of that time. Most serverless practitioners who subscribe to these accepted practices work at scale. The promise of serverless plays out mostly at both high scale and bursty workloads rather than at a relatively low level, so a lot of these best practices come from the scale angle e.g. Nordstrom in retail and iRobot in IoT. If you’re not aiming to scale that far, then you can probably get away without following these best practices anyway.

Node.js just hit 1,024,716,169 downloads and is now officially a part of the three comma club. In the last few years, we’ve seen incredible success with Node.js not just within backend development, but with cross-platform and desktop applications. The technology goes beyond simply an application platform but is used for rapid experimentation with corporate data, application modernization, and IoT solutions.

If you’re a maintainer who’s feeling the burden of your open source software, you have a few options to consider according to Richard Littauer — you can… Onboard more maintainers - spread the burden to more of the community Clearly set expectations - explain your software is provided on an “as is” basis Hire a maintenance company - wait, what?! Is that we’ve come to? Are we now hiring code maintenance companies to maintain our open source? I’m actually quite interested in the economies around this, so let this post serve as an open invite to Richard to join me on Founders Talk for a discussion on the state of open source maintenance and his lessons learned building Maintainer Mountaineer.

Abhishek Singh isn’t deaf or mute, but that didn’t stop him from asking the question: If voice is the future of computing interfaces, what about those who cannot hear or speak? This thought led to a super cool project wherein a computer interprets sign language and speaks the results to a nearby Alexa device. Live demo here and code here.

Good news — the next generation of Vue CLI, the standard build toolchain for Vue applications, is here. Evan You writes: Vue CLI 3 is a completely different beast from its previous version. The goal of the rewrite is two-fold: Reduce configuration fatigue of modern frontend tooling, especially when mixing multiple tools together; Incorporate best practices in the toolchain as much as possible so it becomes the default for any Vue app. This means that any Vue CLI 3 project comes with out-of-the-box support most of today’s preferred ways to build and ship applications.

Pia Mancini, CEO of Open Collective: BackYourStack is the first step to help companies discover the dependencies in their stack that are seeking to become sustainable and a way to start subscriptions to them. Each collective can set up different tiers for their subscriptions such us brand visibility, support or in-house training. Just input your GitHub org and BackYourStack will generate a list of supportable projects by analyzing your dependencies. This is a great idea and a good first step toward making it easier for organizations to put their money where their source is. (YMMV as the results are a bit limited (and maybe buggy?) at the moment. Our report is saying we only rely upon 1 open source project, which definitely doesn’t cover it.)

This post from Eric Holmes details how package managers can be used in supply chain attacks — specifically, in this case, a supply chain attack on Homebrew — which is used by hundreds of thousands of people, including “employees at some of the biggest companies in Silicon Valley.” On Jun 31st, I went in with the intention of seeing if I could gain access to Homebrew’s GitHub repositories. About 30 minutes later, I made my first commit to Homebrew/homebrew-core. If I were a malicious actor, I could have made a small, likely unnoticed change to the openssl formulae, placing a backdoor on any machine that installed it. If I can gain access to commit in 30 minutes, what could a nation state with dedicated resources achieve against a team of 17 volunteers?

Dion Almaer (Google) writes on the Ben and Dion Medium publication: A few teams within Google have joined forces inside Chrome to focus on improving the Web ecosystem, focused on those who build experiences, and create on the Web. We want to make high quality experiences easy to build as that will enable more meaningful engagement on the Web for users and developers alike. This is an awesome breakdown of all the components required to deliver meaningful engagements and a roadmap to the future of the web platform.

Ives van Hoorne writes on Medium: Personalizing color schemes is one of the most important things to have in an code editor. CodeSandbox didn’t have any way to personalize colors in the editor since release, but I’m happy to announce that we do now. The best part is that we were able to reuse a big chunk of logic from VSCode directly and also support any VSCode theme natively in CodeSandbox!

I’ve been closely watching CodeSandbox and have been thoroughly impressed with the work Ives van Hoorne and the 75+ contributors have put into this online code editor for … React, Preact, Vue, and more. I’ve been thinking about getting Ives on Founders Talk to talk about the business model behind CodeSandbox. It seems to have this interesting self baked, pay what you want, Patron model to cover the expenses of CodeSandbox. Most of the features are free with limits, and being a “Patron” lifts those limits + extra features, and supports the costs and development efforts.

This epic four part series from the Airbnb engineering blog showcases how React Native was used at Airbnb to enable their teams to move quickly and maintain a great developer experience. However, in the end, they decided to sunset React Native and focus on native — but their journey to that conclusion is well worth a read. Part 4: Sunsetting React Native — Although many teams relied on React Native and had planned on using it for the foreseeable future, we were ultimately unable to meet our original goals. In addition, there were a number of technical and organizational challenges that we were unable to overcome that would have made continuing to invest in React Native a challenge. As a result, moving forward, we are sunsetting React Native at Airbnb and reinvesting all of our efforts back into native. It’s not all bad though. 63% of their engineers would have chosen React Native again given the chance and 74% would consider React Native for a new project. Gabriel went on to say: React Native is progressing faster than ever. There have been over 2,500 commits in the last year and Facebook just announced that they are addressing some of the technical challenges we faced head-on. Even if we will no longer be investing in React Native, we’re excited to continue following its developments. For a different perspective read Should we use React Native? — a follow-up post to this four part series.