James Simone is a Lead Software Engineer here at Salesforce. One of his great passions in life is open-source software. That is exactly what we will be talking about today.

James was inspired to get into open-source software to help people share code in a more easily indexable, searchable format. This is even what led him to work here at Salesforce. In this episode, James teaches us how we can use open-source software, how to get into it, and some of the projects that he likes.

Show Highlights:

  • How James came to work for Salesforce.
  • What extreme programming is and where it came from.
  • Why enterprises should support open-source software.
  • How second-generation packaging affected Salesforce projects.
  • How to navigate licensing and fair use when working with open-source software.
  • All about Nebula Logger and the logging problem it solves.
  • What Apex Rollup is.
  • How to get involved in Nebula Logger and/or Apex Rollup.

Links:

Episode Transcript

James Simone:
The lines that I’ve heard from companies like Superbase, for example, where the majority of their software, even though it’s a paid application, is open source, and the volume that that speaks to as far as security vulnerabilities that have been caught by people who are simply interested in reading.

Josh Birk:
That is James Simone, lead software engineer here at Salesforce. I’m Josh Birk, your host for the Salesforce Developer Podcast. And here on the podcast you’ll hear stories and insights from developers, for developers. Today we welcome James back to the show to talk about one of his great passions, open source software, how people can use it, how you can get into it, and some of the projects that he likes. But we’ll start, once again, in his early years and some of his early memories with a computer.

James Simone:
Computers started off with my dad having a Windows 3.1 computer with Duke Nukem on it, I think. There were a couple other games on there. But it was the time period where you’d go from Windows into DOS, and DOS would have your game list in there. So it was very exciting time.

Josh Birk:
Right, right. Did you ever get into any Duke Nukem modding or anything like that?

James Simone:
No, I didn’t. But I think I have benefited from Duke Nukem mods as a user, so I definitely look fondly back on that time period. And I was just thinking the other day, too, my dad had a Nintendo, an NES, and in retrospect, I don’t think he ever played it, so was that for me? Because it was there when I was born. And then just suddenly in my 30s now, I’m realizing, “I think that that was for me.”

Josh Birk:
That’s awesome. See, I had the opposite thing. My dad got a laptop, one of the first computers we actually owned. Calling it a laptop was kind of not really true. It was a laptop the size of four briefcases stacked on top of each other. But he was like, “You kids can only use your computers for homework. These aren’t toys. You’re not allowed to play with them.” And then the history would go on, as we got into Commodores and all this other stuff, every computer we ever had, my brother and I were fighting time with him, because he was playing video games on it. Totally not fair.

James Simone:
Well, if it makes you feel any better, I was still fighting for that time, even without somebody else using it.

Josh Birk:
Nice.

James Simone:
Everybody had something.

Josh Birk:
And when did you first encounter Salesforce?

James Simone:
In 2013, I was working for a company that was looking to migrate to custom CRM, actually an old Foxboro application, which had its pros. It had many, many cons, but it had its pros. It was a really fun system.

Josh Birk:
Yeah, Foxboro had it’s fans for sure.

James Simone:
And so we were migrating this 20-plus-year-old legacy system into Salesforce. I met my friend, and, if you’re familiar with the book, the person I like to refer to as my once and future colleague, Jonathan Gillespie, who we’ll get into a little bit more in a second here. But he was leading the charge on that migration. And then he and another one of our developers, I was a product owner at the time, left at the same time, and basically went to my boss and was like, “I think James could do some of this stuff. Maybe you should look into giving him some training.” And made my transition over to starting development on the Salesforce platform as well, which was [inaudible 00:03:43]

Josh Birk:
Nice. And I think this is where you were leading with it, but how did you end up at Salesforce itself?

