Changelog

Repl.it is a startup I've never heard of but it really seems I should have. They just raised $4.5M to build out a "microcomputer to the cloud's mainframe." What is that even? When they started they didn't know either... We started Repl.it as a side project with the straightforward goal of making it easy to get a REPL for your favorite language when you need one ... however, our users wanted more. They misused our system for things it wasn't meant for: they hacked games into our dumb web terminal, they made networked applications despite not having explicit support for it, and they kept asking for more. It's crazy how big ideas start so small and simple. Now they have the backing of one of the most sought after venture capital firms to continue on their quest. The seed round was led by Andreessen Horowitz, with Marc Andreessen and Andrew Chen championing the deal. Cloud-computing is one of the most significant paradigm shifts in our industry, yet it remains command-able only by relatively few professionals. It's similar to when, prior to microcomputers, only big corporations and universities had mainframes. We want Repl.it to be the microcomputer to the cloud's mainframe.

But…why? We’ve loved building Upcase, both as a business and as a way to share what we’ve learned with the community. But while we’d love to keep investing in Upcase and producing tons of new content, we’ve been moving in a different direction—back to our roots, in fact, as we focus on our core consulting business. So what to do with this learning platform we’ve poured our hearts and souls into? We ultimately decided the best option was to open Upcase up to the world and share all of the content, no subscription needed. As they say, if you truly love something, set it free. Focus is SOOO crucial and sometimes is overlooked for too long. Been there. Glad to see the wisdom of focus here being shared (freely) from Thoughtbot. We've always been huge fans of their leadership in the community.

Little bits of appreciation can make big differences in maintainers' lives. Here's one way you can show appreciation that will take less than five minutes out of your day and just might make someone else's. 🙌

I think the consensus agrees that sustaining open source software takes more than just money. And yet money often remains a crucial part of a larger need for open source to sustain AND thrive. So, if that's the case...how should you use funding for your open source project? Brenna Heaps writes on the Tidelift blog: We’ve been speaking with a lot of open source maintainers about how to get paid and what that might mean for their project, and the same question keeps popping up: What do I do with the money? The tldr? Fund the project, community engagement, and pay it forward... But, it's a short read and worth it — so go read this and then share it with your fellow maintainers.

Have you seen this spreadsheet of open source software companies from Joseph Jacks? The criteria to be added to the sheet is; the company generates $100M+ revenue (recurring or not) OR generate the equivalent of $25M of revenue per quarter. These companies have found a way to build a very large business around one or many open source software projects. Anyone on this index surprise you?

Just in time for #Hacktoberfest! The Non-Code Contributor’s Guide aims to make it easy for anyone to contribute to the Kubernetes project in a way that makes sense for them. This can be in many forms, technical and non-technical, based on the person’s knowledge of the project and their available time. Most individuals are not developers, and most of the world’s developers are not paid to fully work on open source projects. Based on this we have started an ever-growing list of possible ways to contribute to the Kubernetes project in a Non-Code way!

If you want to see what the landscape is of companies who are using Go, spread the word and encourage folks to participate in the 2018 Go company questionnaire. On the Go blog: Please help by participating in a 7-minute company questionnaire. Who? If you are in a position to share details like “company name,” “if your company is hiring Go developers,” and “reasons your team or company adopted Go” then please help us by taking this company questionnaire. We only need one response per company (or per department for larger companies). If you aren’t the right person, please forward this onto the right person at your company.

