The Ups and Downs of Open-source Software, with Ken Wheeler

In this episode of the Versioning Show, Tim and David are joined by Ken Wheeler, a Formidable JavaScript programmer well known for open-source projects like Slick Carousel. They discuss the ups and downs of creating and maintaining open-source software, balancing open-source and commercial work, the challenges of fatherhood, and making rap music.

Show Notes

• Ken on Twitter
• Ken on GitHub
• Formidable
• Ken on SoundCloud
• Slick Carousel
• Flux
• React Native
• Electrode
• ESLint
• Walmart lint configs
• Builder
• Redux
• Dan Abramov
• Gatsby
• Spectacle
• React-blessed
• ngrok
• scotch.io
• More Twitter links: @mdavidgreen | @tevko | @versioningshow | @sitepointdotcom

Conversation Highlights

One thing worth mentioning is, keep the APIs small … a lot of people are going to come at you with requests for options, different options and capabilities and things like that, based upon edge cases. And then catering to each one isn’t going to do anything good. If you catered to every single edge case, if you add every single option that’s proposed in the interest of being a cool guy who is doing it, no. Because what’s going to happen is now you have this big, bloated library of different Band-Aids for different edge cases, and you’ve gotten away from the original vision of something that is just this small rock-solid set of APIs for the 90% use case. Don’t let that happen to your project — please!

---

See this TV behind me right here? There’s a Raspberry Pi hooked up to that. I suffer from open-source guilt. I have deep, deep open-source guilt, so I want to do a better job of being a maintainer. So I decided that I wanted to have it in my face all day long, every issue of anything like that. So I have the Raspberry Pi there.

---

Don’t just pull repos down … where there’s thousands of people depending on it. That is not a subtweet to any particular thing; I’m just saying!

Transcript

Tim:

Hey, what’s up, everybody, this is Tim Evko …

David:

… and this is M. David Green. And you’re listening to episode seven of the Versioning Show. This is a place where we get together to discuss the industry of the web from development to design — with some of the people making it happen today and planning where it’s headed in the next version.

Tim:

Today we have with us a special guest, Ken Wheeler. We’re going to talk about how Ken got started in the industry, we’re going to talk a little bit about reactive programming, it’s going to be a great show, so let’s go ahead and get this version started.

David:

Ken, thanks for joining us. How are you doing today?

Ken:

I’m doing lovely. Thanks for having me.

David:

Cool. Tim, would you like to ask Ken our philosophical question?

Tim:

Yes, it’s about that time. So, Ken, we have a philosophical question we like to ask every guest who comes up on the show. So here goes: in your current career, what version are you and why?

Ken:

O wow, you’re going to drop something that heavy on me this early?

Tim:

We always get this response too — it’s great! [Laughs]

Ken:

I haven’t done so well with semantic versioning in the past. Well, I’d like to say that I’m like 0.19-alpha perhaps — or at least I’d like to think that.

David:

It’s nice that you’re keeping it in the alpha range. That’s important.

Ken:

That’s right. It’s not quite beta yet. It’s still a little rough around the edges. Not ready for a 1.0.

Tim:

Cool, so this is the stage you are at in your career. How did you get to this stage? What brought you into the world of what we’re doing?

Ken:

I did it a lot as a child. When I was a little kid, I learned to type really quickly. Most of the computer classes were typing at that point in time. Me, already being a proficient typer, having the privilege to have a computer in the home, I was kind of excused from the typing portion of the computer classes. I got to mess around with other things like QBasic or Visual Basic.

And it fascinated me, so I would play with that. I had a really good time doing it — did a lot of Visual Basic as a kid — and then I stopped programming. Wait, before I stopped programming, I also did a lot of early HTML — like remember, what is it? Like GeoCities and all that jazz, the 3D wireframe spinning skills and blood dripping banners and all that fun stuff.

David:

We will see if we can find an archived copy of your GeoCities page to put up with the podcast. [Editor’s note: we couldn’t find anything, but let us know if you have any luck finding something!]

Ken:

I sure hope you don’t! But yeah, it was a good time. I stopped programming for a little while, and I became a rapper — more so a record producer than a rapper. I really enjoyed music (had from a young age). I eventually got pretty good at rapping and making the background music to rap songs, to the point where I was a signed artist. I worked as a recording engineer for some pretty interesting artists and what not.

Napster came out, and that stopped being a career for me. I had a couple of funny careers after that. Maybe “career” is not the right word. Maybe funny jobs in the interstitial period. I was a matchmaker — a high-end matchmaker at that. It’s not like sports — like relationship matchmaking for wealthy folks.

And I was a stockbroker, which was probably even more hilarious. All kinds of jobs — a butcher’s assistant, pizza delivery, the list goes on, absurd occupations. At one point, I realized that I know how to do computers, and I like it, I enjoy it, so why not pursue that a little.

So I remember the first job that I got, I lied my way into. We were writing Flash — it was like a Flash shop at the time. I don’t know if you guys remember that back in the day, but it was like a full Flash shop. We’d make websites for restaurants and local companies with the super fancy intro, and sweet photo galleries, writing ActionScript, ActionScript 2, later ActionScript 3, keeping it ECMA the entire time.

David:

Of course.

Ken:

But yeah, I told them I knew how to do that, and at the time I did not know how to do that, but I was confident that in a short time I would be able to do that. Lo and behold, I was able to do that, so I did that for a little while. I was a Flash developer, and then the iPhone came out. When the iPhone came out, they kind of murdered Flash. Saw the writing on the wall, and got back into the whole HTML/CSS/JavaScript thing, where I guess jQuery is just starting to get like sort of popular. And I kind of took it from there for about maybe like a year or two, writing the kind of stuff that we do today. Not necessarily the stuff we do today, but not Flash.

David [4:26]:

This is interesting, because I notice a couple of trends that I’ve seen in other engineers. First of all, it sounds like you don’t have like an engineering degree. Is this something that you pretty much learned from teaching it yourself?

Ken:

Absolutely. That’s how I’ve done almost everything that I’ve been necessarily good at, music included. It works for some people, it doesn’t work for other people. I’m an autodidact, so I do very poorly when attempting to be instructed by other people, but teaching myself works out pretty well.

David:

There’s also a trend that I’ve noticed: a lot of people who do this also have musical backgrounds.

Ken:

Is that right?

David:

Yeah, it seems like there is a relationship between like comfort with music and a comfort with engineering, with programming.

Tim:

Yeah, I have a similar sort of origin story where I first started working at a recording studio and then building websites for the recording studio and yeah, same sort of … Well, I didn’t rap, or produce anything, but I wasn’t that cool …

Ken:

I’m sure you could have.

Tim:

Yeah, maybe I’ll lay down a couple of tracks later as outro music.

Ken:

We could do it collab.

Tim:

That would be so good. We could use like Web Audio API or stuff. It’s very complicated sounding, but I’m down.

Ken:

East Coast?

Tim:

Yeah, you’re in Jersey, I’m in Queens — it’s perfect.

Ken:

I feel like the East Coast needs a little rapping these days, my man.

Tim:

They do. So, Ken, cool projects you’ve been working on recently. Do you want to talk about some of the recent programming paradigms, challenges, cool projects, anything like that?

Ken:

I would say that a lot of this React work that I’m doing at Walmart is super interesting, because it’s like a new thing, but it’s also at scale — at humongous scale; so that’s been pretty interesting.

Other things are having popular open-source projects. I wrote Slick Carousel, and actually writing it was not effortless, but it wasn’t super hard. It’s dealing with it after the fact, which has been interesting. It’s very interesting to try and maintain these sort of things — and that applies to all open source. I have a lot of libraries out there that I don’t maintain as well as I probably should. It’s super interesting to see the process of something getting popular and then the different projects, how some have certain issues that other ones don’t. Something like Slick Carousel is like a low hanging fruit: who doesn’t need a carousel, right?

Almost every website that you are building for somebody else for money, they’re going to need some kind of slider on there. But you have other things like Flux libraries and things like that. It’s a little … I’m not going to say “exclusive”, but it’s a smaller audience; it’s a more focused audience, so you have different kind of problems. You have people coming to you with, “I’m not like super-hot on JavaScript. How does this work?” It’s more like, “I am super-hot on JavaScript. We need to optimize this”, or something like that.