James Simone:
Yeah, we could go back to the early years and some experience that we had. I think one of the beautiful things about open source and where we’re going with this is the increase in reusability of software, and in particular things for Salesforce, where previously… I love Salesforce Stack Exchange. I love that there’s so much stuff out there, so many results. But a lot of code… When it comes to reusability, there wasn’t really an easy way for people to find non-proprietary pieces of code in any language, Apex being no exception there, prior to the GitHub revolution. And that really kick-started, I think, people being able to share code in a much more easily indexable, searchable format, that even if you weren’t looking for, “I need to do this one specific thing,” which I think Salesforce Stack Exchange is really good for, GitHub opened up this completely new lens of, “Here’s how I would build a sample application. Here are the concepts and patterns that I think are really reusable.”

James Simone:
And at the beginning of that wave, my company was looking to add some additional functionality in the way of rollups to some custom objects that we had. And if you use the Salesforce platform for any amount of time, you’re going to know that out of the box we are limited in terms of being able to add in those custom rollups. And I think it’s also funny… Also, to level set, the time that we’re making this recording is important too, because I really enjoyed the conversation, the unedited conversation that you had with Ian Varley, our colleague, and some of that goes into the details of why this is important and why you can imagine that we have these limits about, “Oh, you can only have three of these rollups per object. It’s got to be master-detail,” when you listen to Ian talk about how we’ve really designed this, quote, unquote, “database” to work. And so we were using this open source software to add in the ability to have these custom rollups be done, and there were some limitations with that.

James Simone:
Fast forward a few years, I was working at a consulting company just prior to coming onboard at Salesforce, and the same thing happened. We were using this piece of software. There were some limitations. A friend and colleague of mine, Erin O’Keefe, who, in addition to being an amazing Salesforce consultant, has an incredible band under O’KEEFE. I would highly recommend anybody to listen to her music on Spotify. It’s amazing.

Josh Birk:
That’s awesome.

James Simone:
But she came to me and she said, “We’re having these issues with this package. We need to jump ship to something that’s more flexible, more scalable.”

James Simone:
And so in September of 2020, in a day I basically sketched out a POC for this rollup application, and it got me to thinking. I was remembering a conversation that I’d had a couple of years back with a friend of mine who came to my team at the time and said, “I’m having problems. I need to export these things to Excel. I have to do all this math.” And a friend of mine and my mentor at the time was like, “Well, wait. This is crazy. Computers love to do math. We can help you do this math for you.” And that phrase really stuck with me. So when Aaron came to me and was asking about how we could create a more scalable rollup solution, I started to think, “Well, at the database level it makes sense that we have these limitations in place. The database is great for many things. Even a pseudo-relational database is so great at storing things and having them be retrieved by keys. But when it comes to doing math, is the database really the layer that you want to be doing that?”

James Simone:
And so having built out this little POC, having had the chance to prove that it was going to work, it was going to be faster than something that was going to be using [inaudible 00:07:54] under the hood, ultimately, I had the idea for Apex Rollup, that we could basically recreate all of the existing rollup logic and even some new kinds of rollup-based operations by doing that straight in Apex, where the CPU is great at doing things like math.

Josh Birk:
Got it. I think you’re almost to the point where you’re answering the question.

James Simone:
Yeah, yeah. Sorry. TL;DR, I took two weeks off of work at the end of 2020. And again, to level set about when we’re having this conversation, you’ve just released the two-part series with Joe Stern on mental health. The second one came out earlier this week. I think it’s funny to look back on 2020 as a time period in which anything happened other than the pandemic. And at the time, the way that I was dealing with things was by trying to give back. And I had the chance to take some time off from work at the end of the year, and I really wanted to create something that would be useful for people. So I took two weeks off of work. I made Apex Rollup, and basically…

James Simone:
I think I had talked to you about this last week. I woke up from some kind of fugue state where I had just been heads-down programming for two weeks straight. And I had an email from my now boss at Salesforce saying, “Hey, took a look at the repository. I’ve read some of your articles. I’d really like to talk. I think that there’s an opportunity for us to work together here.” And so that was such a moment of serendipity, and especially following so closely on the heels of having released this software out there. It really felt like the crazy culmination of several years worth of working and driving towards this.

Josh Birk:
Right. Did you have a sense of disbelief that somebody actually connected you-

