Robert and I jump on the podcast to have a little chat about open source generally and what we do with open source at CodePen. CodePen itself is not open source, aside from the small bits we’ve made public and the open-source things we include within it. But all Public Pens on CodePen are open source, so we certainly handle a lot of it! Enough that I felt comfortable making our Mastodon presence on Fosstodon, which is an open-source-focused instance.
Time Jumps
Sponsor: Split
This podcast is powered by Split. The Feature Management & Experimentation Platform that reimagines software delivery. By attaching insightful data to feature flags, Split frees you to quickly deploy, measure, and learn the impact of every feature you release. So you can safely deliver features up to 50 times faster and exhale. What a Release.
Start raising feature flags (and lowering stress). Visit Split.io/CodePen for a free trial.
Transcript
[Radio channel adjustment]
Announcer: Today, on CodePen Radio.
Chris Coyier: Hey, everybody. CodePen Radio #396. I have Robert with me this week. What's up, Robert?
Robert Kieffer: Oh, not much. Just good to be back on the podcast.
Chris: Yeah. Good. You're literally about three feet away from me with a soundproof wall between us.
Robert: Yeah.
Chris: It's all too rare that we do.
Robert: The booth.
Chris: We're both in Bend at CodePen world headquarters. Ah... just kidding. We don't actually have a world headquarters. As we learned last week, we're an all-remote company. We just so happen to live in the same town, so we have a nice office together.
Robert: Yeah, I get to crash at your office every once in a while. It's nice.
Chris: Yeah!
Robert: It gets me out of the house.
Chris: Heck yeah. Right downtown in beautiful Bend, Oregon.
So, our plan was to talk about open source because it affects CodePen. It affects every company ever, let's say. [Laughter] Just a vitally important topic.
Robert: It's definitely something that benefits every company out there, and small companies in particular. It's something that's been near and dear to my heart for a while. Yeah, this will be fun.
Chris: Yeah. I think the way that you interface with open-source is a little more - I don't know - raw and direct than anybody else at CodePen because you have libraries that you work on and maintain. You've just been involved with it and have kind of a natural inclination towards - I don't know - dealing with it or fixing problems that we have that way. [Laughter]
Robert: Yeah, well, also I've been around long enough that I've gotten to see the arch of the open-source community really develop. I've been coding since the '80s when open source wasn't really a thing. And so, seeing how it's just evolved, become this just foundational piece of the entire software world, is pretty cool.
I know what it's like to not have an open-source community, so I definitely appreciate where we are today. And I really do like that, just that sense of the value that it brings, and being able to give back. It's pretty nice.
Chris: Yeah. I mean there are grandiose things we could say. It has bettered mankind to have the open-source community. It's a really, super-duper big deal. You know? It's about as big of a deal as the Internet itself, really.
Robert: Yes.
Chris: There's also grandiose controversy with it that I don't know that we'll be able to breach in this podcast. There are problems with it that are so big that they're hard to talk about. They deserve world-class journalism to get into them, like who are the people who do this. Are they living their best life? Are they getting what they deserve out of this ecosystem? How do you monetize it? That kind of thing because there are problems with all that. I'm not sure we're ready to do that.
Robert: Security in the NPM ecosystem.
Chris: Yeah, right.
Robert: Have fun with that. [Laughter]
Chris: Uh-huh. We're going to solve it in the next 25 minutes.
Robert: Yeah. No problem. I don't know what's taking them so long.
Chris: But let's talk about... Maybe we can scope it down to smaller things like examples of CodePen plus open source. I would think it's no surprise to most people listening to this that all of CodePen, for example, is not open source. We have open-sourced kind of precious little throughout our career.
You said to me before the show, briefly, that that's not terribly rare, especially for really small companies. It's almost like calculus you have to perform internally. There's a cost to doing open-source, and a lot of really small companies just choose not to pay it because of the very real costs involved.
Robert: Yeah, especially for small companies, but even large companies. I think companies that really make substantive contributions to open-source are much more the rarity than the norm at any level, but especially for small businesses where, like I was saying, it takes a certain amount of effort to interact and contribute to open-source. If you're a small company, that fraction is a relatively large proportion of your workday. Whereas if you have a large company, you can afford to have a few people that sort of disappear off into the weeds of open-source projects every so often.
Chris: Mm-hmm.
Robert: But small companies, that gets noticeable quick.
Chris: Right. Right, right. There's an example here and there. I remember. I think we have... It's probably still there now. I'm not sure how relevant it is anymore, but some of the things that we've chosen to open-source have been really super-hyper niche, too.
For example, one of the things that's just parentally an issue with user-generated code websites is, "Well, what if that user writes code that freezes the browser?" It's just painfully easy to write an infinite loop in JavaScript.
Robert: Mm-hmm.
Chris: If you accidentally do that on CodePen, it can freeze the browser to the point where you can't even save the work that you were working on because, literally, the browser tab is dead.
[Laughter] We knew that was a problem when we started CodePen, and we've solved it a whole bunch of different ways and benefited from other people's open-source solutions. At one point we were like, "Yeah, we think we have a pretty good solution that works for us," and open sourced it.
But guess how many stars that has on GitHub. Like two. [Laughter]
Robert: Right. Right. Open source is that code that exists at the intersection of problems you have and problems that everybody else has.
Chris: Yeah. Yeah.
Robert: How many people actually have that problem of, like, "I want to run code from somebody else, and I don't want to deal with infinite loops"?
Chris: Right. There's not very many companies. And the companies that do it might have their own internal solutions, as we often do.
Robert: Yeah. These days, it's actually hard to come up with ideas for open-source projects that haven't already been done because there is such a huge community. The projects that I deal with, the big ones are UUID and the mind-type modules and NPM. I mostly got into that because I was sort of there on the ground floor of Node and NPM back in the day, and somebody had to write those. I just happened to be there.
Chris: Yeah, right. We could get into those a little more, but I thought we could talk about some recent. These are pretty micro-examples, but I think they're probably reflective of real-world, small company interacting with open-source community type of situations.
One of the points of using CodePen is using different processors that process your code. Meaning that if you want to write some Less.js really quickly, you don't have to make a folder locally and download the NPM dependencies and set up a watcher to build your stuff. Sometimes you just want to write some of that code and see the results, and a lot of people use CodePen for that. Thank you for doing so, by the way.
Now, when we receive that code, we need to process it. And there are enough bad people in the world that they know that that's the case, that they can write code and that a CodePen server will execute it. So, what can they do to misbehave? Can they get that thing to mine Bitcoin or whatever? [Laughter]
Robert: Right. One of the problems that Less has is that it supports an import statement where you can actually point it at a random file and it will execute that for you on CodePen servers. Prior to my arrival, I think Stephen had created a fork of Less, the library, and gone in and been like, "Well, we're going to disable the ability to have import statements."
And so, when I came in and was like, "Oh, I've got rewrite processors," and specifically the Less processor for this new project we've got going.
Chris: Mm-hmm.
Robert: I was looking at that, and the Less project, there were other people that had kind of said, like, "Hey, it'd be really nice if we could do this because we also want to be able to run Less without having to worry about unsecure or malicious code doing bad things to our servers."
Yeah, so I kind of jumped on that and was like, "Well, here's kind of what we did with our solution," and I massaged it a little bit so that it had a proper command line option that you could run from the command line. There was a field for an API. And put that up as a PR.
Chris: Because it's kind of like you want to pass a true-false value, right? It's not like you're saying, "Please remove this from your open-source library." I just want to, through the config, say, "Yeah, process it without that feature."
Robert: Yeah. The directive is like, "Ignore import directives," or something. I don't remember.
Chris: Yeah. Right.
Robert: It's some flag like that, but yeah. There were sort of two reasons for that.
One is it helps other people that have the same issue. That particular issue had been up for a while. I think Stephen may have actually created it initially, and so it was like a year or so old and had some conversation.
I was like, "Well, let's see if we can solve this problem." And you go back and forth with the maintainers, and you start that conversation with, like, "Hey, I'd like to fix this problem. Is that something you'd be amenable to? Would you be willing to take a PR on this?"
In this case, I think they were receptive to that idea, and so ultimately, that is now a thing on the main Less codebase. It's out there. it's been published. You can now use this flag, which is great because we no longer have to maintain our fork. And that's huge.
Chris: Yeah, that's huge because our fork was a monkey patch, too. It's not like we could use the canonical Less and then apply some kind of file-based patch to it or something. It was not that. We had to go into the internals and change code. That means you're forever going to be reapplying that patch to their updated one, and that sucks. You want to use the canonical thing if you can.
Robert: Yeah. Somebody will eventually get around to looking at our version of that fork and be like, "Oh, yeah. We're like 37 commits behind the main fork."
Chris: Oh, yeah. Tell me about it.
Robert: "Gee, I wonder if there's useful stuff in there that we want." You know? Yeah, forks are useful but also they are a real burden.
[Guitar music starts]
Chris: This podcast is brought to you by Split, the feature management experimentation platform. What if a release was exactly how it sounds, a moment of relief? Ah... An escape from slow, painful deployments that hold back product engineers.
Free for teams and your features with Split by attaching insightful data to feature flags. Split helps you quickly deploy, measure, and learn the impact of every feature you release, which means you can turn up what works, turn off what doesn't, and give software innovation the room to run wild.
Now you can safely deliver up to 50 times faster and exhale. Split feature management and experimentation, what a release. Reimagine software delivery. Start your free trial and create your first feature flag at split.io/codepen. Thanks so much for the support.
[Guitar music ends]
Chris: There's a difference in - I don't know - attitude and effort and stuff there that's interesting to me that - I don't know - I should think about harder. Whereas I'm like, "Okay, I have some problem," or I have some idea or something for an open-source library.
It's one thing to open the issue and just say... You could even do a great job with the issue. You could explain exactly what you want to do. You explain what you've tried. You could explain an imagined situation that would solve your problem. You can do a great job with that.
But no matter what you do, it kind of, in a way, pales in comparison to the PR. You can explain all that stuff and then say, [laughter] "Here's an alteration to your code that you can directly look at that would solve this." That's just such a big deal. It's like night and day.
Robert: Yeah. Well, as a project maintainer, there's sort of a hierarchy of contributions in terms of the value. The first thing is the report of somebody saying, like, "Hey. I'm getting this error message," and that's what a lot of people get.
It's like, "Oh, okay." I can't really do much with that other than sort of nod my head and agree in sympathy.
Then you get people that submit issues that have actual substantive examples of how to reproduce the issues. It's like, "Okay. This actually gives me something I can dig into."
Then the next step up, which is pretty high on the hierarchy of value, are the people that are willing to put PRs together who are like, "Okay. I've taken the time to understand what your project does and try to add value." Those are great because you have actual code you can look at.
Normally, you'll have test cases or at least examples of, like, here's the code and here's how it actually transforms the behavior of the project. And those are really nice.
I love getting that for the projects I'm on, but they're also really rare. Very few people actually take the time to do that sort of thing.
Chris: Right. Yeah, good points. The fact that the issue was already described.
We also had, in a way, permission to do the PR, which is kind of nice, too.
Robert: Mm-hmm.
Chris: It's kind of nice to ask that ahead of time. I almost wish there was a better social convention for that, some kind of verb or term or something that says, "Are you amenable to PRs or not?" Bullion answer.
Robert: Yeah. I mean the open-source community, it is the entire cross-section of the developer world. I imagine going to some ComiCon somewhere where you're dealing with every character imaginable.
Chris: [Laughter] Truly. Right?
Robert: [Laughter] You know?
Chris: How grumpy are you? [Laughter]
Robert: Right. It applies to both maintainers and contributors and the poor suckers at the end of the line that just want to use the fricken' code and not have to deal with the people involved.
Chris: Yeah.
Robert: That's one thing that we could probably go down a whole path there about the ethos and etiquette of open source. I think Alex did come across a project the other day where the maintainer had just kind of clearly had it and was like, [laughter] "Look. I'm done with dealing wit you guys," and he archived the project.
Chris: You found the exact moment where--
Robert: [Laughter] Yeah.
Chris: --he ranted about somebody because probably somebody asked him something probably a little unfair. In the screenshot, we didn't see what he was asked, but [laughter] he was like, "Oh... Hold on, muchacho. You come here and ask me for this code?!" You know he was clearly--
Robert: Yeah. Somebody had asked him to commit to a date by which he would fix some issue that had been a bug for six months.
Chris: Oh...
Robert: And the guy was like, [laughter] -- basically like, "This is open-source, dude. I don't do schedules." [Laughter]
Chris: Yeah. Then that was the first response. He's like, "I'm not doing this." And then three days later he's like, "This entire project is canceled." [Laughter]
Robert: Yeah.
[Laughter]
Robert: My heart just went out to that guy. I felt so bad. I was like, "Dude, I have been there."
Chris: Mm-hmm.
Robert: Yeah. As a contributor, I try to be very respectful of that. As a maintainer, I will admit; the little devil on my shoulder definitely lets me unleash at times.
Chris: I was at a hotel last week, and there were some problems with the hotel room and some various things. You're almost trained as a person to be like, if there's a problem, then you get on the phone or you go down to the front desk and say, "Hey, this hotel room, the water doesn't get hot. There's something wrong with this thing. When is this going to be fixed?"
That almost translates into an open-source library, and you're like, "Hey, there's a problem with this code. When is it going to be fixed?" [Laughter] But that dynamic does not map well.
Robert: Yeah. The hotel analogy does not work in the open-source world.
Chris: No.
Robert: Open source is more like you go into the alley behind the hotel. If you're looking for a place to stay, well, there's a dumpster that happens to be there.
Chris: [Laughter]
Robert: Somebody politely put it out for you.
Chris: Right.
Robert: But you don't get to complain about what's in the bottom of that dumpster.
Chris: Yeah, exactly. It doesn't. But still, your brain probably has trouble with that sometimes, or some people's does.
Chris: Another example is, we're sitting around the office here and we're watching the Apple Keynote/Next 13 announcement. That was just a dumb joke.
Robert: Yeah.
Chris: It was a very, very put together, fancy kind of watch the stream of this event thing where they were releasing the next version of Next, which is by Vercel and, by all accounts, are doing very well. It was a cool release. Good for them.
It was like, okay, in the new thing there's a new folder in the Next world where instead of calling them pages, it's called app - or something like that.
Robert: Right.
Chris: I don't recall right now.
Robert: Right.
Chris: If you put your stuff in app, you've kind of got to say, "Is this - I don't know - a server-side component or not?" It's like a new directive.
Robert: Right. Next 13 is much more deliberate about, like, "We're going to try and render stuff on the server by default." Then magic happens, right? I have no idea what the hell they do.
Chris: Yeah.
Robert: There is this distinction between server-side rendering and client-side rendering. Next 13 is like, "Well, we're going to render stuff on the server if at all possible, but you've got to tell us if you want it to be rendered on the client," like if you're doing some fetch in the client and you can't render on the server.
Chris: Yeah. Yep.
Robert: You've got to tell us, and the way you do that--
Chris: Well, tell us, that's the clutch part, right?
Robert: Right. Right.
Chris: Well, how do you do tell them, Robert?
Robert: Right. [Laughter] Thank you, Chris.
You tell them by putting a little directive at the top of your component file that's literally in quotes "use client" in much of the same way you would do "use strict" (for people that are familiar with that).
Chris: Yeah.
Robert: There's a new directive there that you can put at the top of your file.
Chris: It's awfully weird to just see a string sitting there at the top of the file, but it is valid JavaScript.
Robert: Right.
Chris: So, whatever. You know?
Robert: Right. And there's even precedent for it.
Chris: Yeah, there's precedent.
Robert: There is a "use strict" directive. But if you happen to use a prettier and you want your imports ordered properly, there's a plugin called Prettier Import Order, or Import Sorter, or something like that.
Chris: Yeah, which I give a ten out of ten, and I fricken' love it. I hate it when imports are just random because then you're constantly looking at PRs where people just moved around imports. It's totally irrelevant. Anyway, it's a wonderful little plugin that I'm glad exists.
Robert: Right, and we use it because... Well, we use it because it lets us be specific about, like, how we want things ordered. Do we want local imports to appear below external? Anyway--
Chris: Yeah, exactly.
Robert: It's very configurable, which is great. The problem was if you happen to be running that and you put "use client" at the top of your file, it will automatically drop it below all your imports and wrap it in parenthesis for reasons I don't quite understand, which completely disables that functionality. Ordering your imports would break your Next.js 13 client-side component. I happen to run into this because I was the first one at CodePen (in engineering here) to actually be like, "Ah, I'll build something with Next.js 13."
Chris: Yep.
Robert: I ran into this, and it was like, "Oh, crap! I have to be really careful about when I touch this file to not hit Command-S," which is what triggers the Prettier plugin, and let VS Code just sort of quietly auto-save in the background. That got super annoying super quick.
Chris: Yeah. There is a command. I think, once you bring up the command pile, you can say, "Save without formatting," that at least you can do it on demand. But still, that's obnoxious, but it reminds me of just how rippling the open-source community can be.
I don't blame Next.js for this choice that they made, but they did make it, and it's a relatively weird syntax, even though there is precedent for it. Fair enough. But now who knows what other problems that cause. It's got to kind of do its thing throughout the community.
Robert: Right.
Chris: It's just funny. Then who is left to mop that up? Well, I don't know. Some dude in Bend, Oregon, apparently.
Robert: Yeah, so I ran into it, and I was like, "Well, let me see what's going on here." Eventually, it led to an issue on the Prettier plugin, Prettier Import Sort plugin - whatever it was.
I was like, "Well..." and there were like 15 people who had already sort of liked or commented on that, and it had been there for a couple of months since Next 13 came out. I was like, "Well, somebody has got to solve this," so I sort of dug into it.
Chris: Mm-hmm.
Robert: And ended up putting up a PR. In the 10 days between when I put the PR up and it actually ended up getting merged, 15 people had hearted it. It was nice. I got to actually feel like I was solving problems not just for me and not just for CodePen, but for a much broader cross-section of the community.
I don't know. That to me is one of the reasons why I code. I enjoy. I get a visceral sort of reward for doing stuff like that.
Chris: Well, I'm glad you brought that up because maybe that's... I mean not even maybe. That must be part of the fuel of open source anyway.
It's so easy to point at all the downsides and the pain and the grumpiness and the lack of monetization and all that stuff. You're like, "Holy cow! There's so much wrong with this!" And yet, here it is existing. Why?
And the why is because it's almost like a dopamine hit for nerds. "I did it!"
Robert: For me the value that comes in to me from open source is that when I run into a problem, these days I can drill down into it, and I can go all the way. I can go all the way down, all the way through the dependency chain to the very bottom of the code base, be it some C++ file - or whatever - in the bowels of Node.
I can be like, "Okay, I have access to the entire stack I'm sitting on, and I have the ability to fix it. That's not something that used to exist.
Back in the '80s, pre-open source being ubiquitous, you would get into your stack, you'd drill down, and you'd run into a giant brick wall that Microsoft or Apple or somebody had put up on their operating system or whatever technology you were sitting on top of. And so, I'm profoundly grateful for that.
I have sort of this self-fulfilling destiny now. If I have a problem, I have the ability to solve it, and I didn't used to have that. That was intensely frustrating.
Chris: Mm-hmm. Mm-hmm.
Robert: Sorry I went off on a bit of a tangent there.
Chris: No, I like it. I like it.
Robert: That for me is where that sort of energy and drive to engage with open source really comes from is that appreciation for being able to do my own thing. It's pretty cool.
Chris: So much of it... So much of what we've talked about so far is relatively centered around GitHub and GitHub existing, so that's interesting. Although, that was kind of a lead-up to say that not all of it, though. There are ways to kind of talk about and influence open source outside of it, and I'm specifically talking about a moment that it didn't quite lead to any PRs or any open tickets or anything, but so many companies now have a Discord where you pop into it.
I've been members of at least half a dozen of them where I kind of what to see what the community is talking about and how they're handling problems and stuff. That came up recently-ish with us, right?
Robert: Yeah, I mean that's actually a good point because we are seeing sort of the maturation -- I'm not sure that's a word -- the growth of open-source not just in adoption but also the depth of support you have. These days, especially for larger projects, it's pretty common to have an online community that's just right there, that's willing to help out.
For us, we use Cloudflare, and we've been working with the watcher. Sorry, not the watcher. Durable objects.
I had a question about durable objects a while back, which was, "What's the lifecycle of the object?" Cloudflare is really great at saying, "Here's how you create a durable object," but there wasn't much about, "Hey, when does this go away?"
Chris: Yeah. [Laughter] Yeah.
Robert: I think we alluded to that on the durable object podcast a while back, but I ended up kind of getting an answer, or at least a good an answer as I was going to get by going online to the Discord community that Cloudflare hosts. There are hundreds of people in there, including engineers from Cloudflare, and it's all just built into their Wrangler project and the durable object community that they're building around their open-source offerings there.
Chris: Yeah. Pretty cool. Like I said, it's not like we were opening tickets or anything. But you almost accomplish the same kind of thing. You can get an idea seeded into the minds of the people that build this thing that is ultimately open source. You know?
Like, "Oh, look! People are actually asking about this. Maybe we should build it." You know?
Robert: We talked earlier about if you want to submit a PR asking, "Are you going to be receptive to this?" is sort of polite, but having an entire community that you can go to, and I think they actually have a features and ideas subchannel in Discord where you can just throw ideas out there of, like, "Hey, is this something that the engineering team behind Wrangler or durable objects or workers - or whatever - would be receptive to?"
You can sort of take the temperature of the community as a whole to those ideas. That's a tremendous form of feedback for somebody who might be interested in participating in these communities.
Chris: Yeah. It's just interesting, and I think it draws some people because there's a little bit of a real-time nature to it that you're like... Sometimes you're in a hurry when you have a bug.
Robert: Yeah.
Chris: There's some chance that if you use the Discord model that you're helped quicker than you might be if you just post something on a forum or on GitHub or whatever. It's not always true. [Laughter] You might hear back eight hours later, but I'm sure that helps them get a little adoption.
Robert: Yeah, or eight months. [Laughter]
Chris: Yeah. [Laughter]
Robert: If it's one of my projects. [Laughter] I will confess; I'm not super good at responding in a timely manner.
Chris: Yeah.
Robert: Those of you that have run into my projects, I'm sorry. [Laughter]
Chris: Yeah. All good. Well, this has been a very interesting conversation. I wanted to talk about things not too broadly because, like I say, [laughter] it's hard to breach the topic of open source generally. It's more interesting to talk about little specific things as examples. I think we did that.
Robert: Yeah. All right.
Chris: Yeah. Rock-n-roll. We'll get you back again. We have some other topics we are scoping out, so look forward to hearing Robert probably one more time before our break.
I don't think I've mentioned it on the show, but obviously, we're really close to 400. We're going to get up to 400 and then just take a little tiny break for this show while we finish up ... project.
Robert: I want podcast 404. I want that number.
Chris: Oh, yeah.
Robert: [Laughter]
Chris: Oh, man. Or maybe it just goes up to 403 and then--
Robert: It'll just be dead air. It'll be a half-hour of silence.
Chris: Yeah.
[Laughter]
Robert: Robert Not Found. [Laughter]
Chris: Oh... We are just the perfect company to do that, I think.
Robert: Yeah.
Chris: All right. We'll talk to you later. See ya.
Robert: All right. Take care, man.
[Radio channel adjustment]