If Hacktoberfest has swag on your mind, then check out devSwag: a site that details all the different swag opportunities out there. (Having déjà vu? I logged the repo in February. Now it has a shiny frontend. Also it's cool, so get off my back!)

As with any research Nadia Eghbal shares, this is a deep dive into understanding the user support systems present in today's open source. It's very detailed, highly researched, and more importantly it's actionable. Here's a sample of Nadia's closing remarks: I barely scratched the surface on user support systems: there’s a gold mine of data waiting to be played with. I’d love to see more research on how support communities form and maintain themselves (particularly Stack Overflow, mailing lists, forums, and synchronous chat). Why do some have only one or two answerers, while others have many? Does the growth of these communities mirror that of the code contributor community? Implicitly, a deeper understanding of support communities would help validate the growth model and hub-and-spokes model presented above.

Almost eight years ago, Suz Hinton made one of the biggest decisions of her life: move away from her home in Melbourne, Australia and move to the United States. After amicably breaking up with her boyfriend, another decision lied ahead: would she stay? Suz talks to me about culture shock, the hoops she had to jump through to get her visa, her parents, and dealing with burnout.

Yup, it's true..."estimating project costs is hard." I thoroughly enjoyed the tongue in cheek logic shared by Dave Rupert in this post. ...let’s say your app has a logged-in or logged-out state, well, that’s at least 2 if-statements. Starting price: $20,000. Never before has it been this easy to price and scope out complex stateful apps! The cost of complexity in software is real and this is a very practical post to share with would be customers of your software team. This applies to freelancers, consultants, and even teams inside larger orgs. We all have to account for our time, and that means accounting for the money being spent along the way.

The key is to remain nimble, small (relatively), and indie. Podcasting started as hobbyist/indie media and that's where the secret sauce remains. Panoply, the podcasting unit set up by Slate magazine, recently laid off most of its staff and says it will now become just a distributor of podcasts rather than the creator of them... BuzzFeed announced on Wednesday it was also laying off staff at its podcasting unit... Audible, the audio arm of retail giant Amazon, also laid off some staff from its podcasting unit recently... Our bubble isn't bursting, it's growing. We're not going anywhere.

Nikita Prokopov has been programming for 15 years and has become quite frustrated with the industry’s lack of care for efficiency, simplicity, and excellence in software — to the point of depression. Only in software, it’s fine if a program runs at 1% or even 0.01% of the possible performance. Everybody just seems to be ok with it. Nikita cites some examples: ...our portable computers are thousands of times more powerful than the ones that brought man to the moon. Yet every other webpage(s) struggles to maintain a smooth 60fps scroll on the latest top-of-the-line MacBook Pro. I can comfortably play games and watch 4K videos but not scroll web pages? How is it ok? Windows 10 takes 30 minutes to update. What could it possibly be doing for that long? That much time is enough to fully format my SSD drive, download a fresh build and install it like 5 times in a row. We put virtual machines inside Linux, and then we put Docker inside virtual machines, simply because nobody was able to clean up the mess that most programs, languages, and their environment produce. We cover shit with blankets just not to deal with it. “Single binary” is still a HUGE selling point for Go, for example. No mess == success. Do you share in Nikita's position? Sure, be frustrated with performance (cause we all want, "go faster!"), but do you agree with his points beyond that? If so, read this and consider supporting him on Patreon.

I did not see this coming. Linus Torvalds, writing to the Linux Kernel mailing list: I need to change some of my behavior, and I want to apologize to the people that my personal behavior hurt and possibly drove away from kernel development entirely. I am going to take time off and get some assistance on how to understand people’s emotions and respond appropriately. Introspection is hard, especially when you don't like what you see after staring yourself in the mirror. Cheers to him for owning up to mistreating others and attempting to change. Here's hoping he follows through. 🤞

You should plan 10 minutes and read this story from Emily Freeman. Here are some highlights I enjoyed hearing her speak about. On growing up and being poor... Because I was poor, I was nothing. On why she's in tech... Life, in many ways, is a write-only database. On being a house-wife... I felt like a failure. I was clever, I had worked hard and yet there I was again — worth nothing. On being a mom... Giving birth was the first time I felt truly powerful. On learning... Hard work beats talent when talent doesn't work hard.

I like how this post tries to answer questions on why remote companies need to openly acknowledge the mental health challenges of remote work. Amir Salihefendic writes on Ambition & Balance from Doist: Isolation, anxiety, and depression in the remote workplace and what we’re doing about it... In contrast to a traditional office, remote work puts much more focus on output — what did you get done — rather than input — how many hours did you spend doing it. There's a sense of personal responsibility to get "enough" done that can lead people to keep themselves working long past the point of optimal productivity.

This is the battle cry that started the Open Container Initiative. But in reality, are/was multi-cloud and vendor lock-in true concerns for software teams? Tyler Treat writes on his personal blog: We want to be cloud-agnostic. We need to avoid vendor lock-in. We want to be able to shift workloads seamlessly between cloud providers. Let me say it again: multi-cloud is a trap. Outside of appeasing a few major retailers who might not be too keen on stuff running in Amazon data centers, I can think of few reasons why multi-cloud should be a priority for organizations of any scale.

I talked with Bryan Helmig about this on Founders Talk #55. He's the co-founder and CTO of a "remote only" company, so that means engineering as well. Yes, you read that right — remote only. Maria Gutierrez (VP of Engineering at FreeAgent), writes on the GitPrime blog: When your company’s headquarters are outside of one of the major tech hubs, you’ll likely hit a point where you realize you simply cannot hire enough developers to work in the main office. A lot of companies need to start considering distributed candidates in order to build the quality crews they need. And if you want those distributed engineers to be successful members of your team for a long time, you’ll need to follow certain best practices right from the get-go. For some, going distributed is a choice. For others, it's a necessity to survive. Which side of the line does your organization stand on this subject?

We've been tracking the community's concerns and feedback about Commons Clause fairly well. In this post, Stephen O'Grady basically writes a book on the subject and the impact of this controversial software license. ...the Commons Clause turns open source software into non-open source software, according to the industry’s accepted definition of that term. Specifically it says that the terms of the original open source license notwithstanding, you may not sell software “whose value derives, entirely or substantially, from the functionality of the Software.” ...there are several logical questions to explore regarding the Commons Clause. What are the drivers behind it? What does it mean for the companies that employ it and the wider industry? And lastly, is it a good idea? Set aside 20 minutes and read this if you care about how this license is becoming popular among those (Redis as of recent) who are protecting their right to generate revenue from their open source code, while removing that ability for everyone else.

Justin Jackson shared some personal insights and lessons learned in this post — and quoted Des Traynor, co-founder of Intercom saying: A founder is spending 60 months of their best years in their startup (instead of their career). That is a substantial upfront investment; it’s like a seed round, but instead of money, it’s your life. And the bootstrappers dilemma... Can I get this to scale, while paying my bills, without burning out? This is why many founders end up raising venture capital.

Will Gaybrick, CFO at Stripe, wrote a short piece for CNBC last week that hit my radar. Will shares insights about how companies are worrying more about access to software developers than they are to capital constraints. ...a majority of companies say lack of access to software developers is a bigger threat to success than lack of access to capital. A recent study from Stripe and Harris Poll found that 61% of C-suite executives believe access to developer talent is a threat to the success of their business. Perhaps more surprisingly — as we mark a decade after the financial crisis — this threat was even ranked above capital constraints. Will goes on to say that given this revelation, companies are still misusing their most important resource. Too many developers are tied up in projects designed to prop up legacy systems and bad software, at a cost of $300 billion a year — $85 billion just dealing with bad code. Correctly deployed, the expertise of software developers could add $3 trillion to global GDP over the next decade.

This post on Harvard Business School's Working Knowledge from Kristen Senz gives us insights into the process of learning by contributing to open source. This comes from a recent study conducted by Frank Nagle, "Learning by Contributing: Gaining Competitive Advantage Through Contribution to Crowdsourced Public Goods." Kristen quotes Frank saying: What this study shines a light on is that the companies that contribute and give back learn how to better use the open source software in their own environment. A lot of the research I do looks at the question, can the company be better off but also leave the world better off? While this study is focused on large organizations, in future research Nagle plans to study the effects of learning by contributing on smaller firms and startups.

Mahdi Yusuf worked a startup in his twenties and wasn't worried too much about his health. When he quit that job, he decided to take better care of himself and lost fifty pounds. Now, he's the CTO of Gyroscope, a startup that aims to be the operating system for the human body, but ever since joining, has gained weight back. Mahdi talks to me about how Gyroscope is trying to help people understand their bodies better, growing up with a love for computers, and trying to be healthy with a busy life.

"There’s always more work to do" is a common excuse for why programmers need to work long hours. But a little bit of planning and prioritization will do far more to help you ship your product on time—with the features that really matter. 💯 times yes! Everything Itamar is saying in this post aligns with my experience.

On the Chromium Blog, Paul Kinlan shared a look back to the beginning of Chrome in 2008, the early days of the web, on through to today and the future of the "capable web." 2008-2014 — In just seven years, the web changed drastically. Browsers got significantly faster and more capable, letting developers build richer experiences on the desktop. Users started to consume even more content on mobile, meaning we all had to rethink how our experiences would work across devices and form-factors, even when the user had no connectivity. If you're looking for some perspective on how far we've come with the web and the impact of iteration — you should check this out. BTW — Chrome turned 10, here's what's new.