James Simone:
I thought it spam. I was like, “This couldn’t possibly…” It looked like, “Hello, I’m a Nigerian prince and I need your bank account information.” This is a chance to interview with Salesforce? And it’s the person who I would be working with, not just some recruiter [inaudible 00:10:07]

Josh Birk:
Random recruiter from LinkedIn or anything like that. Yeah. No, that’s awesome. How would you describe your current role, then?

James Simone:
It’s pretty radical. I think we talked about this a little bit last time. Our team practices something called mob programming or ensemble programming. We are on a video call all day, with the exception of the time that I’m talking to you. And we have developers taking turns at the proverbial wheel. So we do 15-minute programming sessions where one person is just the conduit to the computer. They’re the typist. They’re listening to input from a navigator, and the navigator can take input from everybody else that’s there, both technical and non-technical people.

Josh Birk:
Nice.

James Simone:
And we are doing that all day.

Josh Birk:
That’s really pretty cool. It sounds like… We’ve talked about pair programming, extreme program, all this kind of stuff. Is that a discipline that arose organically at Salesforce, or is that something that is a version of Agile that some people maybe just haven’t heard of?

James Simone:
I think it’s a version of Agile that people probably haven’t heard of. It’s the sort of thing where you look back far enough and you can see the evidence arising out of the extreme programming movement that Kent Beck had started. There is this guy, Woody Zuill, and I would recommend for people who are interested in learning more about mob programming to listen to a podcast that he was recently on with a change log where he goes into the history of how he coined the phrase. But I think that people were starting to do this, recognizing, “Okay, well, extreme programming or pair programming, it works, but how do we scale that?” And so this idea, “Oh, well, why don’t we just have more people be a part of the process?” is one of those various flavors that you might choose to experiment with as you try to scale something like pair programming out.

Josh Birk:
Gotcha. Very cool. So before we get into Apex Rollup itself and some of your other projects, I want to level set a little bit about the philosophy and the culture of open source software, because I know that there was…

James Simone:
Absolutely.

Josh Birk:
Some companies have opinions, and some companies are like, “Why would I pay James to write software that he’s then going to go share with the world? That’s supposed to be our strategic advantage. Why wouldn’t we just keep all of James’s brilliant stuff to ourselves so that we have an advantage over our customers?” But feel free to either respond to that or flip it on its ear. In your mind, what’s a good, mature attitude from an enterprise on open source?

James Simone:
I think it should be supported as much as possible. And I think the reason for that… There are so many different angles that you could approach this from, but ultimately, when you look at community outreach and how a company is perceived, so much of that perception is formed around people’s actions that are part of that company in public. And open source is such an excellent flavor for that. It’s a chance for people to contribute back.

James Simone:
I think for Salesforce employees in particular, or anybody who is in the ecosystem, just being able to expand upon what is already such a powerful out-of-the-box experience can only be a selling point for the product. And that selling point, yeah, it’s great for us as a company, but it’s also great for you and your personal brand. If you can arrive at some functionality that’s needed and be of the mind that the best thing that you can do is give it away and support it, I think that’s a really powerful thing to do, and it speaks volumes about your own character and your own capabilities that collectively, again, we all stand to benefit from, but it can only be good for you as well.

Josh Birk:
I always think of it akin to back in the browser war years, when you have two companies, two enterprises. You had Netscape. You’ve got Microsoft. They’re off in their own silos. They refuse to talk to each other, and they’re basically balkanizing the web. And then you look at it today, and we can see how much better the experience is, because those companies are around the same table, sharing the same ideas, having the same arguments, but eventually coming up with the actual standards. And so, I mean, is it overly simplistic to say one value a company would get from this is simply better software?

James Simone:
I don’t think it’s overly really simplistic to say that. I think that even if you didn’t use any part of open source software that you investigated, purely by virtue of investigating it, having a process that exists that you’re able to vet things as usable or unusable or as inspiration is also going to be so helpful. Even if the lesson that you learn is just, “Oh, well, there’s a security vulnerability in this, so we can’t use it, or we would have to redo that portion of it,” there’s always going to be something that you can take out of it.

