Podcast Episode 158: Episode 131: The Story of Rock

Description

Have you ever wondered about how Rock began? Join Jon, Nick and Emily as they travel through time on this epsiode of Rock Cast,starting with the latest feature updates before heading back to the very beginnings of Rock. The technology has changed a lot since Rock's early days (it wasn't creepy back then!), but God's faithfulness and provision has remained at the heart of our story.

Transcribed Content

This episode of Rockcast is brought to you by Rock partner Triumph Tech, a full service specialist partner. Rock partners provide crucial support for Spark Development Network and important services for the Rock community. Connect with Triumph Tech today at rockrms.com/partners. Welcome back to Rockcast, the podcast where we take you behind the scenes with Rock. We'll tell you where we are, where we're going, and today we're gonna tell you where we've been. I'm Emily Forman. I have Jon Edmiston and Nick Airdo here with me today. Lots of exciting things to talk about. It's going to be a little bit of a throwback episode, which we're excited to discuss. But first, let's start with where we are right now. Nick, can you fill us in? Yes, I can. We just completed the beta for version 13.4, and it will go out well. By the time you hear this, it will have already been out. And we, again, had some really good last minute beta participation and found a few more things that we were able to squeeze in into that release. Relatively minor edge cases, but still we don't want to ship it with those weird things that we know about. So those are fixed. And let me just give you a little quick synopsis of what is version 13.4. It's got 15 additions that we've classified as ads. It's got 22 improvements or updates to existing features. Some of those are also considered fixes or enhancements. We sometimes take an enhancement that somebody opened up as an issue and we're , well, it really wasn't built for that, but we're going to adjust it so it can work that way. So 22 of those things, and then 58 fixes. So we made a pretty big effort over the past few months to really chip away at the issue list and a bunch of fixes are now in version 13.4. That's great. That represents a ton of hard work, know. Yes. It was a nice long build. In fact, we've been working on that for longer than version thirteen three was, although it was released in April 21. Were still working on version 13.4 when that was released. So it was pretty long release, I'd say at least three months. So a big thank you to our testers this time around. It sounds they have been invaluable. Yeah, huge, huge amount of help for those guys to just run through on their systems or test systems, copies of production, just kicking that all the features and making sure everything's still working. And it sounds what some of the value that was provided in this time was, was extensible or edge case ways of using something that just kind of reiterates how important it is that we have the actual churches of the community testing things, because they're all using Rock in different ways and have totally different data. Yeah. And even plugins, it's important that you test the plugins that you're using against that version. Now, vendors, the third parties that are making those plugins, really they're supposed to be testing, but man, you should also double check their work. In fact, we did find something late in the game. Thankfully, we were able to make an adjustment to compensate, but yeah, it's always good to test all of your things and all of your extensions. If you rely on it, you should test it. Yeah. All right, thanks Nick. That was a great update. It sounds we've got a lot packed into that dot release. John, what can you tell us about what we're working on now? Yeah, so we've been obviously working on thirteen four, but also putting a lot of the final touches on the major features that are going into '14. So the point we're at right now is we finally have the ability to run a lot of the of the pieces of the update that require database changes. So it's really a super technical topic, but sometimes we can't make those changes until we get through a lot of these point releases, the 13.3s, the 13.4s, because we wanna reserve the right to make some types of database changes in those releases, those point releases. And so now we've kind of drawn the line and say, okay, no more big database changes in the 13 dots. And now that will only happen in 14. So we're going back through putting in a ton of those database changes that have been building up over the last probably six months. So this week is going to be a big week for that, getting those done, and then starting to do a lot of the testing for those. There's still two major features in 14 that still need some more development, so it's coming along pretty well. So we're happy about that. But we're also at the point too where you can't have every developer working on just two features. So there's some development time that we're putting towards knocking out some ideas from the community, some more issues while those two major features get the final polish. It's at this stage too that we start putting in other features that we didn't promise, but we want to put in. So there's still lots of room for surprises for 14. Christmas is coming. Yeah. Sometimes with the big features, they just take time. So while those are getting worked on by a smaller set of the team, the rest of the team can move on working on other things. So it's definitely playing Tetris with project management. Yes. That's a really good way to look at it. Sometimes when we interview people ask, would you use Agile? And it's , sometimes you, it's hard to explain it to them, but it's , gosh, you wish it was that easy that you could just every two weeks just say, this is what you're gonna work on, but it's every day, it's something different that we have to shift our priorities to that it's either an issue that is impacting somebody, we wanna knock it out and or it's , oh, we gotta get this in because of that database migration. Think being that responsive is good. it really helps a lot of the community, but it does make project management a little more challenging. Yeah, and sometimes people talk about Agile and I think the output of Agile, in my opinion, is very responsive development. you can develop quickly and get features out to your audience. If we definitely pass that test, that's what we do. Is it traditional Agile? No, it's super Agile, I call it. Yeah. Imagine what that's done for over time, the speed and the quantity of the features and fixes that have gone out. It's just been an exponential improvement to what would have been possible. Yeah, I mean, a lot of times we're fixing issues within days of them even being reported and sometimes even within one day, we just put something in the 13.4 that was a last minute thing. It would have been easy just to say, Yeah, we'll just wait till thirteen point five, that's a big deal. But , the distance I don't know. I would I would prefer not to have to wait if I was sitting on the other side. There's ways you one could get around these things, but it's , well, it's almost easier just to fix it than it is to communicate ways to work around it. Sort of ties into our next topic. The fact where we came from and what Rock's all about, that's important to us. Being able to be responsive to somebody's needs, because we were all there. We were all on the other side of a vendor in a product. So we really wear that on our sleeve. Yeah. And every vendor would probably say, well, we're not a vendor. We want to be there with you. But I've never really seen that. To a certain point, there might be edge stories that you could tell, but I really feel this is very different. We are actually in the community every day. We're a lot of times helping out with projects in hundreds of churches. I mean, not a day that doesn't go by that I'm not personally engaging with a couple people in the community trying to either solve a problem, give an idea, fix an issue, better understand something. And it's sometimes really hard too, because as it scales, it just gets harder and harder to be able to do that. But I think that is what makes Rock different is it's almost our DNA is not to put build a wall between us and the people who use the product and the community. It's we see ourselves as , well, we're on the same team. Again, it's hard to say that because every vendor, I think every system builder would say the same thing, but I think it's radically different when there really is no wall. Yeah, and I wonder how many of those other products and vendors started with a prayer, for me, and again, I only have a small involvement in this puzzle, but I remember very, very vividly where I was sitting when I heard the story of Nehemiah building a wall, and it's a great inspirational story, and it became Nehemiah's holy discontent. And so for me, I internalized that and I said, God, this is what is wrong. Why don't we have software that is as good as the enterprise software? And at the time, there was, without going too far on a tangent, enterprise software, as we now say, isn't all that great, but we wanted to build something that was worthwhile, worthy of the kingdom, worthy of the king. And it was a cry for me personally. And this was before I really even knew John. And so I always had this yearning that , why can't we contribute to something together, across the spectrum of a bunch of different developers? And it just so happened, coincidentally, I was at CCV when that presentation from the leadership summit was given. And I think shortly before or after that, I'd kind of met John. Yeah, and I think what's interesting is when I started back at CCV and back being hired on, I didn't want to create software for churches. That was the last thing I wanted to do. Because I don't know if that's Really, that's not in the best interest of Of the church. Of a church. I agree. It's , why write it yourself? , man, you just set yourself up for failure. It's you get hit by a bus or or you decide to go do something else. you really leave them in a lurch. Yeah. And so I I was volunteering mainly just to make their website. And so we did that and it was pretty cool, but it was I mean, the bar was really low, , back then, this was 1999, '2 thousand, so the bar was pretty low for what the website had to do. But we just kept building from there, and the problem there was that there wasn't anything to do a lot of these things that we wanted. Back then, the senior pastor, Don Wilson, was really big into making neighborhoods a thing, and there was just no software for churches or even really for anything that would just give you that really high fidelity geospatial view of where people live so you could connect them. And so we just thought, well, okay, well, we better do this and we better write this. And it was really fun because we got to work with a lot of GIS tools. And that was back when the world wasn't really a Google Maps. It's the dark ages of internet. So it was pretty much all ESRI, ArcGIS. And we just got really into that. We worked with the county to get a parcel map of every parcel of land within the county, which is cool. When you get into that, it's free data. For the most part, they'll just charge you $20 for the CD went on. That's how you got it back then. You couldn't download it off the internet. Had to go down to the flood control place and buy your CD at the desk. And then we just made these four foot by eight foot maps of everybody's parcel in our area of town, and we shaded it if you went to CCV or not. Wow. A lot of people are probably creeping out by that, but back then that wasn't a creepy thing. Trust me, was , people were just wowed by it. They were just , wow, this is so cool. Can see, oh, this is my neighbor and they go to CCV2, I didn't even know that. And again, that sounds very, very creepy, but back then it wasn't. Right, you had it in the lobby, right? As people come out of service, they could see, oh, look at that, there's- We printed up a whole bunch of them and you could just walk up and see where you lived. And people had really enjoyed finding themselves on the map and then seeing everything. And now you did that. You'd have a lot of people trying to sue you or something. It was unifying back then. Yeah. Yeah. And so then that moved into doing it online so that we could get those same parcel maps for our staff. And then we started writing software to connect them because , okay, well, how do we get these people into groups? Because the groups all had to be. And next thing you knew, we kind of had a church management system because we didn't have Check-in was new back then. There weren't really digital check-in tools. This was even before Fellowship One was a thing. So we just kind of kept, well, nothing's for that. I guess we better write that. Next thing you knew we had it pretty much a church management system on accident and some other people wanted it central and- Yeah, I could say we pestered you a little bit. I had this vision, this dream of collaborating and then you guys were so far ahead. I think I just pestered you until you did that initiate then moving to selling that? No, I mean, I think it was just when someone else wants it and especially it's a church, , oh, how do you say no? It's , sometimes we did say a hard no, because we knew that they couldn't We knew what it was. And it's , Okay, this is not something that would be helpful to you. I mean, obviously you guys had skill sets where you guys could do it and you understood what you're getting into. Yeah. But most churches didn't. So, yeah, that was , okay, well, there seems to be interest here. So someone approached us about wanting it and we went down that path. And at that point we did try to make one plea to say, Hey, can we open source this instead? And the leadership of the church was , We just don't feel that's what we want to get into. That sounds a lot of support. I think- It was the right They were right. At that time, open source was not it was today, it was confusing, and it probably would have turned into exactly what they were fearful of, is that we would be the support for it. And as much as we kind of wanted to do that, I think that literally was the best decision at the time, was not to open source it. And so we went down the path of selling it to an established church software vendor, and they turned it into a product. They hadn't really been able to innovate into a newer stage, and this was kind of a way for them to jumpstart that. Yeah. So, we were a part of that and we kept developing for that. And my church and many, many others followed suit and jumped onto that. At that point, that's when I kind of latched on and said, well, we're gonna make a community between all of us churches. Let's collaborate together. , me build something that also works for your church if you want it. And I think that was an important piece of the puzzle back then. Yeah, it really was. But at the same time, was the biggest creator dissatisfaction, I think. Because when you get people together and they collaborate and they have ideas and the ideas can't get put in, that creates tension. And that's what kind of created tension for us is that sometimes we were finding ourselves in an awkward situation where we had rights to put code into the product because we needed it for ourselves. But then we hear someone saying, Well, I really want that. And you're , Oh, that's a really good idea. And , Yeah, but no one else thinks so. And then it's , Okay, well, we have an open door, so we'll just write that in there. Slide that in. But then we become, almost what the church leadership didn't want us to be is support for other churches. And that's where I think after a while we decided, okay, this really isn't that helpful. this is causing us a lot of stress and it's not our thing anymore. Right. You can't control the vision of it anymore. Yeah. Literally doing someone else's job and and, maybe we just don't also to understand all the things that they were trying to prioritize. I think there were different norms at stake, market norms versus down in the trench norms of getting ministry done and I don't pretend to know all those answers back then. So we just kind of said, Well, that's enough. We'll just figure something out. But that's where God moves because in that time we had a contract. Obviously, everything is a contract if you sell something and it would kind of bound us. we are, we had to basically say we couldn't go do something else commercially. So we said, well, okay, maybe we could just do something else and get out of this contract. CCV's leadership was , Yeah, that's fine. We understand, open source had come a long ways and we understood it better and there were better models for it. And so CCV's leadership, Yeah, we could do another one and would open source it this time. The money that we're making on this isn't why we did this. So the money is not even a consideration. So we asked if we could get out of the contract, , Hey, you guys keep your money and we'll just do something else or find another way. They're pretty shrewd, so they said no. Just probably the right answer, I guess. It's only one that makes sense, I guess. But we thought, Oh, well, we'll just keep working on it on our own time. And eventually when contracts expire, we'll have something and Which was gonna be seven years later. Yeah. But you think it's a long path and Yeah. So you're , okay. So it wasn't but a couple months when they came back to us and said, Hey, the way we're paying you is kind of hindering some of the models that we can do. And do you mind if we adjust that? You'll probably make more money this way. And again, the church stepped up , Hey, we don't really care about the money. It's not the money that we're doing this for. And if we just said, walk away, don't do any contracts. And that's what we did. So God stepped up and said, Hey, he can move mountains and he will. But you just got to trust and be on his timeline. It wasn't in our timeline. So sometimes we could get frustrated, but we don't have to, just let God do it. It certainly looked an insurmountable hurdle at the time. Yeah. I mean, it was just a matter of months. Then after that came up, it was a matter of hours before everything was just done. And that allowed us to kind of move on to do something else. Yeah, I remember meeting with you. You guys called us out because my church was fifty minutes away. We met in between and you're , okay, we had been working on something, but it was PHP and you had just decided we're just gonna throw it out and start over. Yeah, I mean, back then, it's hard to talk about these things because nowadays it's , well, but you have all these other things. And so PHP, to do the type of development, component development we wanted to do, it just didn't support it very well. And it's not to say it can't today, but I mean, this was a long time ago. This was over ten years ago. We're trying to do things with MySQL, but going back to what I was talking about earlier, geospatial is really important for us. And MySQL was terrible for geospatial. And it knew it. It knew it had actually bugs in the Geospatial code and there are fixes for that, but they weren't being accepted into the product because it wasn't a big deal to them. You gotta focus on what you wanna focus on and Geospatial was not that. Ironically, what was really good back then was Postgres for geospatial. But Postgres, you couldn't find anybody who would host Postgres for you back then. And we really wanted to make sure that whatever we built was something that church could go get hosting for fairly easily. And so Postgres really wasn't an option. Now the tables have turned, Postgres is where it's at. And it's only because Oracle bought MySQL and then slowly destroyed it, that Postgres even got more and more traction and more and more people fled over there. So a lot of times, looking back, you're , Oh, that would have been the smarter move. It's , yep, but that wasn't what the data at the time and kind of would have been nuts to use Postgres back then. Yeah, probably would have hampered the seed from growing. Yeah, nowadays we would have a lot of savings and licensing costs. But in 2020 hindsight, that's the thing, these things don't make sense unless you were back then. But it also goes back to a leadership principle. Well, if you look at a decision back then and you don't it, well, it was made with the best intention with the best data. it wasn't And so sometimes I think we look at decisions and sometimes go, well, that was a dumb decision. It's , well, people rarely make dumb decisions on purpose. Sometimes there's people who just don't look at all the data or who just move too fast. But if someone was a well considered decision was never dumb. In hindsight, it might turn on that to be the best, but we don't have time machines. Yeah, we switched it back to something that we are more familiar with that had component based development. And you pretty quickly then put together a core content management system that you then started to build pieces on top of. Yeah, and I think it's that extensibility that we build with that makes everything hard. nothing is rigid. And so if you open up any development book, it's kind of , okay, that's great. But they always start with , okay, and build the login page. It's , no, you can't. You have to first build a CMS on top of it so that you can have login pages and you can have login block that you could put on any page and put any other blocks on the page. And so I even remember thinking about that again when we were doing Rock Mobile, it's , oh gosh, every book is , okay, now make your first page. It can look this. Hard coded static. Yeah. It's nothing is static that. And it makes it harder, takes it longer and it makes it harder to perform too. I think one of our biggest performance things is our best feature, which is attributes. I mean, imagine if you had Rock and you could not add attributes, you were just stuck with the properties that we gave you. You couldn't have workflows, you couldn't have person attributes, group attributes. I mean, it would just be so Yeah. But that make it's really hard to get attributes to perform fast because they You can roll them out fast, but you can't get them to always to perform fast. Yeah. Trying to do reporting on that's been very challenging and it's working and it's pretty fast. And we actually have some new stuff coming that's gonna make them way faster. Yeah. But it's really hard. Sometimes people are , well, I don't know why that can't perform. It's If you only knew what was going on behind the scenes. Yeah, I mean, we could And if all we cared about was ourselves, we would just add it as a property. If it was just one church, oh, add it as a property. Now it's ridiculously easy to make it fast and edit, but we don't do that. , because what one person wants is very different than what another person wants. And you'd have other problems over time going down that path. Your person model would be totally bloated, but But the community was a big piece of it back then. Obviously, everybody, even before there was a one O, there was a community discussing, talking, testing. That was a major component of what we did and it changed the way everything works. The responsiveness, what features are in there. Community has been kind of built into the DNA from the very beginning. And it's one of the best things I think that's ever happened to the project. But it's also been one of the most challenging things too, because you're trying to keep a lot of people happy and Yeah, I distinctly remember back in the old days, pre Rock even saying, hey, this isn't about pointing the finger at the vendor. This is about what can we do? How can we add value? It's easy to criticize a vendor and a product, but it's hard to add value and do what you can do. Yeah, and I think that's probably one of things too that I've learned too is , oh, I guess I see why some of the things that we thought were so easy that maybe there was resistance to. It's , well, that's going be really hard. And my response in my head was always , yeah, but why does matter? Why does hard matter? But now I kind of understand where that resistance came from. It's not that we would use that as an excuse now, but you kind of understand kind of where they're coming from that it's a lot easier not to be that responsive and to just put up a wall between you and the customers and then pretend there is no wall. you put it up and then you say, Oh, we're just awesome. We're so responsive. And it's , Well, are you? But it's hard when there's no wall. And that responsiveness and extensibility, as you were just both saying, is rooted back in the why and how of Rock coming into existence in the first place. And we're talking about what kind of sets it apart. And it really is that infancy story. Right? And I remember meeting both of you in I think 2012 and Nick, you were coming up on Fridays to help work on the project and it was still very young. And it wasn't that long after that timeframe that we started talking about what should the core values of this be? And the core values have remained really important and it's not something it's not just words you put on a plaque and stick up somewhere. It really has been a decision making tool for the team over time because Rock is so much more even than it was envisioned to be early on, but we took the paths and the steps and made the individual decisions that led to where it is today, which is still quite responsive and still very much in the trenches to what church needs are. And I think a lot of that's rooted in the fact that we took those core values. We oh my goodness. We put so much effort into those and testing them out and trying to determine if they were accurate and then using them as that framework for decisions. And those are accessibility, community, craftsmanship, and innovation. And we've talked a lot about the community aspect of this and that's why we're extensible, that's why we turn around and fix things as quickly as possible. With accessibility, I think that also was hinged in that early story when the other product had been sold off, the price point that was put on that really eliminated it as a tool of choice for a lot of churches. And that just doesn't sit right with our team. Right. Yeah. And I think when we From the very beginning, there's always a power struggle between any kind of business relationship. And at the very beginning, we gave up all of that. So when it's open source, you lose power when you do that, right? Because everybody sees it. And we said, okay, well, anybody, any church can do whatever they want with this, any religious nonprofit, to be super clear. So that basically says, Hey, if we mess this up and if you don't the direction we're going in, well, could go do whatever you want with it, as long as you don't commercialize it, which churches would not want to do. So that kind of gives away a lot of the power to the community. And put some pressure on us. Right, to say, well, you got to keep in line with what the community wants. If you get off that, they have a weapon against you, which is good. And then the other one was the donation model, which is to say, well, there's no gun to your head saying you have to pay or you have to go away. So that is again, another thing is , if we don't do this right, you get to go do whatever you want. That makes it really hard though. It does make it hard. When you give away all of that power, you're really then only relying on trust. it was a two way trust relationship. Whereas if you're a more traditional vendor, mean, there's really not a lot of trust there. You still got to pay. If you don't want to pay, well then go away. You got to take your toys and go home. This one, you get to keep your toys and you could potentially make your toys better if you wanted to, you're not stuck. But we're a % relying on this trust back and And it was hard in the early days. I remember us having meetings saying, how is this gonna work? There's no money. Who's gonna donate? And here's the number we need. Okay, write the number on the board. Let's see if we don't get that by January 1, then we know that this is probably not gonna work. I think you called it a golden fleece or fleece. And sure enough, I remember getting the call from you. Yep, a church has donated and pushed us over that number. And it was a big number. Yes. Yeah, it was a scary number. But it built faith, think. Absolutely. You may have thought I had the faith, but I think seeing those things happen really bolstered my faith that I knew that this was the way. Yeah. It's definitely been an exercise in God giving this project what it needed when it needed it, not before Right. But when it needed it. And that I think that's been very faith building for all of us sitting here anyway. Yeah. It's still scary. I mean, because no matter what There's always another- What you achieve, there's always another phase of it that you have to go through. You're always putting your foot out, knowing if you're gonna- How solid is that? Yeah. God's been faithful. For sure. And it hasn't been easy though. I mean, it's every time it's , you put the number out there and it's just not Then you don't just back away from the number and say, okay, you got to do your part. So it's almost , I usually now just fishing. You gotta put the lure in the water and you gotta do the fishing part. God will bring the fish, but it has happened, but it's rare that you can just stay in your boat and God's just gonna have the fish jump into the boat. It can happen, but it's we're fishing together, right? We put through our effort, God does his effort. And occasionally you get America where the fish jumps in the boat. Or he overflows your nets Yes. When when you just he says cast and you cast it. You're , we're already been fishing. We tried that. In that story, they still had to throw the net. Right. And they still bring the fish into the boat. So it wasn't , in that case, God said, just hold tight. The fish are gonna jump in the Right. They're coming. They had to show that they would follow his command to to fish. Yeah. So But if if this differentiator of the structure and the way Rock is set up and SPARC is set up isn't common in the church management world. It's because it's really, really hard. Yeah, we get calls all the time, maybe independent people who's saying, Oh, we'd love your model. We're gonna follow that model too. It's , Well, careful. Just know it's not easy. Nothing ever looks hard from the outside, but from the inside, it's really hard. It's not to discourage them to say, Don't do it. It's just , make sure you understand what you're getting into. It's actually hard. And I don't think it's bad to have a different model. This is the model for us. So that's what we've said, but it doesn't mean that it's the perfect model for everybody. That's true. It does feel the model that this product and that all of us here individually have been called to support and and work in and really put a a life's calling into. Yeah. And we've learned a lot along the way that different messaging that you can use. And in the beginning, pretty naive, Oh, just give what you can and we'll see what happens. But then as it became more and more a thing that needed us to sustain a team Right. That just doesn't work. No. And the churches running on Rock have said to us at various times, , let's make sure this is stable for a go forward plan, so let's put some standards out there, some recommendations. People are looking for that information and that was completely accurate. Yeah, and I think a lot of the initial intent was , this could just be a This will never need to have full time people. Just That's crazy. If you look at how far it's come and how big it is, it's , no, that was needed. Definitely going to need full time people. And then other thoughts are , Oh, well, everybody will just contribute whatever they want code wise into it. Oh, boy. Now that doesn't work either because I mean, everybody's code is different qualities, different ways of coding. Understanding of how things work deeper down. And even just things that seem incredibly obvious, well, if someone submits their code, they'll support that code in the future when there's bugs. No. Once it's submitted and you pull it in- You own it. It's yours. Yeah, we own it. Now you gotta fix it. And even though you didn't write it. So that was another one of those things that we had to change over time. It's , okay, we won't take pull requests. But the Rock shop gave us the ability to say, well, yeah, go build your thing and integrate it and just provide it to everybody in the Rock shop. Now you support it. Yeah, well, when I was gonna finish that, we will not take poll requests from just anybody. we will take them. Right, right, right. But they have to be very close and we want them to be working for a church. that's who we're here to serve. Yes. But if you have a for profit, and we're not gonna take your pull request and then have to support it, even if it was done on the behalf of a church, because that's basically saying, hey, go pay them to write something that then we have to support forever and never get resources to support. Yeah. It's basically tax to other churches. Right. That just doesn't really work in this model. Yeah. And again, we thought that could work and then we learned over time that, oh, No, that doesn't work. Yep. This has definitely been a learning journey. And let's see, it was what? 2014 when Rock V1 came out, I think. I'm really bad with tears, probably. I think that's right. In the the fall, I think we launched our first major release. And and I remember the the vision at that time was it made sense for where we were with the product, where we were with the community. You've talked about some things that have changed over time. I think God's just had to step in and stretch our vision a little bit at a time, and what a thing it would have been back then to have had our eyes fully opened to everywhere Rock was going. In a lot of ways, I'm glad that it's been a little bit at a time. I think that's all the human brain can kind of tackle. Yeah. I guess if I could go back in the time machine, Well, or think back to how I thought back then. I never would have thought that at this point it would still be this hard. Yeah. And I think it's because we just don't stop. , I don't feel we've rested a day. It's , we're always running after something, some new feature. And I joked, but it was kind of true. , okay, this is the last time I do this. , we're never doing that. I'm never doing that at church management system. Yet. Yet now we are. , we're writing another whole church management system because we're this new V next project of , writing a whole new architecture has become writing a whole new church management system. Now the data model's all the same. Yeah. But holy cow, we are going into weeds so deep to figure Yeah, that haven't been explored in ten years, right? I mean, this is kind of what it was ten plus years ago. Yeah, the amount of research and depth that we have to go to and changes that we're making to the core architecture to make significant improvements. And what, we could just say, what, it's that fast today, it can be that fast tomorrow. But it's , no, that's not good enough. We've got to make this, cutting the load time in half, not good enough. it's gotta be way less than that. And why are we making those decisions? Because of our core values of craftsmanship and innovation. Right. So those are still driving the decisions that we make today. And they're not the easy decisions. We find ourselves taking the hard path many times because of that framework. Yeah, I really think if you The truth is it's insanity. I think I allow most people to be , okay, there it is, let's just make some improvements every year and make some But it's just , we know that's not what's needed by the churches. And that might be a good five year plan. But after five years, you'd have a Mhmm. It'd be kind of a turd. I was thinking that same word. It's just no one wants it. And we're not here for the short term and we're not here as a business model. We're here make a tool that the church is going to need not today, well, they kind of needs it today. Some stuff we're working on, but what the church is going to need in five years. Yep. So that is underway. Yeah. That replacement or next gen, V next is happening. When there's new features coming out that I think are really going to be addressing those needs that we need now, but what we really need in five years. I think if you look at the goal that we were trying to solve in the beginning, it's so much smaller than what it is today. And it's so that what it is today is so much smaller than what we hope to be in a few years. Yes. And originally, when we named it a relationship management system, I think that really indicated what it is we're trying to do here, which is a ministry tool. Mhmm. And those new features and the the basis for all of these things that we're doing is really to build that ministry set of tools, covers basic administration, but really reaches into connecting with people in new ways. And that's another big differentiator in the space, I think, of what Rock provides intrinsically. And it's why we're responsive as well. Yeah, we actually threw that term away, quick church management system. It was actually in our logo. Was for just brief time. Was , Oh, no, this is not what we do. It's so much bigger. And that's not what we really want to be known for. Still the day, church management to me has a lot of internal features kind of, that's what kind of feels . We really wanted to be focusing on the external features that help people. It's really fun to have a kind of throwback conversation and review those things here ourselves just around a little table, but I think it's also super valuable to understand the trajectory of a project that you're interested in or involved in. If where it came from, you can kind of track that line forward into the future and see where it's going. And it's great to circle back and say, yes, this is rooted in something that we were called through all sorts of different complexities together to do. And here are the reasons why, and we're still on track for that. So really cool conversation. I'm glad we could share this with the community. I'm not sure we've ever really just discussed it quite so candidly before. And there's just a lot of value in looking back at history. , in the Old Testament, God frequently had the authors of the different books recite the ways they've seen God show up in the history of their people. And so remembering that history and remembering God's hand in history is something that's just a part of what churches do anyway, and so we want to be a part of that as well. So thanks for listening as we shared our story of origin for Rock. For those of you who are in the community or looking to join and kind of check out Rock or get more deeply involved with the other churches that are there, this community you can learn as much from the people, more from the people who are involved than you can from the documentation or the partners or the product itself. So if you have not yet really dug into this community, you need to do that. We have a couple of classes coming up that can help you not only connect with people, but also sharpen your skills a little bit in the Rock world. In July, the fifth through the seventh, we have the SQL for Rock class. So if you are ready to learn more about the data structure in Rock and some advanced reporting, this is a great class for you. It's good if Rock a little and are not familiar much with SQL. Then there is a master class coming up July. This is our annual virtual master class. So it's a little bit of a different experience than an in person class, but for some that is what makes sense for travel budgets or other reasons if you're a very small staff trying to serve your church and can't get away. The Virtual Masterclass might be the option for you, so check that out. But what we're really excited about and working a lot on right now is the Rock Conference that's coming up in September. Our room block is almost totally sold out. So get your hotel rooms, get them soon, And don't forget that we have lots of exciting aspects of this conference. We have a community celebration the night before, we have a free technical training program the day before, and we have some really incredible content. We've been working closely with the speakers this year to kind of handpick and select the topics and the sessions that are coming in. Lots of really great content. So this is the thing that will drive your Rock experience all year. Don't miss it. And make sure to bring your whole Rock team. We're also going to have a communications and digital track this year. So if your communications team is starting to wonder about maybe utilizing some of the tools a little more inside Rock, this would be an excellent time to send them to the conference as well. The schedule for Rock is now up on our website. So make sure that you check out the conference page and look for that schedule so you can see what we're talking about with all these great sessions coming up. Do keep in mind, it's still early. There may be some adjustments to timeframes on some of the sessions, but you can follow them and create your own schedule, which is pretty cool. Alright. Thank you so much for tuning in and joining us today in our conversation about the history and the direction of Rock. We're so thankful to be supported by a community this one. We don't take it for granted and we are very grateful for your involvement. Thanks for joining us, we look forward to talking with you again at the next Rockcast. Do a church that loves the idea of using Rock but hasn't taken that leap yet? With managed hosting, churches of any size can get access to Rock's amazing technology, hassle free. With just one click, Rock's managed hosting removes the roadblocks that might stop a church from switching to Rock by making the process simple. Churches get the ease of a SaaS church management system without losing any of Rock's powerful features. Are you ready to take the next step or share with another local church? Visit rockrms.com/hosting today.