Dealing with all of that in the open-source space has been pretty interesting. One of the absolutely most interesting things that I’ve been doing lately is React Native, which is crazy. You’re writing real, native applications in JavaScript, which is absolutely crazy to me.

David:

I’ve heard a little bit about React Native, and I’m curious: what kind of challenges are you facing when you try to develop in React Native?

Ken [7:30]:

Well, you have a couple of different benefits there of using it. First of all you get cross-platform, so you write at once, generally speaking, and you get the same experience on Android and iOS — from a single code base. If you’re really nifty, you can even share some of the Redux from the web with that application if they are similar enough. Next up, you get cool things like you can hop the Play code, so you can kind of sidestep the App Store submission process (which has actually gotten a little bit better lately).

One thing that I see at scale, which is pretty cool, is if you have like a bunch of engineers that are familiar with JavaScript, or familiar with React, suddenly your entire JavaScript team can work on your mobile apps. And again, that’s generally speaking.

I’m doing React Native at Walmart, and it’s remarkably non-trivial. There is a lot of stuff going on on the native side that is pretty complicated. So it’s not like just anybody from the JavaScript side can come over and mess with it.

React Native isn’t a replacement for certain things. It just doesn’t make sense for certain things. Essentially, if you were to have a native application, and you found a place where you would use a WebView (this is for like hybrid applications, right?). If you had a place in that where you would use a web view — like a Cordova sort of thing — but you wanted it to feel native, React Native is an excellent candidate for that.

Tim:

What is it about React Native that makes it feel more native than say a PhoneGap/Cordova sort of situation?

Ken:

It literally is native. What happens is, how exactly it works — maybe not exactly, but how I personally understand it to work after working with it and reading up on it in detail — is that you have your JavaScript, which is interpreted on one thread, and then you have native code that takes that interpreted JavaScript and builds native views with that. You’re essentially telling your native program how to lay out and act with JavaScript — but it’s not in the browser or WebView. You’re not running JavaScript in the context of a browser. You’re not rendering to HTML. At no point in time is HTML ever used. What you’re doing is specifying types, like view and text and things like that, and those are representative of (if you are in iOS) things like UI views, UI text, any of these controls. What makes it even cooler is, there’s probably the best bridging system that I’ve ever seen, so your developer experience is amazing.

Almost anything you can imagine on the native side you can bridge over to JavaScript very easily. I had a situation where I needed to use geocoding. So you take a string, and you want to get a lat-long from that string: that’s in iOS.

So, you can bridge that to your JavaScript application. You can make an async call out to the geocoder — or the geocoder class that you have set up in a native module class with a callback; it’s bridged. You can make a call to it, and it’ll send back to you lat-long coordinates.

That’s just one example of the sort of things you could do. Not only can you bridge modules like that, where you can write an Objective-C class, where you do anything under the sun: you can also expose and render views. Any view that you can imagine — any control, so to say — you can hook it up, bridge it, and then represent that in a tag with props (which are essentially HTML attributes) and then wire those up to control it.

David:

That’s really great. I’m curious if the challenges that you’re facing at Walmart have to do more with dealing with the native aspect of it, or dealing with the scale of what you are trying to accomplish.

Ken:

A lot of it is balance, to be honest. They do some pretty nontrivial things over there on the native side. There is a lot of brilliant mobile engineers, who have some really cool base stuff set up.

For me, being a JavaScript guy coming in over there, I want to play as nice as possible. [Laughs] So a lot of it’s balance. I want to use as much native as I can, while still remaining flexible on the JavaScript side.

Scale — of course, that’s difficult, but a lot of that is not only user scale (a lot of that is really services more so than UI). We’re not getting any kind of UI concurrency with the users or anything like that; that’s more of a service problem. But I guess the scale would be developer scale, organizational scale, which we do have to mitigate.

So internally at Walmart, we have a platform called Electrode, where we have a ton of common elements and common components — what have you — that everybody can pick from and that are maintained as a whole.