Josh Birk:
Right. Well, and so that follows up to my next question, because… And maybe this is one of the defining lines where it’s like, “No, we don’t feel comfortable making this open source,” but it almost… You hear the, “Well, is the software less secure because everybody can see it, and therefore everybody can try to figure out how to hack it apart?”

James Simone:
I mean, you could make that argument. I think that ultimately you have to be operating fairly close to the metal to eliminate any instances of security vulnerabilities. And I think that I would fall back to the lines that I’ve heard from companies like Superbase, for example, where the majority of their software, even though it’s a paid application, is open source, and the volume that that speaks to as far as security vulnerabilities that have been caught by people who are simply interested in reading through things and contributing back. So there’s always going to be two sides to that coin. You’re either way more insular and right obfuscation is your primary defense, or you can hope that the number of good actors out there is higher than the number of bad actors.

Josh Birk:
Than the bad actors. Exactly.

James Simone:
Or that [inaudible 00:16:47] bad actors are less successful.

Josh Birk:
Yeah. And there’s no data security nerd who doesn’t flinch at the term “security through obscurity.” [inaudible 00:16:56]

James Simone:
It is a strategy.

Josh Birk:
It is a strategy.

James Simone:
Is it a winning strategy? I don’t think so.

Josh Birk:
I don’t think so. You had better be really, really, really, really obscure. But the fact is, if there’s a security flaw on your software, there’s a security flaw on your software, and I would rather have people pointing that out to me and helping me fix it, as opposed to waking up one day… This is actually how I got out of data security, was the fear that I was going to wake up one day and the extranet that I had built out of C++ that I was learning for the first time had some fatal flaw on it. And you don’t want to learn that because somebody just hacked your company. You want to learn that before you [inaudible 00:17:36]

James Simone:
Ideally, yeah.

Josh Birk:
Ideally. Ideally.

James Simone:
And isn’t it nice that in 2022 we can take the time to say, “I was scared, and I didn’t know, actually. Even though I am trying to know everything, how could I possibly keep everything safe all the time?”

Josh Birk:
Yeah, exactly. Exactly. My fear was that there’s always that one thing. There’s always that one thing, and I would rather have that one thing be something like my modal dynamic HTML window didn’t work quite correctly, as opposed to I actually exposed somebody’s credit card or something like that.

James Simone:
[inaudible 00:18:08]

Josh Birk:
Exactly. Exactly. So coming back to Salesforce a little bit, we’ve had a lot of movement when it comes to packaging and reusability. And how do you think things like second-generation packaging has worked for OSS and GitHub and being able to share these kind of projects?

James Simone:
I think it’s an enormous opportunity for people. I know that I have personally benefited from it. I think it’s funny to think about some of the stuff that I had released open source between the years of 2017 and 2019, prior to 2GP really starting to take off, where the best thing that I could hope for was either that someone was going to clone the repository and deploy the metadata in whatever their favorite format was, or I might have some click to deploy button on there, but there wasn’t a good enough feedback loop there. It makes it so much harder for somebody to upgrade, to uninstall pieces of your application that you’ve since deprecated, just the quality of life stuff that went into the development process.

James Simone:
I’m just flinching even to think about it now. I’d probably be writing up these change log notes like, “And now you need to go to this piece of metadata and remove it from your Salesforce org.” That’s just not fun for anybody to do. It’s not fun for me to write that. It’s not fun for you to do that action as a post-deploy step. And packaging has really revolutionized the way that people can both install, upgrade, and uninstall these kinds of applications into their system.

Josh Birk:
And what’s their touchpoint there? Because we’ve moved this all down into the CLI, where you can tinker with it in terms of packaging, talking to GitHub and making that reusable. But you’re not doing things like tinkering with the metadata anymore, right?

James Simone:
Right. I mean, the touchpoint… It depends. It’s going to be what your comfort level is. We still have these vanity URLs in every org, where you pass in a package ID, and you would be presented with the GUI that’s going to walk you through, “Oh, this is what the version description is, and here’s your full list of metadata.” And that’s a very admin-friendly approach to being able to install and upgrade applications. But if you’re comfortable, yeah, the easiest and fastest way to do this always is going to be through the CLI now, and that’s just a quality of life thing.

