devopsy.kinsta.cloud

Author: Malia Powers

  • The State of the Kotlin Programming Language in 2018

    The State of the Kotlin Programming Language in 2018

    Pusher, the communications and collaboration API provider, recently released the findings of its “State of Kotlin 2018” research report. Over the past 24 months, adoption and use of the Kotlin programming language among developers has seen tremendous growth. Pusher has seen this growth firsthand, with more developers using Kotlin while building applications with the company’s products.

    Earlier this year, Pusher surveyed more than 2,500 developers to get a better understanding of the ecosystem, specifically around usage, features and demographics.

    Key report findings:

    Kotlin is used both in work and personal projects, as confirmed by 60 percent of respondents. Kotlin is even more prominent in side projects, as they tend to be smaller, easier to convert and more experimental.

    Android is hugely popular across the board, used by professional developers and students alike. However, when it comes to backend applications, Kotlin’s users tend to be more experienced developers.

    Most Kotlin developers come from a Java background, or also work with Java. More than 87 percent of respondents have migrated existing Java code to Kotlin. However, more than a quarter of respondents who migrated Java to Kotlin needed to revert back due to both technical and organizational reasons. Tools that use reflection or generate code were mentioned most often as technical reasons to revert to Java.

    Null safety is the favorite feature for 80 percent of respondents, whereas co-routines and multi-platform support are the least important.

    The report concluded that Kotlin is overwhelmingly popular in the Android circles. This raises the question, Will Kotlin break into communities outside Android?

    “We expect to see new generations of developers taking their first steps into programming with Kotlin,” said Pusher Developer Evangelist Zan Markan in an email. “It’s a modern, versatile, cross-platform language that can cross between OO, functional, scripting, and declarative paradigms with ease. This could mean that Kotlin will affect the wider programming language landscape by becoming a benchmark for what a programming language should be able to do.”

    Read the full report here.

    — Malia Powers

  • Developer Trend Chat: Microservices, Node.js, Kubernetes

    Developer Trend Chat: Microservices, Node.js, Kubernetes

    The role of software developers has never been more important. Developers touch almost every corner of our lives, from health care and retail to education. It’s an extremely rewarding career—so much so that software development is now ranked the Best Job in the United States.

    The nature of software development demands that developers be fast-moving. New tools and technologies are providing developers the ability to adopt new skills, work faster and reshape how they work. In this Q&A, CEO of LunchBadger Al Tsang discusses trends in software development.

    Q: Data distribution is still a difficult and complex aspect of breaking down a monolithic architecture. How can enterprise architects avoid this or what is a good strategy for dealing with this snag when they will encounter it eventually?

    Al Tsang, CEO, LunchBadger

    Al: The data’s location, its dependencies and varying levels of data normalization, make breaking down monolithic architectures a challenge. Microservices initiatives can address these challenges by constructing a comprehensive data model. In the past, we had UML tools such as ERD diagrams. These tools are not as common anymore, however, the practice of what they represent still brings value in understanding what data your applications currently use, what’s obsolete, what’s redundant, and what’s related with dependencies.

    Microservices and the tie in to data should be atomic enough so that the data that it operates against is wholly owned and contained. This is easier said than done. There are often dividing lines that can be carved out that mirror the business functionality itself—whether that be by domain, by entity or by business process. In some cases, it’s a combination of all the above.

    Q: Why do you think serverless and FaaS (functions as a service) is growing at such a rapid rate and what specific pain points do serverless platforms (such as LunchBadger) address?

    Al: I believe serverless and FaaS is growing rapidly for a number of key reasons:

    (1) Infrastructure and application platform [are] becoming highly commoditized where a developer can pass the buck to have operational concerns placed on a third party.

    (2) The pressure and need to innovate requires an intense focus on working on your core IP as a differentiator while everything else in your code is a supporting role and oftentimes something that is completely boilerplate (e.g. think persistence to a database or NoSQL data source).

    (3) The movement and drive behind attaining microservices means getting down to bite-sized pieces of functionality means whittling down your logic do distinct reusable compartmentalized pieces of code—i.e., functions—and “serverless” fits this paradigm nicely by adding that you should only concern yourself with the piece of code on an event driven basis.

    (4) New and old companies alike have amassed a zoo of technological languages and platforms where skill sets and resources can be more efficiently utilized if you have a common runtime paradigm and can write your business functionality that supports polyglot usage.

    Q: According to a survey in 2017, Node.js was primarily used as back-end infrastructure for APIs. One of the main strengths of Node.js is that you can use the same language on the entire stack. How do you think Express.js and other minimal frameworks like it contribute to its popularity and why?

    Al: One reason Node.js has had rapid and wide adoption is because it is a massive equalizer. Node.js developers don’t need to have ninja-level domain expertise in high scalability, multi-concurrent connectivity, threads or similar complex topics just to be able to build a scalable app.

    Node.js takes advantage of a language that had the principles of high scalability built inside, namely evented asynchronous programming. Node.js also has an advantage as it’s the language that any web developer would have exposure to thanks to the ubiquity of browsers. Moving the same language and its strengths to the server was a huge win for folks to truly become “full stack.”

    Express.js has further contributed to Node.js’ success by adding the basics of web utility to Node.js. Every web application needs a web/app server that exposes URLs as routes. All servers have consumers making requests and processing those requests can often time be chained from one piece of logic to another. Express took the learnings from Ruby and Sinatra and brought them to Node.js.  You scaffolded a template project and filled in the blanks, as needed and where needed. It’s highly productive because the starting point for many web applications follow this same model.

    Express Gateway galvanizes the success of Express.js—its rich ecosystem of middleware modules and ubiquitous understanding among many developers and make its cloud ready and cloud native by separating out the configuration, metadata and conditionality to be declarative and dynamic. By doing this, Express Gateway runs in containers and orchestrators in a distributed way without worrying about being coupled at any given tier of the application.

    Q: Node.js and Kubernetes is a popular combination, but many developers and companies are confused on where to start or how it will affect their tech stack. Can you explain the top roadblocks you’re seeing and how companies can overcome them?

    Al: Roadblock #1: Where should you extend Kubernetes or where should you extend your Node.js application?

    I think this entangled mess is actually not as bad as it’s often perceived it to be. If it’s a core part of your application and you’ve written it in Node.js, then it should be completely independent of where and how you run it. Before the wide adoption of containers, many Node.js applications were being run in process managers. Many are still running in process managers within a container. In short, if it’s a core piece of your application logic, it should be in Node.js. If it concerns how and where you run the application logic, now you’re looking at configuration or extensions within Kubernetes.

    Roadblock #2: Should I use Node.js to orchestrate my application or leave that to Kubernetes and why?

    Orchestration means wiring up your application at the infrastructure level. Leave this piece to Kubernetes, which can expose and manage your microservices truly as “services.” When you’re writing Node.js applications, you shouldn’t have to worry about the “I/O” of how different Node.js processes interoperate. The whole premise behind microservices is that there are distinct lines drawn where processes must interoperate without assuming the other process may even be up and running.

    Roadblock #3: What if I have a component that has both infrastructure AND application concerns?

    This is a tough one where a lot of companies, large and small, are feeling pain. Kubernetes has a notion of an ingress controller, which is really nothing more than routing and exposure of requests externally to a resource designated internally to handle it somewhere with the Kubernetes cluster. This raises the question: Should you put application-level concerns on that ingress controller?

    I believe in a clean separation of concerns, even if that means having some runtime overhead. If your business requirements don’t require super low latency or other cases that drive you to blur the lines between infrastructure and application, then it’s much easier to maintain if there is a clean separation. This is really no different than slicing and dicing your application into smaller microservices. It’s just executed in your stack at a horizontal rather than vertical level. Build an ingress controller that is only concerned about routing to the right resource. Then build a separate API gateway that sits in front of the microservice(s) to take care of application-level concerns.

    — Malia Powers

  • SlashData Report: Developers Influence Tool Selection

    SlashData Report: Developers Influence Tool Selection

    SlashData has just released its “State of The Developer Nation Report for Q3 2017.” Here at Heavybit, a program that helps developer and infrastructure startups take their product to market, we look forward to SlashData’s reports that allow us to keep up to date on the shifts in the developer landscape.

    In 2013, Stephen O’Grady published, “The New Kingmakers: How Developers Conquered the World,” sending shockwaves through the ecosystem about just how important individual developers are when it comes to making technology purchasing decisions in companies.

    SlashData provides compelling data that backs up O’Grady’s book, showing how influential developers are within an organization and how targeting individual developers at organizations is a viable strategy for enterprise sales. The research only includes professional developers in organizations who buy tools or components and exclude lone wolves—developers who work on their own and where a purchase decision is purely personal.

    Key report highlights Include:

    More than 87 percent of developers with a leadership function, no matter how small, as well as two-thirds of front-line coders, are somehow involved in purchasing decisions.

    For developers that are not in a top leadership position, between half and two-thirds are in a position to make recommendations or influence decisions. In particular team leaders (i.e., senior developers) are big influencers (68 percent).

    Thirty-nine percent of developers acquire tools for their personal use.

    The ability for developers to pick and use their own tools shows that they have the power to make their own decisions and a budget to spend (even if it is small). It’s through this personal use that a tool can get introduced to an organization and is the first step in evangelizing the tool to the greater developer community.

    Up to a third of mid-level developer leaders (team leaders and product managers) hold the pen when writing specs for tools (32 percent and 31 percent, respectively), or even get the final word on which tool to adopt (30 percent and 27 percent).

    This fact is even more proof that individual developers at all levels matter. “Even when in a majority of cases developers still need management to sign off on purchases, the days are over when an inadequate tool could be pushed from the top down because it appeared attractive to CFO’s or top brass,” the report states.

    Developer influence, when it comes to making technology decisions in companies, continues to grow. To harness this shift, companies need to focus on creating tools that developers will come to love and evangelize on your behalf within their organization.  

    — Malia Powers

  • JAMstack Radio Podcast: Benefits of an API-First CMS

    JAMstack Radio Podcast: Benefits of an API-First CMS

    Welcome to JAMstack Radio, a podcast that discusses the JAMstack, a new way to build fast and secure apps or websites. JAMstack Radio is hosted by Brian Douglas, Developer & Advocate at Netlify. In this episode, Brian is joined by Stefan Judis and Rouven Wessling to discuss Contentful, a developer friendly API-first CMS.

    They explain the benefits of decoupling your website’s content from its presentation, including better cross-platform support. With Contentful, you are completely free to write your site in the language you want, while the service takes care of the CMS backend, storing and versioning your data, and backing everything up.

    This podcast is brought to you by Heavybit, a program that helps developer product companies take their product to market.

    [soundcloud url=”https://api.soundcloud.com/tracks/329732086″ params=”color=#ff5500&auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=false” width=”100%” height=”175″ iframe=”true” /]

    Brian Douglas: So, welcome to another installment of JAMstack Radio. On the line, we’ve got Stefan Judis.

    Stefan Judis: Yeah, I am Stefan, I am a developer evangelist at Contentful, based in Berlin. And I’m really excited to be here.

    Brian: Cool, and then we also have Rouven Wessling.

    Rouven Wessling: That’s almost correct. Yeah, I’m also a developer evangelist, but I’m also an ecosystem developer, so I don’t only just get to talk about Contentful. I actually build part of the product, mainly unveiling the PHP SDK. I also have my fingers in some of the other ecosystem projects we do—stereo saturators, family integrations.

    Brian: Cool. The audience definitely knows what Contentful is, because you guys have come up in conversation at least three times in previous episodes. But for those who maybe just found this randomly, do you want to explain what Contentful is?

    Stefan: I can take it. So Contentful is a headless CMS. So what this mean is that we offer an API, where you can retrieve your content, and on the other hand, we offer a web app where editors can edit their content. That’s basically a headless CMS, and we’re API first.

    Brian: Yeah, we’re big fans. At JAMstack, we love separating concerns. And the reason why Contentful keeps coming up is because we keep talking about front end solutions, to talk to APIs, and since you guys are API first, you fit right in the middle of the jam. It’s like a match made in heaven, really, for anybody who wants to have something super fast, but not worrying about collecting and maintaining their own infrastructure.

    Rouven: There was this amazing quote from a user we had just recently.

    Contentful is a CMS where the user gets the full CMS they want, but the developer doesn’t have to deal with us at all. 

    It’s just an API, it’s like any other API you would ever use, it’s just the same. You don’t have to think like a CMS, like it worked just like a Drupal, like a Adobe experience manager of all the gruesome things out there. It’s just an API. And that’s really what we want to be, we just want to be the API for your content.

    Brian: Cool. Yeah, I really like the approach too, because I literally have recently got into WordPress, for some things we need to test for work, and I’ve never done WordPress development before.

    Rouven: How was it?

    Brian: Not very good. Just the getting up and running, and getting you environment set up to host your own WordPress setup, it’s kind of tedious. Especially if you just want to manage a small amount of content to test out a small side project. It doesn’t seem realistic to reach for WordPress right out of the gate, which is why I love the solution of Contentful. You call it a CMS, so do you have an admin interface where users can actually interface and add data too?

    Stefan: Yeah, so we’ve got the Contentful app. This is the place where content managers or editors set up their content model first, so it’s completely flexible, you’re adding there, define what your content types are, you then connect items. And then you’ve got the actual editor interface, and this is where then the data editing happens.

    Brian: Okay, cool. And then, the data itself, we’re talking JSON, I assume?

    Stefan: We’re talking JSON.

    Brian: Yeah, which is very cool. So my last job, we built a growth hacking project to get people to find our site eventually. And because it was a growth hacking project, I worked really closely with the marketing team. So what I did is I built a CMS with Google Sheets. I built a quick scraper for Google Drive, to actually take that data and add it to a Postgres database to then serve to my front-rend react app.

    So I spent about, maybe 1 1/2 weeks researching it, and I spent about another a few days to actually to implement it, and I walked away feeling very proud of myself. And the very first day I showed it to everybody in the team as like, “hey this is what I built, now the marketing team can go into the Google Drive and add data and it shows up on our website that I built for them, this works perfectly.”

    And the first question that came up with the engineering team was, Why didn’t you use Contentful? And I was like, “Content-who? I’ve never heard of these guys, I don’t understand.” And then as soon as I got back to my desk after feeling very defeated, I actually Slacked and was, “Ah yeah, if you told me about this like two weeks ago, I would have used it, but I already built this, and I don’t want to do any more work, so I’m like kind of upset.”

    Rouven: But what you built sounds amazing, because you got the core thing right. You decoupled your presentation.

    Brian: Yeah.

    Rouven: The react app is about how you displayed the content from the part where you store the content. So you can switch out either end without having to redo the entire project. Now if you worked with WordPress, and you have a WordPress theme, and you have all the content in a WordPress database, you’re stuck, it’s never going to get out of there, unless you put in a lot of manual work.

    If you want to add a mobile app, or Alexa Skill, or whatever else you want to build for your content, and you want to reuse the same content, good luck in WordPress. 

    That’s not going to fly. I mean, it’s possible, don’t get me wrong, it certainly is possible, but it’s not going to be fun, by any means. And just grasping that and actually doing that right, is where most people who build websites today actually fail. Because they are thinking in a web-centered world, and everything they design is made for the web, and for nothing else.

    Brian: That’s very true.

    Stefan: You need a mental shift though. With WordPress, you have the holy WYSIWYG editor, where people start messing around with all the content, but when you want to go cross-platform, then you’re stuck. When you have markup in your text blocks, there is no way getting out then again.

    Brian: Yeah, and especially if you have to, like you mention, handle multiple platforms, and now we have the Amazon Echo which has no actual visual interface, like it’s just reading data from strings. It makes a lot of sense to decouple your markup from your API so that way you can present that nicely.

    Stefan: And also you have much more choice of not just reusing content, but also how you have your editors think about content. Like my absolutely favorite feature of Contentful is the images API, where you can seriously resize and mitigate images on the server. And how many people implement CMSs with structured fields where you have to upload the same picture five times at different sizes for different viewport sizes.

    The editors hate it and the developers hate it but people still do it. But the much smarter solution is to resize images on the server and cache them in the CDN.

    And I’ve even seen people with Contentful implemented that way, because they are so stuck in the mindset that they have multiple image fields for different sizes, while it’s much much easier to just use the power of the platform, and just resize images on the server and be done with it.

    And to think more in abstract terms about your content, independently of the platform where you show it, is a mind shift people just have to make. And once you’re there, a whole world opens up to you of just reusing the content you have. The most amazing thing companies usually produce, is content, like this podcast, it’s content, and it’s actually really good content, cause people learn from it, people study it. Bringing the content to multiple places to be more accessible to people, is an incredibly important thing to do just to get it out there. And making that mind shift is so important.

    Brian: Reuven, at the top of the show you mentioned that you also, not only that you’re an evangelist, but you also implement some SDKs. Contentful, do they have SDKs for multiple platforms as you mentioned?

    Rouven: Yes we do. So I have the probably unpopular with this audience job of maintaining the PHP SDK. So if you’re coming from WordPress, I’m the guy who’s going to get you on Contentful. But we do have SDKs for obviously JavaScript, for all the mobile platforms, Swift, Objective C, Java for Android, Python, Ruby.

    All the common languages used on the web on mobile, we have covered. I think it’s right now eight in total, so whatever platform you’re on, we can probably get you hooked up on SDK so you don’t have to actually write raw API interactions ever.

    Brian: Cool. Yeah, that’s like the best thing about, one, separating your concerns, separating your markup, but also being able to use like, these SDKs for example, if I wanted to create a react app or ingar app, or something fancy. If I can just drop in a quick connection to that API and reuse that same data, that kind of unlocks a real world, so it makes sense how Contentful really is serving the space really nicely.

    Stefan: Yeah, you just have to drop in the JavaScript SDK and then you’re already flying.

    Brian: Yeah. Apologies if I broadside you guys with this question, but do you guys have search integrated in there as well? Like if I had a long list of content that’s being implemented, is there an easy way to pick certain items for certain situations?

    Rouven: We do have a full text search. It’s not Algolia-quality search, so if you want a really powerful full text search, use Algolia with us, it has actually quite a nice integration and there are some open-source projects to do it.

    Brian: Oh nice.

    Rouven: But if you have just basic search needs, we actually run off Postgres, we have I think like a dozen different search operators. Including like geographic searchers, range searchers, bounding box GU search, very fancy, but the most important thing is full text search across all the content users have to get you to the result. Whatever humans actually type in, not just computers do.

    But the powerful thing about Contentful is, we really just want to do one thing very well, and that is content and managing your content, and if you want another thing to do with your content, somebody else may do it better than us. So if you want really really good search for your website, or your app, or your Alexa Skill, or whatever else, use Algolia.

    Brian: Yeah.

    Rouven: Push your content from Contentful to Algolia. If you want AB test, use Optimizely.

    We want to really get away from the monolithic view of “your CMS does everything and everything lives in your CMS.

    But you use the most powerful, most advanced tool for whatever you want to do, and you just store your content with Contentful, and you integrate with all these tools. So you’re not locked into using whatever happens to integrate with Contentful, you just use whatever is the coolest thing right now.

    Brian: I’m glad you mentioned Algolia, because an episode that hasn’t been out yet, they’re actually on, I believe it’s the last episode, so the one before this will be about Algolia, which is great because all they need is JSON, which makes sense, if you guys have integration to pass your Contentful data straight to Algolia. It’s amazing how many APIs here work for each situation, and how perfect the JAMstack works.

    Stefan: You just have to connect pieces, right?

    Brian: Yeah.

    Stefan: We’re really reaching that state, and that’s quite nice.

    Rouven: It’s an amazing world we live in right now. I’ve been, the past couple of months, to a couple of API conferences. It sounds absurd on the surface, it kind of is to be honest, but like just discovering how many APIs are out there to do all the things, it’s a great world we live in.

    Brian: Yeah. Do you mind sharing what API conferences were you just at?

    Rouven: The last one I was at was actually APIdays Australia, in Sydney.

    Brian: Okay.

    Rouven: Before that it was APIdays Paris, Nordic APIs. So around the world, mostly US, Europe and Australia, there is a conference where it’s API implementers usually come together, exchanging best practices about how to best implement an API and document an API and get developers started with an API. How to make the first API call as easy as possible. This is incredibly important for us, because

    Entering your content through the web app, editors know how to do that.But integrating content through an API entry each occasion is something new for most developers. 

    So we just exchange knowledge there about actually getting started. And it’s amazing to see how many companies now open up their data. I met somebody from Lufthansa. Lufthansa, the big airline, now has an API, where you can carry flight information. I think it’s the first big airline to do it, and it’s amazing that these old like 19th century companies are starting to open up their own data for the world to use, for us developers to use.

    Stefan: Yeah, this is exactly what we wanted right? You mentioned the react use case. For example, I’m storing the information for my personal website also on Contentful. And just because I can and I have an API available, I built myself a little app that schedules all my travels. Because I do a little traveling, these are the events, and that wouldn’t be possible without an API, that’s really sweet.

    Brian: Yeah, it’s super nice. I really like the catering to, I don’t know if you want to call them non-technical users as well, but having a marketing team or an editing team that’s pushing out content while the rest of the app’s actually being built. That was one of the big use cases why I opted for building my own API-first CMS with Google Drive. It was because we were building a proof-of-concept for a project, and at the time we needed a lot of content for it.

    So we couldn’t wait for the app to be built while we were collecting content, so we started adding content to the Google Drive to eventually port it over manually. So I was like “hold on, we have the content already, let’s not double work,” so I ended up doing way too much work to get this thing to work. But if I’d used Contentful, we would have had all the content being populated as the app was being built, and then click a button and then it populates all our data. And I liked your use case for traveling too as well.

    Stefan: It works pretty well for me.

    Brian: Yeah. I love providing data. Every other episode I talk about this app, but I built an app to tell me whenever there’s a home baseball game. I don’t know if you guys have baseball in Germany.

    Rouven: Rarely. It’s not really, rumor is there is a team someplace in Germany, one, just one.

    Brian: One team? At least you’re keeping up with everybody else in the Western ecosphere. Yeah, so for the listeners who don’t know what baseball is, it’s basically where grown men stand around and watch one tiny white ball get thrown around for hours.

    Rouven: That’s so how it feels to me.

    Brian: Yeah, there’s beer involved, and hot dogs.

    Stefan: I went to a single game in my life, I was bored to death.

    Brian: Well, if you guys ever make it out here to the SF, I’ll bring you guys to a baseball game, and we’ll get drunk.

    Rouven: I think we have a deal here.

    Brian: All right.

    Stefan: I’m up for the drunk part, I’m not sure if baseball’s necessary for that.

    Brian: All right, well we’ll go next to the stadium to a bar and listen to it.

    Stefan: That’s a deal.

    Brian: So the app I built basically is just scraping ESPN data and making sure I know whenever there’s a home game for the Giants, and it just will ping me and tell me whenever not to go to the city, and avoid any sort of baseball traffic. So it sounds like I could use Contentful for that, just to collect all my data for me, and then be able to ping me with the notification, just a serverless function.

    Stefan: These kind of stories make me so excited, that we’re kind of developers and we’re able to build these kind of things. Sometimes I’m like “holy shit, this is amazing.”

    Brian: Yeah we’re at a really awesome time to be a developer, because a lot of the, not all the problems have been solved, but a lot of the hard problems have actually been solved for us, so we can just use our knowledge and collect all these APIs and collect all these use cases.

    Rouven: Just an API callable year. Google and Amazon too have been opening so many amazing APIs for natural language processing, AI context-based language meaning, image recognition, video recognition just opened by Google. I mean, it’s not open source, open source would be nicer, but just an API call away, and maybe three cents charge per API call is a breadth of knowledge, that at least I am incapable of developing by myself.

    Like I can’t build a natural language processor, that’s definitely not my level of skills. But I can just access one that’s really really good by making an API call. And that ability, as a developer, is amazing.

    Brian: Yeah. Even things like VR, and we talked a little bit about the Amazon Echo as well. People have already solved those problems, and you just drop in a JavaScript library to do VR on your phone, or language processing from your phone or other third-party device. It’s amazing and also scary. Because you know, everything’s super easy and attainable to do, so the possibilities are almost endless for the good and bad.

    Stefan: There’s always stuff to go, right, always.

    Brian: Cool. And sorry, Stefan, do you also do code at all, at Contentful?

    Stefan: I was developing many front-end stuff in JavaScript before and now anchor the developer relations team, which means I’m responsible for blogging and hanging around and chatting with people. Coding these days is side projects and try-outs.

    Brian: Okay, cool. Well I’m sure Contentful gives you access to nice stuff for your account so you can continue to build your scheduling applications.

    Stefan: I’m building all this stuff with Contentful now, I need an API, okay let’s do that.

    Brian: Yeah yeah. I feel the same way Netlify, like I’ve had three sites before I was a Netlify employee, and now I have like 50, just because I can. I don’t need to think about whether or not I need to pay for something. For one, if you’re a developer, Netlify’s pretty much free, but for two I get to try out every new feature that Netlify has, so I’m just rolling out always. If I think of something, it goes on Netlify. And hopefully I’ll do the same thing with Contentful, coming up pretty soon.

    Stefan: I tried Netlify last week the first time, and I was like, “That is nice.”

    Brian: Yeah.

    Stefan: It was really easy.

    Brian: Yeah, we try to make it easy.

    Stefan: HBB2 and CDN and yeah it was really good.

    Brian: Cool, I’m glad you liked it. So speaking of which, examples. I was trying to rack my brain, you guys have any good examples of use cases for Contentful working at companies?

    Rouven: All right, let me start. They’re not actually doing static sites, but it’s my favorite customer ever. They’re right up in London, it’s the British Museum, world-famous institution, very like old school dusty name. It’s the British Museum, they have the mummies.

    Brian: Could you do it in a British accent?

    Rouven: I can’t. You can tell my accent is horribly German and I lived in America for a year, and I still haven’t gotten over a German accent.

    Brian: Well, I don’t know if you watch any 1950s and ’60s movies, but all Germans are British in movies.

    Rouven: I haven’t heard that one. So before I left for the U.S. I was an exchange student they told me that in American TV Germans are either portrayed as Bavarians or as Nazis, so don’t be offended. So I always wanted to be the Bavarian. So the British Museum, dusty old mummy house, but they actually have an amazing digital agenda, they have a digital director.

    And Contentful is their default CMS now for all things. And they’ve done some amazing things, which is actually my favorite use case, because something nobody thought of, when they designed Contentful. Audio guides, like the things you rent for 5 pounds, and walk around the museum and they tell you about the exhibit.

    Brian: Yeah.

    Rouven: These are running off Contentful.

    Brian: Wow.

    Rouven: So all the audio files, the pictures, the text, they are stored in Contentful. The curators and the editorial team, they add to it throughout the day. So the British Museum is a very old building, with very very thick walls, which is harder for wifi, so they don’t have wifi throughout the building. So they just have wifi at the booth where they rent out these devices. And they use our sync API to sync down the entire content onto the device.

    And then you take the device, you go through the building, and you have all the content available to you, without actually connecting to Contentful. And it’s my absolutely favorite use case, because I’ve been there, I’ve used the audio guides, they’re incredibly well done, they’re informative, they have pictures. The pictures are changing while the audio’s playing, they have like the family quiz version where you have tasks to do with your kids, like do pantomimes, or makes sounds and stuff.

    So it’s incredibly good content, it’s really well presented, and using our technology to enable it. So this is my absolute favorite. They do some other things, they have some websites running, or some signage systems, but these audio guides are so amazing. If you’re in London, go to the British Museum, take five pounds, it’s going to a good cause, partly to us, get an audio guide, just experience it. They’re incredibly well done, and it’s using the same CMS you can use to call your block. Just think about that. This is a big institution with a lot of money, and they’re using the same product you can use for free to call your block. That’s my absolute favorite.

    Stefan: Yeah, speaking of which, just to make that clear. Contentful is actually a set of APIs, so it’s not just only retrieving data, we also have a read-write API, so when you need your own interface, or a simplified version for that, that’s also available, and then also preview API. So when you for example don’t want to publish stuff but want to build an environment to see edited things, this is also included.

    Brian: Okay.

    Rouven: And the Images API, my favorite API to downscale images. Also one of our APIs.

    Brian: I’ll have to check that out. And then as far as Contentful, you guys have like a trial period or a free plan to check out?

    Stefan: The free plan is up to 50,000 API calls per month.

    Brian: Oh, okay that’s totally doable.

    Stefan: I think so too, that this is enough for a side project.

    Brian: Yeah, and if you go over that then you probably want to talk about investment, and maybe getting some VC funding or something.

    Stefan: Exactly. This is the normal reaction that happens then. When you have the problem that you’re dragging 50,000 requests, you have different problems than.

    Brian: Yeah, than paying for Contentful.

    Rouven: Especially since 1,000 more API calls are just 15 cents. So if you pay us 15 cents, you get to keep using the API.

    Brian: Yeah.

    Rouven: We’re very cheap for Germans. We’re easy, just give us some beer, we’re good.

    Brian: Cool, I’ll keep that in mind, I’ll send a case of my finest Budweiser.

    Rouven: Um, Czech Budweiser you mean, not American, right?

    Brian: Well, Budweiser is not the best beer, it’s not our best export.

    Rouven: The Czech one is really good, it’s also called Budweiser, but it tastes way better.

    Brian: Cool. I really appreciate you guys talking about Contentful and kind of giving us the rundown, but for now, let’s go ahead and transition to picks, if you guys down mind. So yeah, these picks are jam picks, anything that you’re jamming on, things that are keeping you goin, that you like to do to keep your work going, or just even outside of work. So technical or non-technical are totally fine. But I’ll go first.

    My first pick is Webpack. Webpack is a build tool. A year ago I barely knew what it was. One of my lead engineers, actually Christian Schinzler, I worked with him, and he was a big Webpack fan.

    So Christian was actually on Episode Number One on the JAMstack Radio, so for anybody who remembers that far back, but yeah he was a big Webpack fan, I didn’t know anything about it. And I finally got around to actually learning it well. So I highly recommend checking out the webpackjs.org docs, because they did a really good job of making sure it was clear.

    Rouven: Version two is much better, right?

    Brian: Yeah, version two is much better, you can actually understand what’s going on, it’s very clear. So I’ve been doing offline plugins, service workers, I’ve been optimizing our build to make sure it’s not crazy heavy-weighted and stuff like that. And just from a little reading I was able to improve our bundle size and stuff like that. So highly recommend Webpack.

    My next pick is actually Service Workers, too, just roll right into that, there’s a cool offline plugin for Service Workers, which I’ve implemented in Netlify. It’s not in production yet because I’m trying to figure out some crafty ways to offline our docs to as well, currently just our homepage is offlined, so hopefully when you lose network requests on your phone or your desktop, you’ll be able to at least read our docs.

    And all that will be cached, will which be super awesome, so check that out, Webpack and Service Workers. My final pick is Luke Cage, which is a Netflix series. So I don’t know if you guys get all the Netflix series in Berlin, do you?

    Rouven: Yeah, most of them.

    Brian: Most of them? Well Luke Cage is made by Netflix, and it’s a Marvel series. He’s an African-American super hero, and he came out during the jive-talking ’70s, and that’s where he kind of was birthed in the comic books, and they’ve modernized him and put him into a Netflix series, Marvel series, and they’ve also brought along some of the ‘70s undertones too, which is really cool, a lot of the music, a lot of the stuff that came from that comic book.

    I’m very impressed that they were able to intertwine it and not make it as cheesy as the comic books were. So I just finished it, it took me a while to finish it, cause I have no time to watch TV as of late. I do a lot of coding and a lot of side projects, so I just don’t find the time. So I just finally finished the last couple episodes, so I just wanted to recommend, anybody who hasn’t seen Luke Cage, check it out, and then maybe read the comic and try not to laugh. Stefan, since I introduced you first, you have some picks you want to share?

    Stefan: Sure. One question though, have you SW Toolbox when you play around with Service Workers?

    Brian: I haven’t. What’s SW Toolbox?

    Stefan: That’s actually a Google library. And I did a Service Worker implementation six months ago, and it took a while to get my head around it, because you have to hook and to activate and fetch and all that stuff. With SW Toolbox, it’s five lines, reconfigure it, you can say cache first, network first or whatever, and I implemented it and it was like “Wow, I lost a lot of time here.”

    Brian: Yeah, I definitely did spend at least a week on just tinkering and manipulating different things and fetching and pushing.

    Stefan: Check it out, you will see that it’s not that hard then.

    Brian: Okay, cool, I will, I definitely will check it out.

    Stefan: Okay, well cool. My first pick is Unsplash, this images API, where you can get beautiful images under Creative Commons License, for free. That’s awesome, I love that. Especially when I do conference talks or something, I spend a lot of time just looking for beautiful images, so this really helps me out.

    And actually, three days ago I came across an app that is called Zoomi, or Zoom-eye, which is basically a MacOS app which queries a lot of image services that are all Creative Commons, so I now just have to type in a phrase and I can choose out of 100 beautiful images what I want to use for my presentations, so this will definitely save me some time, I recommend it.

    And extra today, when I was younger I was a little more into music, this kind of disappeared when I started coding. But accidentally I came across a band I used to listen to, which is Marot Rockel, it’s a little bit funky electronic music, and I listened to them the last time six years ago, and I discovered that they released three more albums, and I had a dancey day today, it was really good.

    Brian: A dancey day, it’s too bad this is an audio medium.

    Rouven: Stefan really cares about his stock images. Stefan is our slide quality obsessed evangelist. Whenever I had to do any presentation I had my slides to Stefan, and now I get a list, a Google Doc two pages long with all the things wrong with them back. And after I go through it they’re going to be perfect, but he’s really obsessed with the quality of his slides, and he’s great at it, so he loves his images.

    Stefan: It has to be pretty, right?

    Brian: Yeah. I was going to say I was going to look up some of your talks so I can try to mimic some of your talking in slides. Most of my slides I throw it together last minute, so you probably won’t be proud of mine.

    Rouven: Yeah, me too, Stefan is different, Stefan is amazing.

    Stefan: Well thank you.

    Brian: Reuven, you got some picks for us?

    Rouven: Yeah, of course. I’m late to the party, because I got late to Germany, but I’m really in love with the Alexa API right now. I’ve done two skills right now, I’m working on my third one, all of them using Contentful, because “ooh multi-platform.” I get to use content in a non-visual way, which is breathtaking to me still. But even beyond that, just the quality of the interaction, but also the work that goes into the interaction, and actually having to think about, “Hey how do people want to interact with something where you can’t click” is to me just fascinating.

    So I love the API, I love that I can use it AWS lamda, so I don’t have to run a server anywhere, I don’t have to think about hosting it anywhere, I just upload it to Amazon, and Amazon takes care of all the crap for me, but also the thought pattern, having to evolve from, I’ve always done either PHP band dev, or JavaScript phone-in dev, so it was always very visual, and having to think about in a different fashion is to me super engaging right now.

    And the other thing I was raving on today is, for lunch today with a co-worker I made the most awesome omelets ever in our brand new kitchen, we just moved to a new floor with my team. I just love food and today’s omelets were amazing and we had some good wine for it for lunch, and it was the best lunch I had for a long long time. It was amazing. Shout out to Linn for actually having the idea of making us omelets today.

    Brian: Nice. You can’t underestimate a good omelet. Anyway, guys thank you very much for coming on, jamming with me and talking about the JAMstack, talking about Contentful. I’m very intrigued, I’m definitely going to be using this for some future side projects, and getting real used to it.

    This podcast is brought to you by Heavybit, a program that helps developer-focused companies take their product to market. Throughout the program, founders work on developer traction, product market fit and customer development. If you like what you hear, be sure to subscribe to Heavybit’s Podcast Network on iTunes.

    — Malia Powers

  • 5 Common Misconceptions of Serverless Technology

    5 Common Misconceptions of Serverless Technology

    The rapid growth in serverless technology affords companies opportunities to save money on server costs and allows developers to save time and focus on coding rather than back-end operations. A challenge with such swift adoption is the difficulty in maintaining a standard understanding. In anticipation of the Serverless Conference, which was held last week in Austin, Texas, we asked experts in Heavybit’s community about common misconceptions.

    Myth #1: Serverless is a Revolutionary New Direction for Software

    “A common misconception is that it’s a revolutionary new direction for software,” says Nick Martin, co-founder and CTO at Meteor. “Really, it’s just the next step in the evolution of making software development faster and easier. Like the compiler, the database and cloud computing did in previous eras, serverless further abstracts away the complexities of modern app development and is part of an ongoing trend to free developers from entire classes of concerns.”

    As for the benefits for developers, Martin notes that developers can now “focus on their application logic and avoid undifferentiated work like provisioning, server management, or load-balancing.” Serverless ultimately “promises to let developers ship apps faster and at a lower cost,” he says.

    Myth #2: Serverless is a Gadget Technology for Hobbyists

    Nick Gottlieb, head of Growth at Serverless Inc. believes that one of the biggest myths is that it’s a ‘gadget’ technology that’s not mature or only for a hobbyist. “While serverless compute is still a very early technology, it’s built on the same core infrastructure that providers like AWS, Google, and Microsoft have been investing in and selling to enterprises for years,” says Gottlieb. Furthermore, “because the underlying infrastructure is battle tested, and the value it provides around cost savings and faster time to market are so great, there is already huge amounts of mission-critical enterprise workloads being done on serverless compute.”

    Myth #3: Serverless Will Hurt the Movement Toward Containers

    “Containers will continue to be front and center in terms of the underlying infrastructure, but that doesn’t mean they will be the primary unit of deployment for developers,” says Lawrence Hecht, author at The New Stack. “Take, for example, a cloud provider that may build its FaaS (function as a service) on top of containers and use Kubernetes to manage that deployment,” he says. “Individual developers would then deploy application components to functions instead of to container images.”

    Hecht notes that this will not happen right away and in the meantime, “We’re seeing emerging companies build dashboards that allow developers to choose which VM, container or function they want to deploy to. Those dashboards are becoming the gateway to the CI/CD pipeline.”

    Myth #4: Serverless is Free of Security Vulnerabilities

    “The biggest security misconception is thinking you no longer need to worry about known vulnerabilities,” says Guy Podjarny, co-founder and CEO at Snyk. While serverless addresses the risk of known vulnerabilities in OS dependencies, such as OpenSSL’s Heartbleed vulnerabilities, “These ‘unpatched servers’ account for the vast majority of successful attacks today. Serverless applications still contain a large and growing number of application dependencies, pulled from npm, Maven, PyPI and more. These components often carry known vulnerabilities, and require diligent monitoring and preventative tools.”

    Myth #5: Serverless Means No More DevOps

    “A common misperception is that it completely absolves development teams from the harsh realities of operating software,” says Joe Ruscio, partner at Heavybit. “While it does promise to almost completely do away with the ‘undifferentiated heavy lifting’ of provisioning and managing infrastructure, understanding how your application code performs in production remains of paramount importance.”

    — Malia Powers

  • The Secure Developer Podcast: Continuous Security at Chef

    The Secure Developer Podcast: Continuous Security at Chef

    Welcome to The Secure Developer, a podcast about security for developers, covering security tools and practices you can and should adopt into your development workflow. The Secure Developer is hosted by Guy Podjarny, CEO and co-founder of Snyk.

    In this episode of The Secure Developer, Guy talks with Chef CTO Adam Jacob about the role security can play in DevOps and continuous integration/deployment. They cover the differences between baked-in and bolted-on security and how automation with Habitat can change the way developers approach secure coding. Adam Jacob is the co-founder and CTO of Chef, formerly known as Opscode, where he wrote the open-source, automated applications project Habitat.

    This podcast is brought to you by Heavybit, a program that helps developer product companies take their product to market.

    [soundcloud url=”https://api.soundcloud.com/tracks/295763125?secret_token=s-AfcYk” params=”auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=false” width=”100%” height=”166″ iframe=”true” /]

    Guy Podjarny: Hello, everybody, and welcome back to The Secure Developer. Today we have an awesome guest on the show, Adam Jacob from Chef. Adam, thanks for joining us.

    Adam Jacob: Hi.

    Guy: We’ll talk about various cool topics we teed up, that I think are interesting with the world of security and the world of DevOps and CI/CD, and some very interesting new package management, build system capabilities coming out of Chef that I think are very relevant to the security play.

    Before we dig in, for the few of you that might not know Adam Jacob or Chef, Adam, do you want to give a quick intro of your background?

    Adam: Sure, I think there’s probably more than a few who have no idea who I am. I’m Adam. I wrote Chef, originally. I’m the CTO at Chef, and I wrote a thing called Habitat not that long ago that does application automation. And that’s sort of new stuff.

    Then, mostly what all of that really boils down to is, I spent the last 10 years going around talking to big web companies like Facebook and Google and Yahoo, and I’ve also spent a bunch of time with startups. And then I’ve also gotten to go see really large enterprises ranging from giant banks to insurance companies, retail companies like Nordstrom, Wal-Mart.

    So I get to just travel around and see what everybody is doing and see what they’re worried about and try to help them get better in terms of the time it takes or the speed to deliver, or their organization or their culture. So a bunch of it is software, but a lot of it is just helping people sort of understand how better to build their organization.

    Guy: Yeah, I guess there’s always this conversation about whether DevOps and, well, continuous deployment maybe is a little bit more specific, but DevOps is really more about the tools and more about the people and it tends to be a consensus that it’s more people.

    Adam: It’s both, right? Like, if you have a great culture, it’s really easy to say that you want to have a good culture. It’s really easy to be like, “Oh, I want to empower people,” or, “We want to streamline a process,” or whatever. It takes nothing. It’s just words.

    Usually, it’s the technology that reinforces those cultural behaviors that hold you back.

    So, a good example is, “Oh, I want to do continuous delivery, but we use a terrible source control system that makes it almost impossible to do effective continuous delivery. But because that’s the source control system we use, we’ll never change.”

    Therefore, which one’s true? Do you want to do continuous delivery, or do you love your bad source control system? So there’s this reinforcing circle that hides inside there, and I think you see that all the time in security, too, that same circle and that same behavior.

    Everybody says, “Oh, we want to be secure.” I was working with a bank who I won’t name, and I was on an engagement for a couple weeks.One of my first questions that’s going to help them do continuous delivery, and they wanted to, their first target was, to harden the operating system.

    I asked them, “Okay, do you have the hardening spec? Do you know what you want to harden?” And they were like, “Oh yeah, yeah, of course we do. We’re a global bank.” And I’m like, “That’s amazing, great! I would love to see that.” And they’re like, “Oh, we’ll have it for you on the day you arrive.”

    I left three weeks later, and they had never found it. And what they had realized was it didn’t exist. Everybody thought someone else had built that, and that it was someone else’s job, and no one actually did. It was just this loose conglomeration of stuff that theoretically they were supposed to do, but no one actually could track or knew. And that’s a global bank. It probably should matter.

    Guy: I think sometimes it’s about the mess or the fact that tools can help surface information and hold information in a way that is accessible. And sometimes it’s just the sheer obstacle for many of these more complex topics when you talk about deep ops topics around how containers operate or how some machines are orchestrated.

    Or in the world of security, when you talk about deeper security, understanding about what’s an attack, what’s not, and that sort of a constantly moving landscape. Just fundamentally, you have to have the tools. You cannot overcome those problems by sheer education. And at the same time,

    if you have tools and people don’t know how to use them, or they have no understanding of what they’re for, then you would eventually not achieve what you’re aiming for.

    Adam: Context is everything, right? Tooling is great, but it’s not enough. One of the things that we do at Chef and in the security world, is we have a thing called InSpec, which is a language for letting you describe security posture and code.

    So you can say, “This particular machine should have this particular policy. That policy means that port 25 should be open, you should be able to auth this way, you shouldn’t be able to auth this way.”You should be able to talk about packages being installed, you should be able to talk about all of those things and then relate them back up to the actual security line items and talk about their severity.

    We care about this thing because of this piece of HIPAA, or we care about it because of this piece of CIS, or whatever. And those tools are great because they sort of combine the documentation of, this is what the standard is, with the check that actually is executable that says, “And are we meeting the standard, yes or no?”

    I think whether it’s InSpec or tools like InSpec, when you think about that operational part of security and how it applies to those large enterprises, especially large enterprises, but the big web, too, more and more it’s becoming that policy is executable.

    So that conversation between security and developers and operators becomes a conversation around code as opposed to a conversation around documents, and controls, which I think is really the conversation most people have now.

    Some security guy wrote a control and then here’s the list of people that say that they can validate the control. But is the control any good?

    Guy: Is it actually happening?

    Adam: No. I mean, it’s not, right?

    Guy: Yeah.

    Adam: And that’s true everywhere. We wrote a control. Here’s the list of 10 people that you could go interview that know how to do that control. Okay, what about the other 10 people who could also do that, that aren’t on the interview list that wasn’t updated on the last year? Do they always do the procedure the right way?

    Do they always make that process right? And of course, the answer is no. But we just sort of let it ride because the auditor passed.

    Guy: Yeah, it’s the notion of protecting yourself from audits, not from attacks.

    Adam: Exactly!

    Guy: It becomes sort of increasingly there. I love that notion. So with InSpec or, in general, with security, one of the key challenges is that it’s invisible. So if you’re not doing it, you really have no immediate indicator to the fact that it’s not happening.

    The user experience, if you will, of not monitoring, not watching for a certain vulnerability, and the user experience of watching for it and having nothing happen, is the same thing, which is, nothing happens, right?

    Adam: Yeah, which is nothing.

    Guy: Which is good news. So I think anything that helps define and articulate the controls that are supposed to be happening, giving you some mechanisms to understand that the action has been taken so you know that InSpec, the locking or whatever, say, if we use a simple example, the limiting of ports being open, that has been explicitly articulated and explicitly tracked by the tools here, and you can get informed that it has happened.

    We see this in Snyk a lot. We watch projects for vulnerabilities, for vulnerable dependencies, and then you have really, again, it comes back to the fact that you have the same user experience. If you’re not watching a project, or if you’re watching a project for vulnerabilities and none happened there, and we have a lot of these conversations with users today about, “How do you want to hear about it? How do you want to know that you’re watching it?”

    And today, we remain fairly simple. We just remain in this ongoing report that just sort of shows you, “Hey, you’re monitoring five projects” or something, and they have those things.

    Adam: Right, it shows that it reacts often, or whatever, and we can measure change.

    Guy: But it’s great to sort of increasingly have those and have some requirement, whatever, in your Chef and InSpec, and that defines it as well, project X is being monitored for X, Y, Z, so you know it’s being enforced.

    Adam: Right, and then you stick that in the pipelines.

    When you think about continuous delivery and security, security and the validation of that compliance is part of the process by which software goes into production.

    And it’s part of the way that software gets maintained once it’s there, and it’s part of that build process. You bake it in sort of throughout the SDLC, instead of it being a thing that happens at the end.

    And that’s one of those things that’s obviously a good idea. So, as soon as you hear it, you’re like, “Oh, of course, security should be baked into the process, all through the whole thing.”

    Guy: The whole built-in versus bolt-on.

    Adam: Yeah, right? Sort of, duh. But actually, doing it is actually completely–

    Guy: A whole different ball game.

    Adam: A whole other ball game. And the thing that we really came to realize, especially with InSpec, but just sort of in general, is that if you can’t figure out how to manage that security posture the same way you manage the rest of what you do, it’s really difficult to then tell a software developer that it’s their responsibility to ensure that that posture is good or bad. Because, sure, they can make that they write “good code.” You can’t hear the air quotes, but m I was making little air quotes in my brain, probably.

    Guy: I can attest to that.

    Adam: It’s good, but you can’t really ask them to understand the posture of what it’s going to be like when it’s deployed.

    Because the distance from a software developer making a decision to a software developer talking about how that software should be in production, and what it’s posture ought to be, is so vast. And their ability to influence it is so low that it’s really difficult to come back to them and be like, “Oh, this was your responsibility.” Like, clearly it was on you.

    And when those tools give you the ability to talk about it as code. They allow people to participate, you can code-review them. You can have security people audit the code as opposed to audit your documentation, and then have those things as a living piece of that deployment model, I think everything gets better and it gets a lot more secure.

    One hard part of doing things that way is that it’s very not the way that most security regimes are set up right now. If you go talk to a security officer and you ask them, “Hey, could we remain compliant to whatever the standard is, HIPAA?” If everything we did was continuously delivered, nine times out of 10, the answer is just a flat no.

    And what’s interesting is that there is, one out of 10, where that security officer is like, “I don’t know, maybe. Tell me more about how that would work.” And I think if I roll my clock back three years, it was 10 out of 10 that we’re telling me no and that was crazy. And now it’s like nine of 10. And I predict in six months, it’ll be six of 10. And then in two years, it’ll be like talking about, “Should you be doing continuous delivery or should you be doing Agile?”

    Guy: It comes back actually to the commentations sometimes or even that document or something that big bank did not have. Like, these things eventually come back to the documents and to the guidelines. So at the end of the day, you go down the compliance route and you actually have that in the compliance document that it says, well, if you are using continuous delivery, then to be HIPAA-compliant, you need to ensure that you’re doing these things as opposed to just sort of having the goal in it.

    Many of these regulations have the same flaw, the same notion that says, “Well, you have to do these actions,” as opposed to, “You have to achieve these goals.” So they give the vague goals, but then everybody prescribes to whatever recommended actions that have been prescribed, because that makes passing the audit the easiest.

    Adam: Yeah, and I mean,

    the relationship between the auditor and your security posture is pretty tight.

    Like, the real test of your security posture, in most cases, is the auditor. Not like a pen test, or people actually trying to break you. I mean, they are, but you’re not doing it proactively.

    I think when you think about those CD pipelines, the idea that they’re applied continuously, that as applications change, that you’re reapplying the security posture to see if that application has done something that violates that posture, and that when you change the security posture, you’re re-validating the applications and you’re doing it sort of throughout the whole cycle, it’s super powerful. It’s what people are starting to be able to do. I think you don’t see it a lot yet, but it’s sort of the future.

    Guy: I think that’s interesting to understand, the potential versus what’s happening, right? High-level continuous deployment and your whole infrastructure’s code, the fact that you’ve prescribed it, built it in, allows you to get predictability. You know what’s where, and you know that a certain test or a certain enforcement has been done to the extent of bugs. But at least, not as human error.

    On the flip side, it requires security auditors to change how they behave. It’s not just about that compliance, it’s also the fact that today, many of these security audits, you gave the example of a security auditor reviewing your code, are done as gates.

    They’re done as a way that says ‘stop here,’ which is the antithesis to continuous.

    The whole notion of continuous is just, you roll out. It’s okay to pause for a moment, but you can’t stop. You can’t accumulate a backlog, because otherwise it’ll deteriorate, unless you automate that.

    Adam: Yes and no, right? There’s continuous deployment, and then there’s continuous delivery,and they’re not quite the same. So yes, in continuous deployment, there’s nowhere to pause. I think in continuous delivery, there is.

    In continuous delivery, the idea is you’re shipping when you should be able to ship, any time that the business required shipping or it made sense to ship. And that’s different than saying, “We just ship every time you commit,” right? And so in continuous delivery, I think there’s plenty of space to say that, “Hey, this project, in order to ship, requires a security review.” And that process can still be continuous.

    The question is, that should be the only gate between you and getting to production. So if they say yes, could you ship? And then the question of course is, is that true for every commit? Like, could you ship today, if today was the time? The answer to that is very rarely yes, and so that’s where the difficulty comes in.

    Guy: Yeah, and I think it’s an interesting comment. I accept the delta between continuous delivery and continuous deployment, but it seems to me that from security route, well, first of all, even from a quality perspective, one of the values of continuous, both delivery and deployment, is the fact that you spot errors when they’re small, at any given time.

    So definitely, for continuous deployment, when you ship every small code change, whatever, at some low resolution, when a problem occurs, it’s much easier to pinpoint to what was the issue, the source of the problem.

    That value proposition is pretty compelling in security as well, right? If you are looking for a security flaw, being able to, only looking at it within the range of whatever the 100 lines of code to change versus the 100,000 lines of code or 100 million that existed, is very valuable. If you accumulate those changes and you need to now do the security audit, I would argue you’re not actually ready to deliver in that spot.

    This podcast is brought to you by Heavybit, a program that helps developer-focused companies take their product to market. Throughout the program, founders work on developer traction, product market fit and customer development. If you like what you hear, be sure to subscribe to Heavybit’s Podcast Network on iTunes.

     

    — Malia Powers

  • To Be Continuous Podcast: Category Creation featuring Martin Casado

    To Be Continuous Podcast: Category Creation featuring Martin Casado

    In this episode of “To Be Continuous,” Paul and Edith are joined by Martin Casado, General Partner at Andreessen Horowitz. He previously was co-founder and chief technology officer at Nicira, which was acquired by VMware in 2012. While at VMware, Martin served as senior vice president and general manager of the Networking and Security Business Unit.

    The group discusses the deeply complicated and difficult process of category creation, with a special focus on technology infrastructure products.

    This podcast is brought to you by Heavybit, a program that helps developer-focused companies take their product to market.

    [soundcloud url=”https://api.soundcloud.com/tracks/283115632?secret_token=s-zX7AW” params=”auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=false” width=”100%” height=”166″ iframe=”true” /]

    Edith Harbaugh: What do you like about continuous delivery?

    Martin Casado: I think that there’s a broader movement around continuous delivery that is really interesting, which is, traditionally, infrastructure and operations came from an independent group. My first job out of undergraduate was working on simulations code in a national lab.

    I couldn’t control anything about infrastructure. I really didn’t have budget to buy a pencil. You get infrastructure, and you’d have some application to code, and you’d work on that application. We’d fiddle around with our MIG files or whatever, and that was pretty much it.

    The cool thing about the broad movement now, and I think CI/CD (continuous improvement/continuous delivery) is just part of this, is more and more applications, application developers, are actually getting responsibility for operations.

    This is provisioning, this is delivery, this is deployment. That’s a big huge change in not only what technologies get created but who’s consuming it and why they’re consuming it. I think it’s actually one of the more interesting trends right now.

    Edith: This would be a great time for you to introduce yourself.

    Martin: My name is Martin Casado, and I’m a general partner at Andreessen Horowitz.

    Edith: But you did stuff before you were at Andreessen.

    Martin: That’s right. The quick arc, as I mentioned, I used to be a research scientist at Lawrence Livermore National Labs. I spun out of that, did my PhD at Stanford. My research was in networking, so I was part of the team that started software-defined networking.

    I was there for four years, spun out of that, started a company called Nicira where we did software-defined networking. I did that for five years. That was acquired by VMware. I ran the networking security business unit at VMware for almost four years, and four months ago I decided to change and become a VC.

    Edith: So you basically created a category. What drove you to do that? What made you decide to start something knowing that it was so hard?

    Paul Biggar: You’re talking about software-defined networking? For the viewers at home, Martin roughly invented software-defined networking.

    Martin: There’s a whole bunch of people contributing, but I think a lot of the original momentum came from my thesis. You know, I’m going to be totally honest. If I had any idea how hard it was, I never would’ve done it.

    Edith: Really?

    Martin: I think so.

    Edith: I think you would’ve.

    Martin: Well, maybe. But it would’ve been a lot more daunting. I came out of Stanford pretty darn naive, like, “This is going to be easy!” Now, nine years and tons of gray hair later, I just realized that, man, it was a battle. I don’t think I had one-quarter that was easy. Everything was a battle.

    This is the way that I think about it. If you’re an entrepreneur, and you’re going to do category creation, you basically just have two jobs, in addition to product development. And job No. 1 is, there’s going to be some constituency out there you’re selling to, and that constituency, they wake up every morning and they think about all sorts of stuff, but they’re not thinking about your thing, because it hasn’t been created yet.

    That object in the mind space, that object doesn’t even exist in their brains yet. The first thing you have to do is create that object. It’s like Leonardo DiCaprio at “Inception.” You go in, you’re planting an idea in somebody’s head. It has to become a thing, something people think about, something people know and integrate.

    This is from nothing, and that’s hard. For us, it took five-plus years, and it touches every aspect of thought leadership such as analyst relations and technical conferences and broad marketing.

    Paul: So the activities that you’re doing in that category creation are largely marketing and getting people to hear about the activity and learn about it?

    Martin: I think so. I think maybe technologists will view marketing as this pretty shallow thing, but I think you’re exactly right. It’s marketing. But it is often very technical marketing, for example, in the guise of open source.

    In releasing open-source projects, you’re getting people to use it, you’re going to standards bodies, you’re going to conferences. It’s an incredibly technical thing, but in the end, it’s marketing in the sense that you’re actually creating awareness and a market.

    The first thing that you’ve got to do as an entrepreneur is, if you’re doing category creation, nobody’s thinking about your thing. You’ve got to get them to think about your thing, which is a lot of work. In my experience, five to seven years.

    Then the second thing that you have to do, which is just as much work, is then you have to attach a value to that thing. And I think we as technologists, there’s this kind of fallacy that we have where, “I’m going to create this new widget.” Let’s say I create the iPhone.

    Paul: Everyone will know how amazing it’s going to be.

    Martin: Exactly.

    Paul: Just build it and they will come.

    Martin: Yeah, there’s intrinsic value in my widgets. I take my widget, I put it on a sidewalk and someone picks it up. They’re like, “This is amazing. It’s worth millions of dollars!” And that’s totally not the reality.

    The reality is people only see value if they exchange money and they’ve used it.

    And if you’re doing category creation, how do people know what that value is? It’s a very difficult thing.

    Paul: And when you say attaching value, do you mean monetizing? Or is there more to it than that?

    Martin: I meant more the idea. Ultimately, this materializes monetization. Let’s say that you’re my constituency, and I’ve created this new widget. First I need to get you to think that this is actually a real thing. I’m going to call it a new phone. So, you need this new phone. First I need to convince you that you need the new phone.

    Then the second thing I need to convince you is it’s worth tens of thousands of dollars to you because you need to mentally actually attach that value to it. And it turns out introducing new concepts don’t necessarily have value if they’re new concepts.

    Normally, the value comes from, for example, an actual transaction. There’s a psychology around this. Or at least some experience with it, knowing that it’s going to, I don’t think you can just sit back to a couch experiment and be like, “Oh, I think this is going to save me money, therefore it’s worth something.” It really requires a lot of effort to make value.

    Paul: So the category that I see being created, or the one that’s closest to me at least, is this idea of containers and Docker, and more specifically Kubernetes, the idea that there’s this cloud infrastructure over there. The way that I became aware of it is exactly the way you’re talking about it. There’s open source coming out there that you can use and you can hack on yourself. There’s talks up there where people blow your mind.

    Martin: I think that actually this point, and certainly for all the listeners, I think this is one of the most salient points of this decade, actually, which is going to be a weird thing to say. At least an infrastructure’s the following.

    In the past, how did we create mindshare and customer bases? Well, there’s this whole pmm function and this whole sales function. And if you look at the big enterprise companies, if you look at Cisco and IBM and Oracle, really their power is this function. They own the sales channel.

    They have great relationships with the analysts, they’ve got great relationships with the customers, they’ve got certifications and the classes. So anytime they have a new concept, they take that concept and they cram it down the machine.

    As a startup, it doesn’t matter how cool your technology is, the hardest thing is to actually penetrate that channel.

    But when it comes to this new era of open source, now you actually have this hack that’s never existed before, where the buyer is shifting from an operator to a developer. Developers like open source, and you can actually create these concepts by getting open source out there and getting them to use it.

    Paul: We’ve been talking about this sort of thing, just the idea that it’s bottom-up now versus top-down.

    Martin: Not only that, it’s a totally different buyer that’s a totally different aesthetic. I don’t think developers care as much about analysts. I don’t think developers care as much about the 42-long sales dude with white teeth and the boat. I don’t think developers care as much.

    Paul: They won’t even answer his call.

    Martin: Exactly. About the channel, I think they don’t care about complex procurement processes.

    Edith: Having sold software for a little bit myself, if you get into a bigger corporation, you still don’t start to run into that.

    Paul: You get there, because the developers were first asking for it to exist.

    Edith: The longest part of our sale cycle is you get bounced to procurement and legal.

    Martin: Absolutely. I think this is the most important nuance of this argument, is exactly what you said. I’ve always maintained that open source and the developer is replacing marketing and pre-sales, not sales.

    You get credibility to the account, you can get things to technical close and technical validation, you can get account pull. So it’s almost like filling the pipeline, getting the transaction done, I still believe. For a long time, you need to have a professional, direct sales force that will be in there pushing things for procurement.

    Edith: It’s just a lot of work, because you pass the technical evaluation. They’re like, “Okay, go talk to procurement.” And to procurement, you’re a widget.

    Martin: Right, but the good news is, now it’s possible. Where in the past, to get that much legitimacy, to get things to technical close, was very difficult. You didn’t have the certification, you didn’t have access to the buyer, you didn’t have the account rep to make the introduction. You didn’t have any of that.

    Edith: That’s true.

    Martin: And now you do, and now it’s just about actually going through the logistics. And you’re absolutely right, it’s hard, it’s baroque. I’ve called it tribal bloodletting. It’s all of that, but you can do it as a startup.

    Paul: The thing that I think is really interesting is the converse of that. It’s that people who work in open source now are becoming actually incredible marketers. They don’t refer to themselves as such, but they have amazing social media presence.They build up tons of channels, whether it’s mailing lists or just Twitter followers.

    Edith: It’s like everybody recreates marketing. Everybody’s like, “Oh, we don’t need marketing.” Then you’re like, “Well, what is this thing over here where you have an email list?” Oh, that’s not marketing.

    Paul: It’s not marketing because I’m a developer.

    Martin: I really think that those that know how to do this are some of the most valuable people in the entire industry because this is the new entree for products into customer bases. I mean, there’s another kind of potential pitfall here, which is, let’s say you’re using open source for marketing.

    Now, there’s probably $7 billion have been invested in open-source companies and only about a $1 billion worth of returns. I’m not sure if those numbers are true, but I hear them quoted all of the time. But the reality is, a lot of money’s gone into it and not a lot of money has come back.

    The reason is because now, if you’re using open source to do marketing, you’re almost cannibalizing your sales motion. And so for a long time, the only open-source model we knew how to work was the Red Hat model, which is a services company. Only Red Hat’s ever pulled it off. It’s been very difficult.

    But another shift has happened in the last few years is people have figured out that actually you can use open source for marketing, but you don’t have to confuse that with your actual product offering.

    And with the rise of services, you can actually use open source for customer traction. You can monetize the service, and when it comes to services, no discussion of open source or closed source. So I think that we’re actually starting to unlock viable business models where you use open source for marketing.

    Edith: Who do you think does a good job of that?

    Martin: I think GitHub is a great example, right? Git isn’t even built by GitHub. It’s the standard in Linux. But if you look at GitHub, it’s a very fast-growing company that’s based on open source, and so everybody knows about it because of Git. So Git is doing the marketing. And this is just one example, I think there are many.

    Paul: It’s funny that you cite that as based in open source, because almost none of their stack is actually open source.

    Martin: Exactly, it’s a service offering. That’s what I’m saying.

    Paul: When you say service, you’re referring to software as a service, not service as in consulting?

    Martin: Absolutely. I should’ve been more clear. The long-standing question for us, certainly since 1995, is how do you build an open-source company that has the margins of a closed-source software company? Because you’re open source, basically you become a service and support company.

    What has happened in the last decade is exactly what you’re saying: people will realize that you can get account credibility and account traction, account knowledge, through open source.But then you can offer a back-end service offering as a service offering, and monetize that, and it’s often a closed-source stack on the back end of what you’re doing.

    But you don’t talk about open source/closed source as much with service offerings. It’s normally if you’re consuming something on-prem that you think about those things.

    Paul: How do you feel about this? People who are building, let’s say CircleCI as a good model, but there’s a ton of them. Building something that’s a SaaS product, a hosted SaaS product, but that then sells to people who use it in their own VPC and pseudo on-prem sort of thing.

    Edith: Oh gosh.

    Martin: I come from this somewhat traditional world of selling enterprise software. In there, there’s this whole discussion, and I was part of this discussion, of is it on-prem or is it off-prem in general? And I think that you framed this question perfectly. I’ve realized that that’s a false dichotomy. It’s actually not the right question to ask. I think as a service, is it actually an operational model and a delivery model? It doesn’t really matter if it’s on-prem or if it’s off-prem.

    I think that the days of selling closed-source software to companies is done.

    But you can sell them services and you actually can sell them appliances. But if you look at appliances, appliances almost look like services. They’re boxes that have services, and often the upgrade is happening remotely, management is happening remotely.

    I do think that the right model for these companies, I think CircleCI’s a great example of this, you have open source that customers use, you have a SaaS offering, but you also have an on-prem delivery offering as long as you don’t change the operating model, as long as it still looks like a SaaS model somehow, whether it’s a managed service or something like that.

    I think as soon as it becomes shippable software, where you have to manage a heterogeneous set of environments, you have to manage all the day-two ops. It becomes unwieldy.

    Edith: I had a really interesting discussion the other day with the VP of Sales from CircleCI and somebody from Microsoft. CircleCI was basically like, “We love that it’s selling on-prem. It’s helping you.” Microsoft is like, “We’re trying to get off-prem desperately.” So it was not the argument you thought was going to happen.

    Paul: I think it’s probably because of how sensitive the IP is. If you’re talking about something like, well, documents are pretty sensitive, but the source code is very sensitive. And so people are not as happy to ship that off-prem as we once thought was going to be the case.

    Edith: Microsoft’s reasoning was, and this might be the way Microsoft had done it, is they have 10-year maintenance agreements.

    Martin: We have, “If you have a problem, upgrade to the latest version and then we’ll deal with you.” I think that’s kind of what everyone has. There used to be this idea that you’d create a fork and then you’d backport things to that fork or the old version, or something like that.

    I don’t know anyone who’s doing this sort of services, the SaaS with a managed to on-prem version that does anything but “the latest version is the version.”

    This podcast is brought to you by Heavybit, a program that helps developer-focused companies take their product to market. Throughout the program, founders work on developer traction, product market fit and customer development. If you like what you hear, be sure to subscribe to Heavybit’s Podcast Network on iTunes.

    — Malia Powers

  • Don’t Make Me Code: Environment Protection

    Don’t Make Me Code: Environment Protection

    Thanks for listening to “Don’t Make Me Code,” a Heavybit podcast that discusses developer experience design and the unique challenges of building developer-facing products. “Don’t Make Me Code” is hosted by Steve Boak, co-founder and CPO at Opsee, and David Dollar, co-founder and CEO at Convox.

    In this episode, Steve and David are joined by Sean Li, lead product designer at Docker. Sean, Steve and David discuss Docker’s acquisition of Kitematic, the friction of attempting to replace a developer’s existing tool, and the increasingly prominent role of design in developer tools.

    This podcast is brought to you by Heavybit, a program that helps developer-focused companies take their product to market.

    [soundcloud url=”https://api.soundcloud.com/tracks/274576622?secret_token=s-QHiyf” params=”auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=false” width=”100%” height=”166″ iframe=”true” /]

    Steve: We’re calling this episode of “Don’t Make Me Code” “Environment Protection,” and we’re here with Sean Li, lead product designer at Docker and one of the founders of Kitematic.

    Sean: Thank you.

    Steve: Thanks for being here with us. This is a really exciting conversation for me because we get to talk to a product designer for a company like Docker.

    Sean: It’s good to be here.

    Steve: Kitematic is a real interesting project for a bunch of reasons. I mean, it caught the interest of Docker. It’s also proven to be a really novel bit of development environment technology. And so we’re curious how it all got started.

    Sean: It got started in a university dorm room. I was a student from University of Waterloo in Canada, and the school actually offers a pitch competition. So we had this idea around making development environments easier, and so we pitched the idea and won. That’s how we got enough money to get started.

    Steve: Wow, and was it at all tied to Docker at that point?

    Sean: Docker was actually what we used for the back end. At the time, Docker was version 0.3. And then we’re on Hacker News, and we’re like, “Oh, this is interesting. It could be super useful technology to do what it wanted to do.” Our idea was essentially like Dropbox for your code.

    You get a Dropbox-like icon on your task menu, and then you can put code in it. For example, Django, it would just run it for you. And you can see it on the browser.

    Steve: Oh, nice. And so you have your production environment there, compiling for you and ready to go.

    Sean: Yeah. Then, when you added the code, it will sync to the cloud environment and then update right away.

    Steve: Nice. That’s awesome. It’s like a step beyond GitHub. It’s not just committing the code; all the CI and everything is built into this one workflow.

    Sean: That’s like the future plan right at the time, but at first, our MVP was super simple—just syncing code to a remote server and then seeing the changes.

    Steve: From the beginning it was implemented as a desktop application, you said like a Dropbox tray application.

    Sean: Yeah, because Dropbox was obviously the inspiration.

    Steve: And so why a desktop application?

    Sean: At the time, we actually didn’t realize the power of desktop application yet. At one point we used to pivot a lot, as startups usually do. And then we’re talking to customers, and they start realizing what we’re using underneath.

    We talk to Canadian Tire, the biggest retailer in Canada. They were looking for something like this, and they’re like, “Are you using Docker underneath? We want to use that.”

    At the time, the product we have is in the cloud, like an on-prem web browser setup. And then we started thinking of, instead of abstracting away Docker, why don’t we embrace it and then make it easier for the customers? Then we start brainstorming ideas, and it came across that having a desktop application is actually super beneficial.

    It’s like the best platform for developers, because they can import their code super easily. They can open a directory instead of having to upload files in a browser. You can also get a lot of access to their desktop, so once your tool gets more powerful, there’s more things that you can do.

    It’s also super cool because we use Chrome in an electron shell. And we wrote the UI in React, so that means we only have to worry about how the UI runs in that one browser, instead of having to worry about browser compatibilities across the board.

    Steve: So it’s not something React needed, it’s just running in a web view in the electron browser.

    Sean: And we make it feel as native as possible.

    Steve: All right, nice. So it’s a true desktop app in many ways, but specifically the UI, it’s a web UI.

    Sean: A lot of inspiration comes from the Atom Editor by GitHub. They’re using the same technology.

    Steve: And so this whole bit was open-sourced from the beginning?

    Sean: We were working on it, and then we open-sourced it.

    David: I’m curious what made you decide as you’re releasing this tool. Was open-source service a strategic decision, or you figured you could get more users by doing that? Or is it just wanting contributions from the community? Could you talk through a little bit of your inspiration behind that?

    Sean: I think the biggest part is if it’s something that touches their code, it’s really important that the developer trust it by seeing what the code is like.

    We’re really open about what we do, and also the part on gathering the feedback from the community is super, super helpful. I feel like, in general, open-source projects get more feedback from the community.

    Steve: With developer tools it seems like a great way to encourage participation. If you’ve got an open-source project, you’re inviting people to contribute. Obviously, our Opsee product for example, it’s closed, a SaaS application. So we don’t have the level of community support from developers that we would really like in some ways.

    Sean: We hired an engineer from Docker because he was a maintainer and he was super passionate about the project. It really helps on that front as well.

    Steve: Following from that, you launched this to an open-source community, did you have an idea of the kinds of users you were targeting at that point?

    Sean: We sort of did from the original product that we had, the Dropbox-for-code product. We had a signup list. A lot of these users are more leaning towards willing to use UIs and prefer something simpler. The super active ones are actually consultants that work on multiple projects.

    Steve: That’s an interesting segment. People there, maintaining a lot of projects, and they’re looking for an easy way to keep track of all that stuff. And Kitematic fit that mold.

    Sean: Yeah, and Docker being isolated also provides that value.

    Steve: That too. Now, if I’m maintaining multiple projects, I can have a Docker environment for each one. The app makes it very easy to move between those. And so specifically the React UI and the GUI, what was it like having that be part of the open-source project? Did you get contributions for that as well, or was that entirely internal?

    Sean: The React UI helped us in a way, because React is, according to a Google trend, almost on the same trajectory as Docker. So there are a lot of people willing to work on something that’s built in React. It was in a way accidental, because when we started, it was a really good technology to use.

    Steve: Did you have any designers contributing to the project?

    Sean: We do have design-minded people but not professional designers.

    Steve: For example, you’re a lead product designer at Docker and you, I assume, identify mostly as an engineer, or your background in coding. But there’s definitely this hybrid world in the developer tool space.

    Sean: Definitely. In the beginning we had hackthons. A lot of participants were trying to add features to Kitematic, then make a huge effort on figuring out the right UI right experience to build there. By default, I think what I wanted is sort of like designing an OS.

    A UI is very extensible, and you want to figure out the right points where you can extend on it. You actually focus on per component and really set an example of how you extend the current UI. When people contribute, it can follow that pattern. And you only had to make slight adjustments to it.

    Steve: That seems true of open-source projects, generally, too. You want build a broad base that people can build on top of and customize.

    Sean: Yeah, but the initial effort has to be really strong. Because otherwise you will get swayed by different opinions. And design by committee isn’t always a nice thing.

    David: That’s pretty interesting because you oftentimes see open-source projects that are sort of notorious, especially visually, for bad design or design by committee that ends up being a little too weird. I can think of some Linux desktop managers that I won’t name, but Kitematic is actually a beautiful application.

    Sean: Thank you.

    David: I’m curious how you managed to maintain that, even when you’re doing community-driven design.

    Sean: I think a big part of it is keeping focus and actually be willing to cut things. In the beginning, Kitematic actually had build, you can actually build an image and then push it. But to keep focus and make things simple before we figure out the next steps is actually making it run content only.

    Essentially the focus of Kitematic was helping users install Docker on their computer. You know, in a visual way, it feels very reliable. We solve a lot of underlying issues with VirtualBox in the beginning. And then after that choose a beautiful catalog where you can click one button and run a container. And then that’s the experience we were aiming for and focused on. So it’s super obvious what to do.

    Steve: Did you ever get push-back on those decisions from the community where you had to assert your position strongly there?

    Sean: No, I think the community is mainly supportive. What I had to manage was people trying to add too many things that are not focusing on that road map currently.

    Steve: I think I remember you saying, on the Software Engineering Daily podcast, that you did end up cutting quite a few things from the product after a bit of time. Can you talk more about that? You were trying to clean it up?

    Sean: The one thing that was cut was building images from it. Even though it’s a super important thing, we decided to delay it because we want to do it right. Instead of releasing something super early, and then get sidetracked into different things, we want to keep focus until we figure out this is it.

    And then release that as a whole. Talking about cutting more, the next version of Kitematic is sort of Docker for Mac. It really solved the core issues that Kitematic was trying to solve in the beginning, to install Docker reliably on people’s desktops in a way that it almost feels like it’s seamless.

    You don’t feel like it is running inside a VM at all, and that’s the goal in the beginning. You install Docker for Mac. When you open the terminal you can type “Docker run,” and it just works.

    Steve: Had the Docker for Mac project begun before the Kitematic acquisition?

    Sean: It was after the acquisition.

    Steve: So you were involved with that from the beginning.

    Sean: Yeah, I was the founding member of Docker for Mac.

    David: So it’s interesting to think about this this sort of internal debate. I guess with most design questions it’s customizability and configuration versus limited options, and this curated a beautiful experience. I feel like that happens even more with developer tools.

    It seems like Kitematic and Docker for Mac, some of these tools, are definitely trending towards the latter there, where you’re removing some of the optionality of Docker to make a better user experience. I think that’s really interesting.

    Sean: I think the two tools are, in a way, more complimentary. People usually use Kitematic by having the Kitematic UI side by side with the terminal. So they like the transparency that they’re getting from the Kitematic side, and the sense of it feeling reliable.

    “I see things are running. I can check the logs super easy.” On the other end, the terminal is how they’re used to working before, and that was sort of expected in the beginning. And then you go from there. You never want to displace a tool that they’re already using, one they’re so familiar with.

    So instead we embraced that but made Kitematic more of a complimentary to the Docker CLI.

    Steve: That’s really interesting. I’ve seen similar comparisons made with GitHub and some of their tooling. GitHub has their Mac app and their web UI and stuff like that. And I found myself going to them for things like diffs and comparison, merge states, something where I want to get a lot of text or get some status update.

    But for actions, if I want to do merges, everything I’m actually doing with it I’m still doing through the command line. But that’s a really interesting comparison, because it sounds like you’ve made the same distinction. To view things, maybe you go to the UI. But to actually take action?

    Sean: GitHub desktop is like a huge inspiration for all these decisions as well.

    Steve: I never really heard that distinction made this clearly, that there are certain things that developers are going to continue to want to do through the command line and through terminal. But that we can make the experience better in some ways, like just figuring out whether a container is running or not. That’s really nice to have a UI to see that all the time.

    This podcast is brought to you by Heavybit, a program that helps developer-focused companies take their product to market. Throughout the program, founders work on developer traction, product market fit and customer development. If you like what you hear, be sure to subscribe to Heavybit’s Podcast Network on iTunes.

  • To Be Continuous Podcast: Have We Forgotten How To Code?

    To Be Continuous Podcast: Have We Forgotten How To Code?

    Welcome to To Be Continuous, a show about continuous delivery and software development, hosted by Heavybit members Paul Biggar, founder of CircleCI, and Edith Harbaugh, CEO of LaunchDarkly.

    In this episode, Paul and Edith discuss the fallout after the widely covered “left-pad” incident, and while they agree that these sorts of moments move the entire open source community forward, they wonder: Have we forgotten how to code?

    [soundcloud url=”https://api.soundcloud.com/tracks/264605904?secret_token=s-Kv9Ep” params=”auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=false” width=”100%” height=”166″ iframe=”true” /]

    Edith: Hey, Paul. So, somebody unpublished a module called left-pad and the internet basically exploded. And now it’s been a couple weeks since then, so there’s a lot of different topics to cover in terms of what this means for open source, whether it means that people have forgotten how to program.

    Paul: So LaunchDarkly. Or, I’m sorry, the left-pad. I’m obviously looking at my own t-shirt.

    Edith: You’re looking at your LaunchDarkly t-shirt?

    Paul: The left-pad incident was pretty interesting and one of the things that we did when coming up to this was just, like, looking at all the Hacker News discussions and comments on it.

    And there’s wildly varying positions on what this means for open source, what it means for whether people can program, what it means for, like, about the Node ecosystem. So to kick this off, why don’t you give us a recap of the entire incident?

    Edith: Yeah. So, in short, a programmer had a module called Kik, K-I-K. Which is also [the name of] a very popular messaging app. I mean, even I’ve heard of it and I’m not a teenager.

    Paul: The Kik lawyers contacted the dude. Said, “Please take down your module, change it.” And the programmer said, “No. I basically don’t believe in copyright laws.” So then, the Kik people contacted NPM. The NPM people took down the module called Kik. And the guy, in I’d say, kind of a fit of pique, said, “Okay, you took down my one module, I’m gonna take down all my modules.” Basically, I’m taking my marbles and going home.

    So, he took down all of his modules. One of which turned out to be an incredibly popular module called left-pad, which did basically what the name implied. It sorted left pads. And without this in NPM, the quote I read was, “Builds all over the world started to fail very quickly.”

    Paul: So as I understand it, left-pad was used by another module, which was used by another module, which was used by something core, or like, this incredibly popular module—

    Edith: Yeah, it was basically turtles on top of turtles on top of turtles, and at the bottom turtle was this guy who—

    Paul: Took his marbles and went home.

    Edith: Yeah, or yank the bottom Jenga, basically.

    Paul: Gotcha. And so all the builds started to fail. People’s deploy started to fail. And people got pissed.

    Edith: People got pissed because they didn’t even realize that they had this dependency. So what happened was NPM basically republished it. They said that, even though you’re the original publisher—

    Paul: So there was a lot of outcry on the internet and then they republished it.

    Edith: Just basically said, “You don’t have the right to un-publish this.”

    Paul: Gotcha. So, um, but they had an Unpublish button, as I understand it. So he did something that was built into NPM to remove a module.

    Edith: Yeah, and since then they have tightened their rules a lot. They basically said that this should be something that’s used extremely rarely, if at all, and not something you can just do capriciously.

    Paul: So one thing that’s interesting about the NPM ecosystem, and the Node ecosystem in general, is they’ve had a bunch of things like this. Things that are security-related, or that are drama-related.

    And people have repeatedly come out and say, “Oh, no, JS is a tar pit, or ghetto,” or whatever it is that people use to describe poor ecosystems, that normal programmers don’t know how to code, and so on, so on.

    And what it looks to me like is, you know, each of these incidences brings the Node ecosystem quite a bit forward. To the point that, I mean Node is relatively new, it hasn’t had 15 years before prime time in the way that Ruby or Python did, or 20 years before it got big, and it’s a real, kind of bottom-up thing.

    I mean, if someone built it and there were some steroids and then someone else took over, and then NPM took over, and then. It’s this sort of weird language from the ecosystem perspective. It didn’t have the same advantages that, like, Java had, or that C or C++ had, in order to get to maturity. And so each of these incidences propels it closer to maturity.

    Edith: Yeah, I compare it somewhat to when electricity first started coming out. And then you were just working through all the issues that could happen. Like, for example, when a power line went down or a transformer blew.

    Like, you work through, Okay, what are our points of failure? Let’s not make that a point of failure again.

    Paul: Hmm. So, NPM changed their policies on this basis, right?

    Edith: Yep, so now you can’t have an individual contributor be able to unpublish, even if they originally published. Now you have to contact them, and it’s much more stringent.

    Paul: Gotcha. The response, despite people being … Well, people were annoyed at their response.

    Edith: It seems perfectly rational to me.

    Paul: Oh, I think it seems perfectly rational. This is the thing about the in trend. There’s always some set of people who are annoyed at everything you do.

    Edith: Well you know, the internet is full of billions of people. I mean, there’s gotta be some sort of standard deviation, or otherwise it would be a very boring internet.

    Paul: Right, right, and this is why there’s always haters on Hacker News. No matter what you do. If you do it one way, there’ll be one group of haters, if you do it another way, there’ll be a different group of haters.

    And so, with left-pad, there were people who were annoyed that NPM retroactively decided that they had ownership over their namespace, which previously, they had sort of gifted to people in the community, the first people to take the namespace.

    Edith: You mean the original thing about Kik?

    Paul: So there’s that, but there’s also the left-pad. They took away the sort of autonomy of the left-pad offer.

    Edith: I read a good article that basically says part of open source is, if it truly is open source, do you maintain the rights to it? Or is it a community project?

    Paul: Hmm. The traditional way of deciding that sort of ownership was the fork. That you could go, and you could fork, and when you forked, you weren’t necessarily entitled to the same name, you weren’t entitled to the same trademarks. When Debian forked Firefox, they called it Iceweasel.

    When Jenkins was forked, or Hudson was forked, it became Jenkins. GCC got forked. They all got new names. But what was the fork here, it wasn’t even a fork. It was a republish of the same thing, the same software, in a namespace that the original author didn’t control.

    So typically you’d own the URL, you know, if you have a software library, you’d own the URL. And they did own, in some sense, the URL within NPM, or the name within NPM’s space, and NPM, the sort of owners of that namespace, overrode it.

    Edith: I think they did what was necessary for good order.

    Paul: Sure. I completely agree, I think that was a good decision.

    Edith: I mean, so to take this to the logical conclusion, what if you had a module named left-pad, and you decided that, like, as a prank you were going rewrite it to be right-pad? Like, sure, that’s … Is that within your rights? Kind of, but it’s a real jerk thing to do that you probably want to prevent.

    Paul: This is kind of one of the dangers of the whole ecosystem around centralized package managers, of sorta trusted package managers, where there’s no actual trust involved. So, what I mean by that is what is published does not have any gatekeepers.

    Edith: Yeah, exactly.

    Paul: I mean, it’s great, it allows an ecosystem to grow much faster, but it has safety concerns because people generally don’t pin their packages to an exact version.

    Edith: You’re basically pinning it to a floating value.

    Paul: You’re pinning it to a floating value. And that floating value could change. There’s no guarantee of what a minor number means or what a major number means or what a patch number means or what a patch even means. There’s some sort of, like, general community guidelines in semantic versioning, but there’s no enforcement of that.

    Edith: Yeah, and I mean this basically goes back to the whole Cathedral versus Bazaar thing.

    Paul: Right, right. It’s very Bazaar. And intentionally so. It’s the thing that allows a community to grow, and is there a point at which open source communities need to, like, batten down the hatches to prevent that sort of behavior? Or prevent that sort of risk?

    Edith: Yeah, and it’s really interesting. I think this goes back to something we’ve talked about with Nadia Eghbal and Sean Byrnes a couple episodes ago about when you buy from a corporation, you have some sort of guarantee of standards that they publish somewhere. You know, this is our guarantees versus with open source, you don’t normally have those same sort of guarantees.

    Paul: Even when you do, it tends to be—

    Edith: There’s no enforcement mechanism.

    Paul: Right. So there’s no enforcement mechanism in the Bazaar.

    Edith: Well, there’s no, um … Like, so with a company, if a company has said, “Okay, we’re gonna release twice a year and it’s gonna have this level of quality,” and they break that, you can walk with your feet or your money. If an open source project stops or does something that you don’t like, there’s very little enforcement end.

    Paul: Theoretically, you could walk. You know, you could fork the thing, but when you end up in an ecosystem that has massive network effects, and in the way that NPM does, you can’t walk with it. Because the pends is all transitive. The left-pad was, you know, a turtle way at the bottom of the stack.

    Edith: It was almost like a turtle hatchling.

    Paul: So, to fork left-pad, you would have to fork the entire NPM ecosystem.

    Edith: Yeah, and it’s not even. The fork is not the issue, though. The issue was that people were depending on it being in a certain place in a certain way. It wasn’t that it wasn’t forked, it was just like this entire structure at the bottom was gone.

    Paul: I guess what I’m saying is that if you get pissed off with a certain set of developers or a certain set of practices within the NPM community, because they’re so interlinked, you don’t have the traditional open source option of forking.

    Edith: Absolutely. Absolutely.

    Paul: You could rename it. You could pick a different library, but because of the way—I’m not sure if they still do this, ’cause I read something about it, but in NPM, it used to be that the version of the software that your library took was the version that library got. Do you know what I mean by that, okay. So let’s say there’s some software, let’s call it left-pad.

    Edith: Let’s call it right-pad.

    Paul: Right-pad. So, right-pad version one is being used by library A. And right-pad version two is being used by library B. In the Java ecosystem, and many, many other ecosystems, only one version of right-pad would be used.

    And I believe in NPM, both versions of right-pad would be used. So library A will use version one, and library B will use version two. Now that’s definitely the way that it used to be, I’m not sure if they’ve actually changed that.

    Edith: Yeah, I don’t know, but that sounds very messy, very quickly.

    Paul: So both options are terrible. And there isn’t a right way to do it.

    So, really, what it depends on. So, the NPM way of doing it, every library get its own version of the dependencies, is fantastic. Because it lets that library do what it actually intended to do under the covers.

    If, however, you start having an object that gets sent around, or that two modules are, let’s say it receives a, I think, an HTTP packet or something like that would be a good example. Let’s say you take an HTTP packet from one module and just hand it to another module, and they have different understandings of the shape of that object, or what functions you can run on that object, then that’s messy.

    But, on the other hand, if you override the version of right-pad that some other library’s using, you end up with all sorts of problems. This is a major problem in the, sort of the Maven ecosystem. And at CircleCI, we used Clojure, and Clojure is built on top of the Maven ecosystem, and we would have bugs where the library that we used.

    One library that we used had a dependency, and that was in the package file for another thing. And so, that’s the version of the packets that we used. So we would have to pick. And as a result of that, we have to pick the library that works. And, often, there isn’t a library that works for both, or there isn’t a, sort of subdependency that worked for both. So those are close to forked no matter which way you do it.

    Edith: Yeah, I mean, we ran into the same issues with our STKs. I mean, ’cause we have dependencies on other libraries that sometimes conflict.

    Paul: Right, disaster.

    Edith: On the other hand, I mean, the bigger point, I think, was. So there was an interesting backlash, I think, that everybody kinda projected what they wanted on the NPM thing.

    People said, Oh, people don’t know how to program anymore. You know, why do you even use what they called left-pad? You know, why don’t you just grind your own wheat and make your own bread from scratch and eat it at lunch also?

    Paul: I have no sympathy at all for this view of the world.

    Edith: Uh, that you should make everything from scratch? Or—

    Paul: That, “Oh, we’ve forgotten how to program because we need left-pad.”

    Edith: Yeah. The fact that we have modules available that make it easier and easier and easier to program is a good thing.

    Paul: I think it’s kinda different to that. I think it’s more of a curmudgeon view of the world. It’s a get-off-my-lawn—

    Edith: Wait, that you’re the curmudgeon?

    Paul: No, the people who complain, “Have we forgotten to program anymore?” I think it’s a no true Scotsman kind of argument. Real programmers know how to write their own left-pad, real programmers write in statically typed languages, real programmers write in C, real programmers, and I’m going back in time here, real programmers write in Assembly, real programmers hand-code their. Tweak the needles on the.

    Edith: They do their own garbage collection.

    Paul: Oh, and it’s garbage collection, what is this? Garbage collection is for amateur coders, right? I mean, you could just as easily have written, have we forgotten how to manually allocate memory?

    Edith: Or, you might as well say, like, nobody knows how to make their own transistors anymore. I mean, like, the entire computing revolution has been that you no longer have to assemble a computer by hand.

    Paul: Right. And each layer of the ecosystem allows a vastly larger number of people to take part in it. So I think the thing that we’re seeing now. This has been happening for five or 10 years, but what’s getting really, really big now is people who only know how to front-type program.

    People who only know Javascript and HTML/CSS, and they go to boot camps and they come out, they maybe have some, like, vague real understanding.

    And they call themselves coders, and we, the real programmers, who know how to write a quick sort, and who know how to write left-pad, we don’t welcome them to our community. And frankly, I mean, I have felt this in the past, I have since changed my mind, but it’s a very, very common perspective.

    This podcast is brought to you by Heavybit, a program that helps startups turn products loved by developers into successful businesses. Throughout the program, founders work on developer traction, product market fit and customer development. If you like what you hear, be sure to subscribe to Heavybit’s Podcast Network on iTunes.

  • To Be Continuous Podcast: Open Source Economics

    To Be Continuous Podcast: Open Source Economics

    Welcome to To Be Continuous, a show about continuous delivery and software development, hosted by Heavybit members Paul Biggar, founder of CircleCI and Edith Harbaugh, CEO of LaunchDarkly.

    In this episode of To Be Continuous, Edith and Paul are joined by Sean Byrnes, CEO of Outlier.ai, and Nadia Eghbal. The group discusses open-source economics and examines several potential evolutions of adding money to the open-source equation.

    [soundcloud url=”https://api.soundcloud.com/tracks/257873002?secret_token=s-fHPo1″ params=”auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=false” width=”100%” height=”166″ iframe=”true” /]

     

    Edith: So, Nadia what do you like best about open source?

    Nadia: I like that open source is where I feel I spend time with a lot of creative people. It’s sort of like creative talent at its best. And it feeds directly back into the rest of startups and technology and everything else that I love.

    But it seems like everything starts with open source. Which makes it really magical.

    Edith: So Sean, what do you like best about open source?

    Sean: It’s the community. I enjoy learning from other people. I enjoy being able to find people I would never connect with that I have interests in common with. And a community that helps, because I consider open source to extend beyond just writing lines of code to sharing ideas, and sharing concepts and sharing solutions to problems, and while I might not always use those same solutions, I’m always inspired for new ways to solve other problems.

    Paul: So that’s super interesting, because nobody said that they like how it supports their Silicon Valley startup through sharecropping. Or … nobody said, I like how I get paid to work.

    Edith: Well, Paul, that comes later in the episode, but this would be a great time for our guests to introduce themselves.

    Nadia: I’m Nadia Eghbal. I’ve been writing recently and thinking a lot about how to support open source infrastructure.

    Originally, I have background in nonprofits and impact investing and working with foundations but most recently I was a founder of a startup and then I went into venture capital. And have sort of seen the system from all different sides and would love to marry together all those different interests and topics in which seems to happen in open source.

    Sean: Hey, I’m Sean Byrnes. I’ve been writing software most of my life. I’ve also been a founder of companies and an investor.  I would not consider myself an expert on open source and I don’t wanna claim that pedestal but I have, am, the maintainer of some open source libraries which seem to be pretty popular and I have contributed to others and I think that I’ve been lucky enough to know a lot of open source developers in my life which is, by no means, a majority of them but enough that I feel part of the community, at least.

    Paul: So, one of the topics that we were discussing just before the show started, is this idea of how open source developers get paid. Or, if open source developers should get paid.

    Nadia, sounds like you’ve been talking about this for a while or thinking about this for a while. Can you kick us off?

    Nadia: Yeah, actually, have a new thought on this topic from Michael Rogers whose, who runs Node.js Foundation. And he said recently, I think, on the last post I had written that everybody gets paid for open source. And I think that’s a really great way to start thinking about it vs. saying that nobody gets paid. Because in the end we’re contributing time to open source, right and in the end, somebody is paying you to have the time to work on open source.

    Whether it’s your employer and then you can work on open source full-time at your job. Or you’re full-time employed and that gives you the bandwidth to be able to work on open source on the weekends or whatever.

    So when I think about paying people to work on open source, I think people sort of like, bristle at the idea because they think that money is not involved in open source at all. And what I really liked about Michael’s point is that, in the end, money is actually really closely tied to open source and we’re just not talking about it.

    Sean: I get it. It’s interesting because my point of view is that it’s actually more nuanced, I agree with you 100 percent but I think that it’s very nuanced and that a lot of people do get paid for open source, it’s not even that we aspire to wanting them to get paid, right. ‘Cause there’s lots of kinds of open source. It’s funny ’cause on Medium, Nadia and I had an exchange.

    I kind of quantified it into the four categories of open source the way I see them. Which is by no means the universal standard but at least, how I see the world there, there are places where open source is part of your, a corporate product. It’s part of a whole.

    Like, LaunchDarkly. Edith’s company, has open source SDKs. It’s not because they’re doing anything grand, it reduced their sales friction if their customers can see the code before they integrate it into their app, right. So that’s one kind of open source.

    A second is what I call corporate open source, where there’s an open source project but there’s a company that sells services and products and stuff around it, right. So Confluence does that for Kafka. And Databricks does that for Spark. And MySQL was, I think, one of the first companies to really make a good model out of it. Red Hat, you could argue, had mixed success but that’s another kind where there’s a company whose corporate goal and sales is towards this project.

    There’s the third kind which I call, kinda like corporate marketing, which is you take a project out of a company and you roll it out like LinkedIn did with Kafka, where they’re actually, the company’s maintaining it they just make it available. So Google, the Angular and Facebook work react. And again there, I think, that it’s. You could argue why companies do this, some of ’em do it for recruiting, some of ’em do it for marketing. Some of ’em do it for because they’re very nice people.

    I think that the fourth category is where it’s a little bit weirder, where it’s like, what I call the community where somebody started a project. Maybe it’s an individual, maybe a few people, to solve a problem. And a lot of the most important open source products today started that way. Even Linux started that way, right. And it grew, and it got bigger, and eventually, then it became unclear because other people were using that project to build other companies and build other products, and make more money.

    And I think in that fourth category is where I think it’s less, because the first three categories is usually pretty clear who’s getting paid to do what and where the money’s coming from, but in the fourth category it gets very muddied and very quickly. Because if I start something, and the metaphor I like to use is, the open source library that I wrote was something called Likely.js which is a recommend ender system for no JS where you can, like Amazon product recommendations. And I know that there are people in the world that are using that as part of companies. And those companies are obviously making money because it to recommend products, right. And so, the question is, you know, so in that world, do they owe me anything for creating that which is underlying their products? And then, in turn, what do I owe the projects that I build Likely on top of? And then where does the flow of economics in that world go?

    Paul: So I have an interesting view on that. Years ago, I got involved in this project called PHC, which is a compiler for PHP. And there was a couple of guys who had start this and I joined a year later. And when they started it, they made it GPL. When I joined, I argued, we should change from being GPL to BSD because if someone comes along and uses that technology to build something that’s cool, I would rather that happen than not now happen and it might be that if was GPL that it wouldn’t happen. And so that, essentially, in sort of the kinda related to Likely.js you decided by the license.

    Whether or not you were going to make it publicly available or if you didn’t want people to build business on it, you could’ve made it GPL or AGPL or something along those lines and you could’ve restricted it in any way that you wanted and you chose not to. And there’s something implicit in that, that communicates to people who are building their companies on it, etc., as to what your intent was.

    Sean: No, that’s true. Although there’s a nuance in there which is that, even the GPL suffers from this, what Richard Solomon still complains about today which is, you could still use Likely.js on a server.

    Paul: Right, right, right. Well, so AGPL would work around that.

    Sean: Sure, and there’s other licenses that I could choose, but the majority of licenses out there today but even then, let me argue counter side, not because I agree with it just because, hey, let’s argue because—why not! You know, as an individual developer, I don’t have the time resources to go pursue people. I’m not gonna go sue somebody. Really? No, come on, like it’s not gonna happen. So, I think, you’re right only in the act of releasing it as open source on GitHub. I was making a decision that it’s possible for people to use this in ways that may, either A, I don’t intend, they could’ve used on Silk Road to recommend drugs for all I know, seriously, right.

    Or, to make money on it in ways that I am not gonna benefit from. And I made that decision knowing full well the impact of that. And I would actually argue most developers do that. The question is whether or not there’s remorse later on when it turns out, wait, I really wish I hadn’t made that decision, I can go back in time.

    Paul: Well, I think this is a common thing that people create a thing and then they say, well, if this is popular, I could sort of keep it or I could, there’s value here. I could keep it to myself or I could keep the value to myself. Or try to profit from it in some way. But they make, what is essentially, a marketing decision. I’m just gonna release this, I’m gonna see what happens to it. I’m gonna see if it spreads and then if it spreads, I can then make a decision as to, as to what, how possibly I can make money out of this. Or I can get value out of this. But at that point, obviously, the cat is out of the bag in terms of people actually using the software.

    Nadia: Yeah, I mean, I think it’s actually should start from the principle, like you said, of it’s really great when people, you give something away and then people can use for whatever they want. Whether it’s for a hobby project. Whether it’s for illegal drugs or whatever, you know. Businesses, whatever, that’s like, kinda one of the coolest things about open source is that you can use it for whatever you want and that’s kinda what you signed up for right.

    If you didn’t wanna do that, then don’t license it that way. I don’t know, I wouldn’t frame, at least the problems that I’m seeing and that I’m interested in, is not really about seller’s remorse, I guess of, “Oh, I made this thing and now it’s really popular and how can I make money off of it.”

    But I think it’s more really about investing back into the infrastructure that we’re all using and that requires some sort of maintenance and upkeep. And that’s why I like the term infrastructure and I’m trying to use it in that sense of things that don’t have a business model or business attached to it. Like you, literally, could not charge for Python. It’s just not gonna happen. Or the packaging associated with it or whatever, but still like millions of people are using it. It’s touched billions of people. And you literally have like one person working on a library or a project, that doesn’t seem, that seems like it’s in everyone’s best interest to make sure that it works properly.

    Edith: Well I think Nadia made a really good point that a lot of the fun of creation is the creation. And the hard work is all the maintenance and the support and the documentation after. So like, Sean, you basically got the fun.

    Sean: Oh, totally. Well I mean, if you even think back to the original “The Cathedral and the Bazaar” essay from years ago, that was one of the fundamental topics of, you know Eric was inheriting, I think it was called Pop Mail from somebody else.

    He had gotten tired of maintaining it and so he wanted somebody to take it over and he found Eric and Eric took it over. I mean, that’s, you know, I think, yes, as engineers we like creating and we like creating things in our free time and we don’t like maintaining them as much and maintenance feels more like work.

    And so, I agree with Nadia’s point that if everybody is driving economic value from it somebody has to be willing to step forward to support it. I think the problem is that I also, it’s funny that you have a background in nonprofits because I also have worked for nonprofits and I see the similar lament in nonprofit companies.

    Which is that—not nonprofit companies, nonprofit organizations, where the person who starts it usually really wants to solve this problem, they’re usually really good at that. They’re not good at the fundraising

    And in this case, the nonprofits, it’s like raising grant money or getting donations. But they have a good mission and they have a good organization to go do it. And they have this lament which is why can they not get more support to solve the problem they see in the way that they wanna solve it.

    And I see the same around maintainers of open source projects and I think the challenge is going to be that I wonder if it is even possible for the general economy to support them, to do what they wanna do, the way they wanna do it. Or if they are gonna have to start doing it the way the general—

    Paul: Right, because they have other options. They could start a consulting company. Get hired by a category two company or something like that. To build around it and support themselves that way and then their job doesn’t, then their job isn’t what they wanted their job to be which is making cool software. Their job is, you know, doing maintenance contracts for a big soul-less enterprise.

    Edith: You say that like it’s, I mean, soul-less enterprises, I mean …

    Paul: I’m a big fan of soul-less enterprises. But I’m just looking to sort of put the—

    Sean: They have a lot of money. We have to sell them.

    Paul: And if any soul-less enterprise would like to buy CircleCI they should contact me for enterprise pricing.

    Sean: Just mention the code OSS for 10 percent more.

    Edith: And by the way, thank you for wearing your LaunchDarkly t-shirt today, Paul.

    Paul: Always. So, Nadia and Sean had this conversation on Twitter a week ago which led to them being on the show. And one of the Tweets that got involved was from a Jacobian who’s one of the senior Python kind of people. And what he said is, OSS developers deserve to be paid. SV, Silicon Valley, has made massive profits by exploiting free labor. This needs to end.

    And I think that there is this, this feeling in open source by, at least by a lot of people who end up on the maintenance side of things that, there is a sort of a sharecropping going on here. And that’s something needs to happen about that.

    Edith: I think Nadia actually put this extremely well in the essay; like cool, I wish I had written that essay, it was brilliant.

    Nadia: Aww.

    Edith: But just like, what’s really fed this is the explosion of GitHub and it’s really easy now to start an open source project.

    Nadia: Yeah, I feel like right now is just a time when we’re so used to thinking of open source in a certain way and things have kind of gone along as they have for so long that we haven’t necessarily noticed or taken a step back that the past five years look completely different than the past 30 years. And stuff is just not the same anymore. And in part, I think it should be framed as a really good thing because it means that open source kind of won, in a way.

    Companies want things to be open source. They wanna learn how to open source their own projects. They wanna understand the whole thing. Everybody is defaulting to open source and that’s a really positive thing and the question is more of, not like, oh, we’re exploiting people and that really sucks but how can we help support that underlying layer that has helped make everything so great. It obviously needs some sort of reinvestment back into it.

    Edith: Yeah, I mean, one of the most fascinating thing about “The Cathedral and the Bazaar,” which was written 30 years ago, is that they referred to Linus Torvalds as this charming guy. Yeah, I know, and you’re like wow, here’s this charming, personable guy who like persuaded people through sheer force of will to work on his project.

    Sean: Yeah.

    Edith: I mean, to go back to Sean’s example about a nonprofit and everybody in the studio right now is like, whoa, that’s not …

    Nadia: Not at all.

    Edith: By anybody’s perception now, and I don’t know whether that’s just the grind down of having to keep maintaining a project or …

    Sean: First, I’d like to thank, I don’t know if his name is actually Jacobian, whatever it is, thank him for his service and work on Python ’cause I think, no matter what we agree on here, we can all agree that the people doing this are doing a service for the general community.

    Nadia: Definitely.

    For more on Continuous Delivery and to hear other Heavybit podcasts, copy this link into your favorite podcast player. We’ll have show-specific RSS and iTunes subscription options soon. You can also follow To Be Continuous on Twitter at @continuouscast.