So, rather than each individual app going into doing their own thing, we have a centralized collection of components and Redux helpers and things like that, that are maintained organizationally. The idea being that if you have three different teams working on three different apps, and they have the same text box component, rather than doing their own thing, they’re going to go and use that one text box component. And then, if one of those teams finds that the text box component isn’t as flexible as they need it to be, they PR it and it gets better. And that process propagates, until you have rock solid, really good components. Because these components are added to, pull requested, tested thoroughly, better reviewed, you can be sure when using them that you’re going to have something more stable than had you just gone and done it on your own.

Tim [13:04]:

That’s pretty cool. It’s almost like Walmart has its own sort of internal open-source environment to kind of keep track of all of those. Are there any lessons that you can take from how Walmart does its sort of open-source-like work and kind of translate that into the actual, much wider open-source community?

Ken:

Absolutely. We have an ESLint config. I work for Formidable; through them, then, I work for Walmart. We use the Walmart lint configs, all the process there. We also have a tool called Builder, which we use to manage several repos. If you have that Walmart-like situation where you have a ton of repos, we use Builder to essentially have the same build processes — everything like that — across all those, and be able to update that across all those.

So, if you had a Webpack configuration — you had like ten repos — and then you changed something in one of them with Webpack, you’d then have to go into each one and update your Webpack config in every single one of those to get the new way that you’re doing that build. So we have tooling around things like that, where we have this shared build system and testing and things like that — where we can make one change in one place, and then it will propagate across, what, 90 repos or something?

David:

Wow. That’s a great example of how that sort of thing can apply, because when you’re dealing with open source, you’ve got all of these different people working on different things simultaneously, and trying to keep track of all of that can be insane. How do you balance your open-source work with the work that you’re doing inside of companies?

Ken:

Well, it’s actually funny, because Formidable, the company that I work for, we bill ourselves as an open-source company that does contract work to keep the lights on. It’s not like I go do my day job and then do open-source work. A lot of my day job is open-source work. We have officially sanctioned open source that I’m given time to work on in the 9 to 5 that I’m here.

When I wrote Slick Carousel, that was not the case. I was working at a great company but was in an open-source–driven sort of thing. I would do my open source at night and come back and do client work throughout the day — a lot of the time getting my client work done a lot better by doing my open source at night, or tools that would allow me to work quicker, faster, better, what have you.

Now, at Formidable, open source is encouraged. We’re given time to work on it, and we have a ton of open source that we work on. As far as my personal open source, my personal open source is suffering at the moment. There is only one reason for that, and that’s fatherhood. I’d come home, my wife would put on The Bachelor or something like that (and who wants to watch that?), so I hang out and work at my open source, tap away the keys. If she had a big day in the morning, she’d go to bed at 10:00, I’d stay up until 1:00 in the morning playing with computers.

That’s not the case anymore. Now, the time that I am working with, I’m either getting my dad on, I’m completely exhausted and/or drinking. There’s not as much time as I wish there were to do my personal open source, but I make it work.

I try to manage it a little more, whereas previously, whatever I was interested in I would just work on. Now I’m trying to say, “Okay, well, this needs to happen on this and this needs to happen on this.” I’m getting a lot of these new hot thumbs-up things on GitHub — the “reactions”, or whatever they call those. I’m like, “Ah, well, you got to take care of that one.”

So I’ve been trying to not just cut releases, but delegate the work a little bit more. Some of these libraries are pretty popular, and there’s a lot of people depending on them. If somebody comes to me and they say like, “I have this thing that needs to be done by this time”, I’ll try and prioritize it for them. Or if somebody at some company is like, “We need this feature”, I’ll try and prioritize that for them. It’s interesting to try and manage.

You’re writing code for free, but you are still somehow indebted with it — but it’s not free, right? I told my wife I got some absurd amount of hits on the page, the documentation page for Slick, and she’s like, “What if you charge for it?”

I’m like, “If I charge for it, someone will use the different one that’s free.” It’s not like you don’t get anything from it. You get an enormous amount from open source. While you might not be getting like paid directly, the fact that you’ve written certain open source opens the doors to different things career-wise. It’s like you’re not technically being compensated, but it’s good. I build cool things, other people build cool things, it all works out because now we have all these cool things.

Tim [17:11]:

Yeah, that’s very true. Speaking more to the health, or at least the mental health, and organization of open-source maintainers, do you have any tips for people who are looking to get started with contributing to open source? If someone for example has what they think will be a really good idea but might be worried about the long-term burden of maintaining something like that?

Ken:

A lot of people that I see commenting about it, or talking about it, it’s almost that they’re scared — they’re uneasy about doing it. They don’t know if their code’s going to be good enough. All I’ve got to say to that is just put it out there. I still don’t think my code is good enough, and it probably never will be. You know what I mean? It’s just like put it out there, and if something’s that bad, somebody will say something about it.

But if they’re saying something about it, it’s an opportunity to improve it. I did some things with Slick Carousel early on, or I did some things [on] other libraries. When people call me out on that, I’d be like, “Wow, I never actually knew that. I never knew that that was like a perf thing. Thank you so much.” They are like, “This is like a cross-site scripting vulnerability or something like that?” I was like, “Wow, I had no idea that was possible like that.” It’s just a learning thing.

It’s like any time anybody calls you on something, don’t feel dumb. You can feel dumb, I feel dumb all the time, but don’t take it personally. If they’re worried about the long-term maintenance, who cares? You don’t owe these people anything. You’re putting something out there for free, taking time out of your day to support it, and that should be good enough. If people are depending on it, if people are really depending on it, I think delegating and making sure that it’s reasonably up to date is a good thing. Don’t just pull repos down and shit, where there’s thousands of people depending on it. That is not a subtweet to any particular thing; I’m just saying!

But I would just tell people don’t worry about it. Just build stuff and put it out there. I wish I could not worry about it a little bit more, personally. I’m actually a little uneasy to build any new things or put them out there, not just because of time, but because I know that I can’t maintain them. It’s like having a child that I know I can’t take care of.

I know that I’m not going to be able to like dedicate this full-time issue. It’s not the writing the code. I can fix the bugs, no problem, that’s not even a big deal. It’s the issue management. That’s the biggest thing. Having to sit here and argue with people.

One thing worth mentioning is, keep the APIs small. If there’s one thing that I’ve run into, very personally, is that a lot of people are going to come at you with requests for options, different options and capabilities and things like that, based upon edge cases. And then catering to each one isn’t going to do anything good. If you catered to every single edge case, if you add every single option that’s proposed in the interest of being a cool guy who is doing it, no. Because what’s going to happen is now you have this big, bloated library of different Band-Aids for different edge cases, and you’ve gotten away from the original vision of something that is just this small rock-solid set of APIs for the 90% use case. Don’t let that happen to your project — please!

Tim [20:12]:

Yeah, I have to say that some of the best advice that I’ve gotten — and realized myself when releasing some of the limited, very low-starred libraries that I have in open source — is just keeping it small, but also with the ability to extend for those who need to. I think I’m mostly in favor of releasing small, single-purpose APIs where the documentation is good enough so someone can just fork it themselves. And then it’s, “O, let me add this thing.” Maybe their version will get more recognition than mine, but it definitely keeps the maintenance burden so much lower.

Ken:

It’s good not just to close off the scope, but to give an escape hatch for people to iterate upon. I think an amazing example of that is Redux. Shout out to my man Dan Abramov.

Redux is remarkably small. It’s a very small library that does a very small thing. But it is gives you the escape hatch of middleware. Now an entire ecosystem has sprung up around it, where all those edge cases that people needed for all the different projects are now individually managed by those people and other people who have those edge cases in separate projects via middleware.

There’s Redux middleware for everything nowadays. It’s something an action comes through and it makes you a taco. I think that’s a really great way to go about that. He really struck gold with that API design, because there you go, there’s your escape hatch. You can iterate on that for perpetuity with middleware.

Tim:

So Ken, what do you say to people — and I guess sometimes I’m a part of this camp (you and I go back and forth every now and then). But what do you say to people who say, “I’m just working on a project that’s x size. Why do I need to do something like React or Redux for my project?”

Ken:

It depends on your project. It’s hard to say though, right? Like I can sit here and say I wouldn’t use React for a static site, but actually I would, because of Gatsby. I wouldn’t write a presentation. Of course I wrote Spectacle, I write presentations in React. For React itself — that’s not a good one — but I think it certainly speeds things up, but it’s highly independent upon your needs.