Josh Birk:
Nice. Just one question in general… People are starting to get involved either from a development point of view or a, “I’m going to go browse some GitHub projects to see if I can…” Okay, it’s not build or buy. It’s build or clone, I guess. Let’s go with that. But what should people think about when it comes to terms with things like licensing and fair use and making sure that they’re working within the spirit of the open source community?

James Simone:
Yeah, I mean, I think maybe I would phrase it as build or fork.

Josh Birk:
Okay. Yeah, I like that.

James Simone:
If you’re not okay with the terms that have been applied, most licenses in open source are going to basically say, “If you’re going to fork this, then all these other statements are waived. Go nuts with any changes that you want to make. But by the way, you’re going to have to opt into any kind of upstream upgrades and do that kind of resolution yourself.” So the benefit that you get there if you were saying, “Okay, I want to take most of this application, but there are a couple things that my company needs or my team needs that are… We need to do these changes.” Those are the risks that you run, as opposed to doing something which I would describe as the more traditional object-oriented approach, where you encapsulate those things at the edge of your system, which leaves you able to hopefully upgrade things without actually touching things outside of that interface layer in your own system.

Josh Birk:
Gotcha. I guess to follow up on that point itself, are there avenues people can get into that might get them into trouble if they use open source in a particularly wrong way?

James Simone:
I think that that mostly comes down to the fork thing. If you’re saying, “There are things about this solution that I personally need to change, and I don’t want to have a boundary in my software where I’m writing an interface that is going to be the adapter for working with this third-party piece of software,” then yeah. If you’re going to fork something and go off and change things, you run the risk of either introducing a regression that didn’t previously have coverage for, so those unknown unknowns that of course always pop up, or you leave yourself vulnerable to not being able to accept upgrades in the same speed or format as other people. And that could be fine if the functionality that exists today at the exact moment when you do that [inaudible 00:23:35] is everything that you’ve ever needed, and you only need to continue to build upon things that you don’t expect the original author or team to support or introduce in the future. It’s really that upgrade path that becomes the big pain point, especially when those upgrades are things like closing security vulnerabilities.

Josh Birk:
Right. Exactly. Well, throw that on the flip side. And I think we’ve covered this a little bit. How much do you see, in successful open source projects, people not going that route, but going the pull request route? And is there a correlation between the size of the active community and the success of the open source project?

James Simone:
It’s the classic chicken and the egg thing. Is this project successful because people are highly engaged, or did people become highly engaged as the project grew in success? And the example that I love to use for this is, again, going back to our colleague Jonathan Gillespie’s Nebula Logger, which is the most starred logging framework for Salesforce on GitHub. I mean, Nebula Logger has experienced an exponential increase in growth since the start of the pandemic. I mean, it’s really taken off over the past two and a half years now in terms of people using it, in terms of the size of the organizations using it. We use it, for example. It’s just the scope at which the usage of Nebula Logger has increased over the last several years is incredible. And to some extent, I think that the contributions are tied to that number, but I don’t think that that… It’s hard to measure which part start the other. Were people starting to contribute because all of a sudden they found this tool, and then through them contributing it got better, and now more people picked up on it? I have no idea.

Josh Birk:
Or a little bit of both, perhaps.

James Simone:
Yeah, maybe that’s the happy middle path that we can walk together.

Josh Birk:
Right. Well, tell me a little bit more about Nebula Logger. How did you discover it? Well, [inaudible 00:25:41]. That’s interesting that you said that its use was heavily upticked during the pandemic. Do you think that’s coincidence? Or was that just sort of a shift in perspective to what people were looking for at the time?

James Simone:
Probably the latter. It’s always an interesting thing to think about. And I’d love to get Jonathan on here as well to speak more about it, because it’s really his baby and his project. I discovered it because the initial version of it was something that he created while we were working together at our original company some… Oh my god. Nine years ago now. Crazy to think about. [inaudible 00:26:19]

