How to practice continuous learning and adaptability with open-source (Trails Podcast episode #17 with Shane McLaughlin)

Join us in this episode as we delve into Shane McLaughlin’s perspective as a Salesforce Platform Architect. We talk about practicing continuous learning and adaptability with Salesforce open-source. Explore his journey, gain insights, and discover valuable tips.

Chapters

• 0:00 Introduction and Background
• 2:23 The Launch of SFDX and the Salesforce CLI
• 5:43 Open-Sourcing the CLI: Libraries and Plugins
• 10:13 Curating Awesome SFDX Plugins
• 13:47 Insights from CLI Telemetry Data

Transcript

Harald (00:01)
Hi Shane, it's great to have you here, thank you for taking the time.

Shane McLaughlin (00:06)
Thanks for having me, Harold.

Harald (00:09)
So could you give us a short overview of your developer career? How did it all start and how did it lead to your current role at Salesforce on the SFCLite team?

Shane McLaughlin (00:21)
Yeah, sure. That's an interesting story. I was a finance MBA and I was working for a big utility here in Houston. And they put me in charge of this little e -commerce business and we were going to use Salesforce. That was the first time I'd ever seen or touched it for our customer service. So if you called us at the call center or sent us an email or whatever, we'd be doing typical service cloud things with it. And it turns out the people we had hired to build the rest of the e -commerce business failed spectacularly at it.

And so I kind of took it and built it all on Salesforce and had the help of a couple of people that were working for me because we had no more budget left to do anything else. And so that was kind of the awakening of, I looked at it and I was like, I can do a lot more good for a company as a Salesforce developer than I really could managing other people. And also I think the company was like,

I didn't know you could do that with Salesforce. So that spun off a few years of building other business processes and stuff like that on it. And I think at that point, we built so much weird stuff that people hadn't seen that the Salesforce people were taking notice of it. And at a time when that little business was not as interesting to the company, I decided to offer my services to Salesforce. And so they hired me there.

Yeah. And then this is actually, I think this week is like 10 years at Salesforce. And so I started off in sales engineering, mostly doing platform demos. And then I moved to platform product marketing, mostly doing platform demos. And so like, I think of all of that time as like being a developer on top of the platform. And that's kind of how I started messing with the CLI and messing with plugins was, I'm going to use this to

serve my demo needs and make it easier to distribute demo orgs. And then that's how I kind of got to know the CLI team and the product and stuff like that.

Harald (02:23)
So fast forward into 2017, which is at least where SFDX and the Salesforce CLI became publicly announced. It was probably around there earlier as a private beta. I learned about it 2017 when it became public beta.

So yeah, that definitely brought a lot of fresh air to Salesforce DevOps to the way the Salesforce developer experience is shaped. So any specific memories to that time? I assume you have been on that team that launched SFDX back then already.

Shane McLaughlin (03:06)
No, not at all. I think when that first came out, I was over in, I just started moving to product marketing. And so I was aware of it in the sense that lots of people were working with it and in the sense that, hey, this is coming. So we're going to need to be able to talk about it, do demos, use it in demos and stuff like that. So that was really my introduction to it. And as I was looking at that, I was like, you know, at the same time I have

this giant spreadsheet that I had inherited when I took that job, which was, here's London world tour on June 21st or whatever. And these are the orgs at these different booths that people might need to log into. And every time you do one of these, you have to go spin up, you have to go create new orgs and put the. Usernames in there. And every one of these has like a, you know, someone comes and talks to you, you show them the demo, and then you have to undo all those steps so that you can, you know, build whatever it is that you showed them how to build again.

And so as we were looking at SFDX, I was like, this is useful not to demo it, but to build demos with it. You should be able to push a button and have an org. And then when you're done with it, you should be able to throw it away because Scratch Orgs came first with SFDX. You should be able to throw it away and not have to do all the reset steps and just be like, give me another one. So that was my initial interest was, I'm going to use this to get rid of that spreadsheet.

no, we have two world tours happening on the same day on two different hemispheres. You know, we don't have to worry about, I'm logged into this order. You logged into the org too, or are we going to be stepping on each other? You know, that kind of stuff. It just became, everybody could have as many as they want. And it was this, this dream of being able to spin up scratch orgs and hand them out like candy. Yeah.

Harald (04:44)
Yeah.

Yeah, very similar experience on my side in 2017. I was working at an ISV and very similar challenge. The team grew orcs that we used to share started to get polluted before QA or even at the time development in a as an ISV in a developer edition or the packaging org was still very common. So this whole

opportunities that came with SFDX and specifically with Scratchworks were definitely a game changer. Another big milestone that I remember from SFDX was the announcement that it actually became open source, the command line. Do you recall when that was?

Shane McLaughlin (05:43)
Yeah, that was more of a gradual process. And some of that happened while I was on the team. So we had originally there was just this one big monolith of the CLI, and then users could make plugins. And we would maybe three times a year after a Salesforce major release or so, we would copy all that to an open source repo. So you can be like, here's the code. But it wasn't really open source in the way that it should have been. It was more of like, this is a static copy of a point in time.

And so then what we did to take that apart was to break out some of the stuff into libraries. And so that way, VS Code and the VS Code extension for Salesforce and DevOps Center and stuff like that, and anybody else who wants to build things could consume those libraries. So those all went out first open -sourced. And then we started breaking that giant CLI into plugins so that you'd have just the org commands for offing to an org. Okay, that's a plugin.

And so we would open source those as we gradually moved them out. And so that actually took about a year and a half. We don't own all the plugins on the CLI team. So like there's a packaging team and they're responsible for the packaging plugins. And so there was a point in time we had to be like, okay, yours are moving out and going open source. Yeah. So that happened gradually, but it's been really nice. We get much higher quality of.

VR contributions, we get much higher quality of bug reports. People are like, here's where it is in the code. I changed this. That changes the bug. This is what I did to fix it. We're like, thanks. 90 % of the work is done on that. We'll just check it and write some tests and publish it. Yeah, so open source has been exciting for us. We use a lot of open source. We've contributed to some other open source libraries. Just the thing that will open a web browser on every OS and shell.

in existence, no matter what your web browser is, that's a library. And there's been a few things that we've found, or sometimes the users have found, that doesn't quite work right. And so we can contribute those back. So it's nice working in the open. I like the tool set a lot.

Harald (07:38)
Mm -hmm.

And you, would you consider your team like pioneers for the open source idea inside Salesforce?

Shane McLaughlin (07:57)
there's been a lot of open source work. There's been a lot of open source contributions. but a lot of times that's a team who's using an open source product and contributing back to it, you know, like Apache foundation type things. I think.

I think there's a number of teams. You see it a lot with developer relations, I think was one of the first places where, you need to make it open source so you can share it with everybody. So I would say they probably pioneered getting that kind of stuff through security and being able to use GitHub actions and PR processes and all that kind of stuff. And I would say we're probably one of the product, in terms of proper product teams, I think one of the earlier ones.

But there's a lot of teams that are doing open source work. And especially some of the stuff that's off the core platform, you'll see a lot more. It's just less integrated. It's easier for it to stand on its own island.

Harald (08:51)
LWC would be another example, right?

Shane McLaughlin (08:59)
Yeah, I think that came out, that may have been open source before the CLI was finished being open source. So yeah, those were pretty early. LWC is great. They got to where they were the inspiration. I don't know if you've seen, but we've mostly moved all of our feature requests stuff to GitHub discussions, letting people vote and have those. LWC had like a RFC process built in GitHub where like,

not just we're working in the open, but we're planning in the open. And I like that approach a lot. And once GitHub discussions came out, we decided to adopt that too, just to help prioritize not just bugs, but like feature work and, hey, is this a good design for this? Or you think it should be something else? And we get a lot of nice feedback on those.

Harald (09:46)
Awesome. So speaking of SF or SFDX plugins, you are the author and maintainer of the awesome SFDX plugins. I think that that's how many people probably in the ecosystem know you and your GitHub. So yeah, essentially for those who don't know it, I would say it's a curated list of, yeah.

extensions to the CF CLI. And we also touched upon it briefly with my last podcast guest, Matthias Horker, who has something similar now or let's say inspired by your famous project. He gave it a spin and also launched something very recently. Yeah. So could you

Shane McLaughlin (10:28)
much nicer.

Harald (10:42)
probably share what inspired you initially and do you have any specific plans with that project.

Shane McLaughlin (10:59)
a little bit in that question, but I'm gonna go ahead with it.

Yeah, what inspired that initially was a lot of the ecosystems have an awesome React or an awesome CSS or whatever. And I've used those in a few places where it's just nice to be able to find this big list of stuff. And then as new things come out, people are like, let's put that on the list. And it's really good because sometimes the original React isn't leaking off to all of you. It's some user who decided to put all this together.

And so I had plugins on there. I had some plugins from other people that I was using at the time. I knew there would probably be a good chunk of them. And you'll see that that was done on GitHub as me and not as Salesforce. Salesforce is not recommending them. This is some guy on the internet who says, here's a list of things that you might be interested in looking at. And then we've added, since then, we've added the plugins discover command to the CLI, which will show you

Here's also a curated list right there in your CLI. But it's also got things like NPM downloads per week and GitHub stars and some other things. And last time it was updated. So it's kind of nice to see the relative popularity and health of plugins, I guess. So yeah, I found that useful. The new web -based searchable one is also really sweet. He showed that to me. I appreciated his work there.

Harald (12:26)
And I think I saw it by stars and yours was the kind of showing up first, if I'm not mistaken.

Shane McLaughlin (12:37)
yeah. Yeah, there may be a lot of older usage of that. It is mostly unmaintained. Some of those commands have drifted into the actual CLI. Some of them are not as useful as they were at the time. And some of them were very specific to stuff I was building for product marketing. So you'll see commands like, I need to set my user profile photo or activate a Lightning branding set or whatever.

Harald (13:03)
Mm -hmm.

Shane McLaughlin (13:07)
things that you might not care about if you're interested in CI testing things, but things that you might care a lot about if you're doing workshops and demos and things that need to be properly branded with your fake company for your demo.

Harald (13:18)
Absolutely, I can relate a lot to that. I actually do this not quite frequently, still manually. I have to check out that CLI command. So yeah, probably as a last question, I'd like to touch upon telemetry. So I assume your team has pretty unique insights into the actual usage of the CLI. Are there any interesting...

weird funny observations about the usage that you can share.

Shane McLaughlin (13:54)
Yeah, so we collect telemetry. We don't know who you are. We have to scrub all the identifiable information out. But we do like to track things like what commands are being used, what flags are being used, but we don't get the values. We just get which flags you're using. But we also are interested in things like what OS are you running, what version of the CLI are you running. And then we track exceptions. So if you get exit.

errors and stuff like that, we'd like to see those and see, we know what that is. Or like, what is that? We may need to go search in the code for that. Yeah, in terms of interesting things, I've been really interested in the SF transition. So we've got about 70 % of daily executions are now on a new SFv2 CLI. And so there's about 30 % that are on some version of the old SFDXv7.

And you'll see most of that usage is on the very last SFDX that we published. So they're on it, they're using it. You can write update, but there's nothing to update to. It's the end of the line there. We also see some, if you want to talk about weird stuff, if you look at the top 20 versions or so, they're mostly recent SF, but there's, besides the last SFDX, there's number 15.

is really old. It's like 7 .123, which is almost like three years old at this point. And we don't really have a reason why there might be a clump of usage on that one really old CLI. But yeah, there's also people that are still on versions that are less than 100. So like minor, you know, 7 .90, stuff like that, which is

Harald (15:46)
Mm -hmm.

Shane McLaughlin (15:51)
really, really old. And if you look at it, you'll see people who are like, I'm logging in and I'm querying something, like Sockle query. And I guess that still works fine for them. And they have no reason to change it. But we hope they do at some point. I think it would be nice to not see some of that in the telemetry. And then we've also been interested in some of the command migration for the new deployment commands that the project deploy.

set of things and of the people that are on current CLI or recent CLI, they're about 88 % on the new deploy commands. So there's not many people who have the current CLI but are still typing for source push or MD API deploy or things like that, which is actually kind of, I'm impressed with that. I was thinking it might be a little bit harder to get people to change their scripts and switch their habits and stuff, but they seem to be doing well.

Harald (16:33)
Yeah.

Shane McLaughlin (16:48)
And then some of the stuff has just died. There's an old command, dino for source status.

Harald (16:54)
Yes, actually, I remember running it. Isn't it giving the overview of all the connections one has? Or am I confusing it?

Shane McLaughlin (17:07)
That might be the org list. But no, this one is like what's changed in the org and what's changed locally and what might be in conflict. So before you did a pull or a push, you would run this command to see what's going to go which way. Yeah, and people have pretty much just stopped using that command. I think it's like less than 2%. And they're using the new deploy preview or retrieve preview commands and stuff like that. So I think that's interesting.

Harald (17:10)
Yeah.

Shane McLaughlin (17:36)
the other thing, how many, how many plugins do you think ran in the last week? Like different plugins.

Harald (17:44)
Well, would that include non -public ones? Because I guess there are people not publishing their plugins and just keeping them for themselves. So, okay, I'm trying to make a guess here. Let's say how many are on your list on your directory? Maybe 200 -ish or so the public ones. Do you happen to know?

Shane McLaughlin (17:52)
Yep.

Yeah, I don't think we have that many on our public list.

Harald (18:11)
What?

Okay, but okay, let's let's just wear and a guess I would say 500 maybe.

Shane McLaughlin (18:25)
Yeah, we had 295 different plugins that ran in the last seven days. And so this is like different, these are all different authors by different plugins. And over 75 % of those are not from us. So it's about 230 or so are third party plugins that someone's created. So excluding Salesforce and excluding plugins owned by Salesforce.

Harald (18:29)
Okay.

Mm -hmm.

Shane McLaughlin (18:55)
related, you know, like commerce or whatever that has a plugin. Yeah. So that's about what that's about the number of plugins. And some of them, I don't think I've seen before when I was looking at that list. So you it's probably someone's private plugin that they have either on private NPM, or they're just installing it from source and building it, you know. And you'll see a lot of them have one user and they'll have a whole bunch of CLI or sorry, a whole bunch of CI usage. And you're like, someone's done something helpful for their

Harald (18:57)
Mm -hmm.

Shane McLaughlin (19:23)
deployment processes or testing or whatever. Yeah, so it's interesting. A lot of them have companies names in them. So in that case, we kind of can see if you name your plugin, you know, my company's name and then, you know, then you can see you can you can have an idea of who that might be. So yeah, plug in metrics have been interesting.

Harald (19:44)
Well, great. Thank you very much for this insight. One more question that comes to my mind is will you maintain or if you can share that. I think you are probably one of the fastest shipping products in terms of release cycle within the landscape of Salesforce products. Do you still maintain that release frequency of every two weeks?

Shane McLaughlin (20:10)
We actually release every week. So the way that works is, so today is Wednesday, which is our release day. So today we have a nightly release that goes out. So if you ever want to play with what we merged yesterday, it'll be there in the nightly channel. So once a week on Wednesday, we promote nightly to become the release candidate.

Harald (20:13)
or everything.

Shane McLaughlin (20:33)
And then that set of changes will stay as release candidate for a week. And so we have users that like to test the release candidate against their deployment pipeline. And that way, if anything is going to break in the next, if we promote that candidate, then they tell us and we can fix it and patch it before it goes up. And we appreciate that so much. And then in that release candidate becomes the official release the following Wednesday. So today we just promoted our candidate. Next week, it'll be the regular CLI that most people are using.

Yeah, we like it. It's interesting because, at least in the JavaScript world, there's a lot of stuff in the dependency stack with other packages and their dependencies. And it's quite often that you'll see vulnerability updates. Someone has a bug or someone has a security issue or whatever, and they'll put on a patch release. And then we want to pick that up as quick as possible and get that into your hands. Because we have some customers like

it, you know, in 99 % of those situations, I don't think there are vulnerability to a CLI. And they're like, if this were running on a public facing web server in node, you might be able to do something. Or some of it is like even things that don't make sense because it's like a denial of service attack type of vulnerability. And you're like, you could do S your own, you know, local machine in lots of, lots of easier ways than using a CLI exploit. But

Harald (21:49)
Hmm.

Yeah.

Shane McLaughlin (22:00)
We don't like those things showing up because people will build a Docker image and then they'll run it through their security scanners and these things will show up. And so we kind of have to patch pretty frequently, even if we weren't fixing and releasing new features. But the other thing you'll see is new metadata types come out for Salesforce for the next major release. We want to get those in so people that maybe they start testing on preview sandboxes and they want to use those new features. So as teams finish their metadata, we tend to add those.

Harald (22:07)
Mm.

Shane McLaughlin (22:29)
The other thing is internal Salesforce teams like to test their metadata with the CLI. And so the CLI needs to know about their metadata. And so that may ship in the CLI six weeks before it's available to users. But that way, internal teams are using the same CLI. So yeah, we have to do a lot of releases besides those things. The other thing you'll see a lot is workarounds for server issues, where there's some new error and it's retryable.

Harald (22:40)
Hmm.

Shane McLaughlin (22:58)
And if we're pulling for like a deployment to complete or something, and there's like some new connection reset errors and like that, we would like to be able to put the work around for that and ship it. And that gives the server side team more time to figure that out without impacting customers using the CLI. It may be a little while before they can release their fix. It may be the next Salesforce major version before they can release their fix. And so it's nice to be able to patch those things.

because they break all of our tests, just like they break your deployments. And there's a lot of releases. Yeah.

Harald (23:35)
But there is a lot of beauty to a fast release cycle.

Shane McLaughlin (23:40)
It depends who you ask. But that's the option. If you like a certain version, like we saw earlier in the telemetry, if you think 7 .200 is fantastic and it does everything you need it to do, you can keep using it. It's still there. Yeah.

Harald (23:42)
I don't know.

You stick to it.

All right, so yes, thank you very much for those insights. It was a pleasure to have you. And yeah, looking forward to what the SF plugin will bring in its upcoming releases.

Shane McLaughlin (24:18)
Great, thank you.