If you’re writing an application, I think it can really help you. I think if you’re writing just like a local deli web page, you probably don’t need React or Redux. Most of the time you don’t even need Redux. I have developed React Native games without Redux. Redux is the sort of thing that you cross that bridge when you get to it.

David:

I can see that. React is versatile enough you can use it for tiny little components, or for the entire application.

Ken:

There’s projects where I guess you can have React almost act like Web Components, where it’ll mount them into little pieces of a regular web page. If you just want like a React widget, or if you want a full-scale application, you render the whole page in React. Which is generally speaking what I do. Or if you’re a maniac, you render an entire native app with it. Or, if you’re even crazier, you use React-blessed and use React to render to your CLI blessed terminals, where you have CLI dashboards that are written in React.

Tim:

I think my brain is melting now.

Ken:

Have you seen that?

Tim:

No, I have not.

Ken:

O man, I got to show you. It’s pretty chill. I’ve set up GitHub webhook. See this TV behind me right here?

Tim:

Yeah.

Ken:

There’s a Raspberry Pi hooked up to that.

Tim:

Of course.

Ken:

I suffer from open-source guilt. I have deep, deep open-source guilt, so I want to do a better job of being a maintainer. So I decided that I wanted to have it in my face all day long, every issue of anything like that. So I have the Raspberry Pi there. I didn’t get it actually completely finished, but what I had was I set up ngrok on the Raspberry Pi to expose it externally, and then set up a GitHub webhook, and then an Express server on the Raspberry Pi, so that every time something happened on GitHub, it would send it to the Raspberry Pi. The Express server would take it and then it would render a terminal output using Blessed, to give me a cool hacker review of how shitty I am on maintaining open source. But if you haven’t seen Blessed, it’s really cool.

Tim [24:28]:

That sounds amazing, and extremely unhealthy, and I’m worried about your sanity now.

[Laughter]

Ken:

No, I’m fine, I’m good.

David:

O come on Tim, who doesn’t have Raspberry Pi hooked up to their television set? Please!

Tim:

I know, that’s ridiculous.

Ken:

Throw the first stone, right?

David:

Listen, Ken, how can people find you online?

Ken:

O wow — bodybuilding.com forums.

[Laughter]

Evko gets that one.

So, you can find me at github.com/kenwheeler. You can find me on twitter.com/ken_wheeler. You can go to formidable.com to see where I’m at over there. You can go to soundcloud.com/thekenwheeler if you want to hear some super-fresh stuff. I don’t know, you could Facebook friend me. I think I have privacy settings with friends of friends, but we should all become friends.

David:

We should all become friends, absolutely, and we will be putting links to those in the show notes. I just want to thank you. This has been a really great interview. Thank you for joining us today.

Ken:

Thank you so much for having me.

[Musical interlude]

David:

So it sounds like you knew Ken from before this.

Tim:

Yes, actually. Ken and I became internet friends, because we both wrote articles for a website called scotch.io. It’s funny, because it didn’t surface very much here, but Ken and I actually wildly differ in opinions on frameworks, or very popular libraries. One of the big reasons for that actually is because Ken works on giant, hugely-scaled projects like Walmart and the stuff that he does in Formidable Labs. I work on a lot sort of smaller, less-having-to-worry-about-global-state-everywhere types of projects. But every once in a while him and I will go round for round on Twitter, talking about why we code one way versus another way. It’s always a sight to see if you ever witness it.

David:

It’s interesting. I’ll have to look for those. I was impressed with how strongly he felt about his positions on these things, and I thought he brought very good arguments for why he’d come to the conclusions that he did about the different approaches that he has.

Tim:

Yeah, definitely, and it’s something that earlier on in my career I was — I think as we all are — very heavily opinionated towards a certain methodology or coding a certain way. But the more I experienced things like, “We have 15 or we have 50 developers on our team”, we need to standardize things. We need specific methods. We can’t walk into a project and code everything from scratch now, because there are much more concerns. There’s much larger scale, there’s much more code to push. Yeah, I can definitely see pretty much all of the reasons that he takes the approaches that he does on certain projects.