Josh Birk:
We’re so old. We’re so old. I know.

James Simone:
Oh no. That just got real. Yeah. And so I was always aware of it in the background. And then when GitHub really started to become a big presence in the open source community and Jonathan launched it there, I think that there were people that got there and were interested in finding somebody who had already solved this particularly thorny issue, especially as you start to integrate things like low-code and code-based logging. How can you consolidate those things? And I think that Jonathan really had hit upon the right combination of those two things at exactly the right time. And the growth in the meantime… Again, I’d love to have him speak more to that thing. But I do think that it is interesting that it happened during the pandemic, such an enormous increase in usage, and I think we could probably spend a lot of time talking about why that might be.

Josh Birk:
Yeah. Well, I’ll look into getting him so he can talk about the impetus and the growth of it and things like that. But go back to that part you just said. The solution that it’s trying to solve, is it the low-code angle? Is it a really popular logger because it’s simply easy to use and configure? What’s the logging problem that it really solves?

James Simone:
The logging problem that it really solves is being able to track the details across low-code and code-based things into one specific log entry.

Josh Birk:
Interesting.

James Simone:
So you have this parent record that ties together a lot of different log entries that could be called from Flow, from Apex, from Process Builder, all these different [inaudible 00:28:02], or Lightning Web Components, and tie them all together as long as they’re part of the same transaction. So you really start to build up, for especially your mission critical processes or things where you expect errors to occur, this rich audit trail of, how did we get from point A, where everything was fine, to point B to where everything was decidedly not fine?

Josh Birk:
Decidedly not fine. So it sounds like it removes those weird blind spots if you’re coming from an Apex-specific logging system, because then Flow took over, did a whole bunch of stuff, and now you don’t know if it’s the one that struck the match or something. It catches all of these potential culprits.

James Simone:
Yeah, exactly. Like how did this… Things got rolled back. That much we know.

Josh Birk:
Mistakes were made.

James Simone:
Yeah. Also, news break, we are not perfect. We’re perfectly fallible, and now we need to recover from that.

Josh Birk:
Right. Okay, now let’s get into Apex Rollup. You went into a little bit of the detail, but what was… Well, actually let’s go into the elevator pitch. What’s the elevator pitch for Apex Rollup itself?

James Simone:
Yeah. I would say the very short pitch is, you want to be able to add custom rollups to any object, even objects that aren’t related by lookup relationship. Any text field that has a key value that matches a value on another object can be used. So it’s not just a lookup based rollup solution. It’s really any key value pairing can be used. So you can set up these rollups. They can actually span across entire object hierarchies. So for example, if you have a grandchild record that has a parent-level relationship, and then that parent has a relationship to a grandparent above that, in most other rollup solutions, if you needed to roll data up from the grandchild to the grandparent, you would need to have intermediate fields on the parent so that you could then roll those up subsequently to the grandparent. In this solution, you can do just child to parent rollups. You can also do great-great-great-grandchild to grandparent rollups. So you can go up as many levels as you need to without having to store that data on individual fields.

James Simone:
And in addition to that, there’s a larger variety of operations for rollups that are allowed than the things that you might get out of the box. All of the out-of-the-box ones are supported, your sums, your counts, your mins, your max. But then there’s also things like first and last and concat that are supported, and those are some really interesting operations for being able to rollup richer, non-number-based fields to their parents or grandparents or what have you.

Josh Birk:
Interesting. What’s the silver bullet example that you would give that’s like, this is an elegant solution because you needed to tie one data point to another point data point. What are those two data points?

James Simone:
A fun one that I like to talk about, because it’s not supported out of the box for reasons that are just there, something like a min or a max of your task activity dates. You can’t using [inaudible 00:31:34] do a min or a max on the task activity date field and roll that up to an account or an opportunity or whatever you’re tying tasks to. With Apex Rollup, that kind of operation is supported out of the box. You can configure that rollup using Apex. You can configure that rollup using custom metadata. You can configure it using the Flow. And that kind of operation, which previously wasn’t possible for you, may open up some new avenues for things like reporting and, again, allow you to have a more holistic solution that takes advantage of all these incredible out-of-the-box things that we have on the platform while souping up that functionality and giving you better access to your data at the level that you want it.

Josh Birk:
Right. Now, this is an example of something that I’m very glad we have somewhat of an administrator audience for, because it seems like something that an admin wouldn’t even think would be possible. How admin-friendly is this? Do you have a handy Lightning Web Component that they can just throw into Page Builder?

James Simone:
Yeah, there’s a Lightning Web Component that you can use to just recalculate things for one parent record. The admin-friendly routes, I would say, are bifurcated into these two different approaches, one being setting up your rollups through custom metadata, and the other being setting up your rollups through Flow. Those are really going to be your chief avenues for starting the rollup process as an admin. I like to refer to this as the Google Analytics installation, where if you’re not going to be using record-triggered flows to call Apex Rollup, then you can install, quote, unquote, “install,” since you’ve already done this, Apex Rollup into any object by adding one line of code into your trigger or trigger handler class.

Josh Birk:
Got it. Nice. That sounds like you’re… What’s the phrase? Something like you’re combing through the desert. How scalable is this? Are there specific limits when you’re going from a cousin to cousin style relationship?

James Simone:
Yeah, there’s one type of rollup that is allowed through Apex Rollup called a one to many, where you can actually roll data up from one parent to another parent through children records, if both of them have the same [inaudible 00:34:04]. But there’s really very little in the way of hard limitations. The system is designed to scale infinitely with the size of the records that you have. It basically under the hood does things like use a cueable or use a batch job, depending on the size of the record set. And it tries to optimize for things like speed when doing these rollups based on the size of that record set.

Josh Birk:
Got it. And kind of tying it all the way back to the packaging question, if people are interested in Nebula Logger, or they’re interested in Apex Rollup, what’s the easiest way for them to get either involved or get it up and running?

James Simone:
You can go to nebulalogger.com, which will take you straight to the GitHub page. Classic bait and switch. Or you can visit the Apex Rollout GitHub page as well. We both have what I would like to describe as fairly comprehensive wikis. Mine is probably a little bit more dense, and this is a call to help for anybody who’s interested in helping write some more clear and concise technical documentation, which is, as you well know, a skill in and of itself.

Josh Birk:
Exactly.

James Simone:
But our GitHub pages are probably the best places to start with these things.

Josh Birk:
Very cool. Follow-up question there, because you said app exchange. How do you think open source software… Build or fork, right? A lot of the attraction to these solutions is that they’re things that have community with them. They have upgrade paths. They’re already solving problems. I don’t have to rewrite the wheel. How do you feel like these projects line up with the app exchange?

James Simone:
I think there’s room for both. And I think Nebula Logger is a great example of a project that both has an app exchange listing and is also available as a second-generation package. So with the managed package version available on the app exchange, you are tied to the same release schedule as the Salesforce release schedule. So you’re going to get three releases a year. The managed package is going to be maintained at that same interval. It’s going to be upgraded every time that Salesforce does a big release. The benefit of something like that, of course, is that you can go through the app exchange and read everything there, have the listing be there. The second-generation package model, I think, is at this point a little bit more flexible in terms of how you can upgrade, how frequently you can upgrade, all that good stuff.

Josh Birk:
That’s our show. Now, before we go, instead of asking after James’s favorite non-technical hobby again, I asked him what hobby he had never picked up that he really wanted to.

James Simone:
Yeah, I’ve always wanted to learn how to play the guitar. I’ve never spent the time necessary to do so.

Josh Birk:
Yep. I thank James the great conversation and information. As always, I want to thank you for listening. Now, if you want to learn more about the show, head on over to developer.salesforce.com/podcast, where you can hear old episodes, see the show notes, and have links to your favorite podcast services. Thanks again, everybody. I’ll talk to you next week.

 Get notified of new episodes with the new Salesforce Developers Slack app.