David:

It sounds like he came to these conclusions pretty organically — in particular, the way he was talking about the importance of small APIs on these open-source projects. I thought that was a really fascinating point.

Tim:

Yeah, I gave a lightning talk at a meetup one time about that. I basically just open-sourced this really, really small, it wasn’t anything magnificent. It was just a small API that allowed you to work with cookies easier, because, as you know, document.cookie is just string manipulation. There’s really no function there. So I just kind of abstracted that into an object with some methods and made it a little bit easier. It was maybe like 50 lines of code, and there was obvious potential for other functionality.

For example, you could have, what if we save some of the cookie manipulation in local storage, or add some new methods here, or give the user a way to add secure cookies? I intentionally left that out, and I wrote down in the repository in the README, “Don’t submit new functionality.” … I said “please”. I said, “Please don’t submit any functionality to this. Rather, fork it and do what you need to, or submit a pull request that makes my crappy code better than it is, but leave the functionality to itself.”

What I really want to do when I write open-source code is I want to encourage the user to learn more. I don’t want to write code that someone is going to use and implement without giving a second thought as to how it works. And that’s typically why I try to avoid abstractions as much as possible, and tend to move more towards not necessarily doing things from scratch every time, but coding in such a way that you are very, very, intimately familiar with how your application works.

David [29:15]:

I can see that, and the importance of having people learn something from the code that you’re writing. I think when you look at how quickly just the JavaScript landscape alone moves — how much is changing, how many new frameworks there are, how many paradigms are coming out — that people are saying, “This is now obviously the right way to do things, and you can’t do things that way anymore.”

But things change so very quickly. One of the things that Ken was talking about was this fear that people have of releasing things to open source, because of their own sense of intimidation about their expertise and how skilled they are.

But it’s really important, when you’re thinking about whether or not you want to release something to the open-source community, to remember that you’re at the stage that you are with the specific things that you’ve been exposed to, and somebody else is out there at that same stage but with completely different set of concepts that they’ve been exposed to. Each one of you can learn from each other, from the mistakes that you’re making as well as from the things that you’ve learned and that you want to share.

Tim:

Yeah, that was a lesson that I learned very quickly on my first major open-source project — which actually didn’t end too long ago, when we worked on WordPress Core to get responsive images into WordPress Core. I wrote version 0.01 of that plug-in, that eventually made its way into WordPress. There is maybe — I’m not exaggerating here — maybe one line of my original code made it to the actual final iteration. I was okay with that, and in fact more than happy, because what came out of it was this amazing thing that I could never have built on my own, because WordPress is just this enormous code base. I slowly learned that, OK, it’s not a bad thing to put something out there that’s terrible, because it’s going to get a conversation started. People will join on. People came out of nowhere.

Joe McGill, who basically saw this thing to the finish line, I’d never met him before. But one day he saw, “O, this thing is happening on WordPress”, and within a month or two he was a core contributor deleting all my bad code and writing in these new great things. At the end of the day, when this project was finished, we were all WordPress Core contributors. I learned right then and there not to be super worried about the thing that I’m pushing out, because the thing that I’m open-sourcing to the world, it’s as much a learning experience for me as it is a benefit maybe to somebody else. If it’s good, great, somebody else will use it, maybe I’ll get to talk about it one day. If it’s bad, I’m going to learn so much more.

David [31:50]:

This is just as true in closed-source environments as it is in open-source environments. I’ve worked in so many companies where the projects that I’ve worked on, it’s been a team of people. And at the end of the day, one person might have been actively involved in coding constantly, and not a single line of code might have been included in the final project, but that participation and the involvement, the learning that went on, the different perspectives that come into play — it’s not like you can define a team by, “You wrote seven lines of code, so you get this much”, and “You wrote 12 lines of code, so you get that much.” It’s like an old joke in programming. You don’t pay people by the lines of code that they end up getting published. You have to focus on the learning and the value that’s being added by the collaboration of the team as a whole.

Tim:

I’ve learned probably the most that I have in my career through open source.

David:

Yeah, and the fact that there are so many people out there willing to share their knowledge and share their interest in these things is remarkable. When people started talking about it originally, it was like “People are going program for free? Nobody is going to do that.”

Oh yeah? People are going to do that, and people are going to learn from it, and they’re going to benefit from it, and society as a whole is going to benefit from it.

Tim:

Yeah, definitely, and that’s one of the things that I love about open source. I feel like sometimes people can see it as, “It’s slave labor, it’s like you’re doing this stuff for free. Why would you ever do that? You are just sending your secrets out into the world for everybody to see.”

And I was at that point one time when I first got into coding. I was like, “Why would you show everybody what you’re doing? Why not keep it to yourself?” And then I realized that it’s very counterintuitive to most other industries that exist, but the more you put things out there, the more you teach each other, the more you personally benefit from it. That’s something I love about this industry.

David:

Another thing that’s remarkable about it is you should only be so lucky as to have somebody copy what you are doing and try to riff on it and move forward with it. The thing you learn when you start putting things out into the open source is just how compelling your idea has to be before somebody will join in and start participating with you. It’s not like we have to hide your ideas in a safe under your bed in order to protect them. No, if you put your ideas out there, you’ll find out whether or not they have any value by whether or not people start using them.

Tim:

Yeah, I couldn’t say that better myself. And I’ve run that time and time and time again. Code that I’m absolutely terrified of putting out there, I’ll put out there, and then sometimes to my relief, it’s like “Nobody saw this, it’s been done a million times before, cool, that’s that.”

Then at other times, I’ll release something, and some people will see it, and that’s great. One of the things that I really like that Ken was super, super honest about maintaining open-source projects. That is something I hear a lot from people who work on these projects that just balloon in popularity.

People use them all the time, and then it becomes a sort of looming overhead stress that you have to keep up with maintaining this thing. People can become dads people, get married people, just go other places in their lives. And it’s [been] talked about before, but I think it’s something we have a responsibility to talk about. People in open source need that sort of mental health. Open source shouldn’t be a thing that people have to worry about intensely about maintaining and get stressed out over. I think as a community we should really be doing our best not just to thank but to help open-source maintainers wherever we can, because, hey, we’re all using their stuff.

David:

I’ve actually heard it discussed as an issue about diversity, and marginalized communities in the programmer world who, may not have the flexibility or the privilege to be able to spend time working on open source. They get squeezed out of the job opportunities, because jobs are being offered only to people who have a large open-source resume.

Tim:

Yeah, what would you say we do to help that issue?

David [36:00]:

It’s a tough one, because on the one hand, an open-source resume is a great way to judge somebody’s programming skills — certainly much more effective than these whiteboard interviews. On the other hand, there are people who just do not have the resources — who might not be as fortunate or as resourceful as Ken to have found a job at a company where working in the open source is also part of his professional career, and part of what he’s getting paid for. It’s a very difficult challenge.

Tim:

Yeah, I think about that often in terms of, I catch myself a lot looking at candidates and asking myself, “Well, I can’t find something on their GitHub profile. I can’t find a GitHub profile for them, or a CodePen,” or whatever, so I don’t think this person is a great programmer. I have to catch myself, and then I remember not everybody has the privilege to just go home and fool around on GitHub for an hour. Some people have to have dinner for their entire families, or maybe even work an extra job so they can make ends meet. I would say something that I know personally that I can do better is to catch myself before I am judging somebody for their lack of a GitHub profile.

David:

Absolutely, and it’s something that we might want to address on a future show — maybe bring in an expert who can talk to us a little bit more about that.

Tim:

I think we most definitely should do that. Yeah, that’s a great suggestion. I think one of our next episodes should be pretty much all about that.

David:

I think we can do that.

---

Well, thank you so much for listening, everybody. We always enjoy getting to talk technology with all of you.

Tim:

We would also like to thank SitePoint.com, and our producers, Adam Roberts and Ophelie Lechat. Please feel free to send us your comments on Twitter — @versioningshow — and give us a rating on iTunes to let us know how we’re doing.

David:

We’ll see you next time, and we hope you enjoyed this version.

Frequently Asked Questions (FAQs) about Ken Wheeler and Versioning Show