LDSTech is dead?

Hi people,

One question... The website http://tech.LDS.org is dead? I don't see news updates and others infos. Or the channel is active, but only website tech.lds.org that stoped?

Regards,

I inquired about this recently and received this answer:

There are no longer any employees assigned to LDSTech. As a result, the page hasn't been updated with new articles.

It's been a pattern over the years, it'll dry up, then a service missionary is called, then it dries up

I wonder why they can't at least do a minimal update occasionally. I maintain a few websites, and I can change and add new content in about 15 minutes. I suppose the tech site may be more complex and updating it might be more labor intensive...

zane,

It does seem dead, the excitement around the ramping up, getting internet to all the sites, introducing come, follow me, all the online tools, it's just over, we're on cruise control.... everyone's been assigned to other stuff and the only fun stuff are the couple of mobile developers left doing that work.

johnshaw wrote:It does seem dead, the excitement around the ramping up, getting internet to all the sites, introducing come, follow me, all the online tools, it's just over, we're on cruise control.... everyone's been assigned to other stuff and the only fun stuff are the couple of mobile developers left doing that work.

It's true that the LDSTech site is no longer being updated, but the rest of your speculation is not true. There's lots of work being done on backend services, and we know that at least the Calendar online tool is in the midst of a major overhaul. Here the Calendar product manager said: "We are working on a new major release of the calendar."

This is sad and too bad. I remain hopeful that someday a forward thinking CTO will be hired at the church and make the bulk of all Church software project open source or open source for members. I can't help but think that the failure of the LDS Tech project came from a desire to maintain too much control over the projects and what was even attempted to contribute.

It requires changing how you think about doing work.

If the list of issues was stored on GitHub, and the project allowed Pull Requests, and serious PRs were assigned to full time team members you could make some positive progress in having volunteer programming happen. If there was a promotion process so that people who had contributed multiple times were given more permission or taken more seriously, it would reduce the effort required to maintain. We aren't talking about a huge amount of people to police. Even Gospel Library only has around 1500 registered volunteers, far less than many open source projects.

Don't get me wrong, I know that this isn't as simple as flipping a switch. I just wish there was more emphasis put on this by the tech departments of the church.

For security purposes, I would not make the source code of all church applications open source.

aebrown wrote: It's true that the LDSTech site is no longer being updated, but the rest of your speculation is not true. There's lots of work being done on backend services, and we know that at least the Calendar online tool is in the midst of a major overhaul. Here the Calendar product manager said: "We are working on a new major release of the calendar."

Yet other extremely valuable tools have been eliminated. Oh goody a calendar that has worked great for years is improving. My stake still doesn't use it correctly in any sense of the world. I can rely on it for Ward or stake activities.

What's missing is the last mile effort. SP/Bishop's and the STS helping coordinate adoption. Tool development means less than adoption in my mind and that's what LDSTECH is for.

LDS Music for iOS is struggling for volunteer developers, and Gospel Library for Windows is trudging along slowly. Both of them are still run as public LDSTech projects that anyone can join and contribute code to. Many people have joined the projects, but few actually put in pull requests – and of the few that do, even fewer do so consistently. For example, there are several open issues in GitHub for LDS Music for iOS, but the most recent pull request was about a month ago. This doesn't inspire a lot of confidence in the people who make decisions about where funding and focus should go (for example, towards LDSTech).

I don't blame contributing members entirely for the failure of LDSTech. There is a lot of continual work that needs to be done on the organizational side to keep a volunteer community engaged and provide support, which I think was a cost that was never fully planned for in LDSTech.

drepouille wrote:For security purposes, I would not make the source code of all church applications open source.

What security issues do you presume would exist that are more problematic than providing the applications themselves to end users?

Maybe you mean that there are "sensitive applications" that shouldn't be open sourced (like the in-Temple apps) and I support that. That's specifically why I said "the bulk of" and not "all".

sbradshaw wrote:LDS Music for iOS is struggling for volunteer developers, and Gospel Library for Windows is trudging along slowly. Both of them are still run as public LDSTech projects that anyone can join and contribute code to. Many people have joined the projects, but few actually put in pull requests – and of the few that do, even fewer do so consistently. For example, there are several open issues in GitHub for LDS Music for iOS, but the most recent pull request was about a month ago. This doesn't inspire a lot of confidence in the people who make decisions about where funding and focus should go (for example, towards LDSTech).

I don't blame contributing members entirely for the failure of LDSTech. There is a lot of continual work that needs to be done on the organizational side to keep a volunteer community engaged and provide support, which I think was a cost that was never fully planned for in LDSTech.

It's hard not to see that the volunteer work has been minimal, but I would like if it was kept in mind that the difficulty of contributing is one of the crux issues. For most of the life of the LDS Tech project, it wasn't as simple as find an issue on Github and open a PR against it (and Github itself wasn't always mature enough to support that, either). Definitely volunteers could have tried to help out more. I feel like I personally could have, too. If it was more "open sourcey" then it would be easier to be an occasional contributor. And I don't think the lack of engagement or activity should be a reason not to pursue it, though.

Allowing volunteer contributions should be seen as a worthy goal that is always given value and priority.

All LDS applications within LCR, which are used for membership and will soon be used for all finance functions are too sensitive to release to public view. Likewise, applications on several other LDS web sites (missionary, temple, etc) are too sensitive.

The Church has put forth several online crowdsourcing initiatives, and unfortunately, most of them have failed (for example, Helping in the Vineyard, which fizzled out after a few years and was replaced Volunteer.LDS.org, which was in beta for a couple of years and then abandoned). The success of Create.LDS.org remains to be seen. FamilySearch shines as a positive example (indexing and recently translation). It can't be run as a side project or as an afterthought. I think when the time and the leadership is right, the right things will happen to get things moving again.

drepouille wrote:All LDS applications within LCR, which are used for membership and will soon be used for all finance functions are too sensitive to release to public view. Likewise, applications on several other LDS web sites (missionary, temple, etc) are too sensitive.

I get what you're saying about LCR (maybe, only because it might expose a critical vulnerability and lead to leaking data), but most of the church's apps would be completely useless without access to the systems that fill them with data. But even if there are systems that might be too sensitive, there are tons of apps and websites that aren't sensitive from a code perspective.

cardonbj wrote:

drepouille wrote:All LDS applications within LCR, which are used for membership and will soon be used for all finance functions are too sensitive to release to public view. Likewise, applications on several other LDS web sites (missionary, temple, etc) are too sensitive.

I get what you're saying about LCR (maybe, only because it might expose a critical vulnerability and lead to leaking data), but most of the church's apps would be completely useless without access to the systems that fill them with data. But even if there are systems that might be too sensitive, there are tons of apps and websites that aren't sensitive from a code perspective.

yup.

feels like this is likely often a pressure, it's not as though there aren't ways of managing that kind of thing. just has to be prioritized.

I think one of the issues is the effort the church would have to put into a sandbox and exposing it to the developers on the "outside". They may have discovered that the effort to create the environment and manage the community was too high when compared to the effort to develop in-house. This isn't like community development of a OS or a word processor.

Secondly, we've seen some of the church apps use a professional development environment - something that makes sense when you have a handful of full-time developers, but too expensive to hand out to the community.

russellhltn wrote:I think one of the issues is the effort the church would have to put into a sandbox and exposing it to the developers on the "outside". They may have discovered that the effort to create the environment and manage the community was too high when compared to the effort to develop in-house. This isn't like community development of a OS or a word processor.

I don't disagree that it would require a possibly sizable up front investment of time and resources. However, in my opinion it's a worthwhile investment. It's likely that the community developers still wouldn't produce as much as anyone would like, but it would at least be possible. There are multitudinous open source projects that do all kinds of things from system monitoring, to personal calendars to email to whatever you can imagine.

Secondly, we've seen some of the church apps use a professional development environment - something that makes sense when you have a handful of full-time developers, but too expensive to hand out to the community.

There are businesses who need to make huge profits who use this business model, so it doesn't seem like it should be infeasible for a charitable organization to do it.

I'm also kind of curious what you mean by "professional development environment"? All of the Church's apps can be built using open source development platform tools. I guess it's not completely impossible that they have some proprietary libraries in there somewhere (though I don't think so...) but the mobile apps in particular (Gospel Library, LDS Tools, Scripture Mastery, etc.) can all be pretty easily built with only free tools (or standard development tools in the case of things like iOS).

cardonbj wrote:I'm also kind of curious what you mean by "professional development environment"?

A language, API or library that would require a significant cost to install on a developer's machine. Can the application be written without it? Yes, but it may require re-writing from scratch causing a significant setback.

I'd ask if you've done community development yourself? I've seen others who have come here extolling the wonders of community development, but I don't recall as any were developers themselves. Doing some number crunching, it appears the number of members in the general population of the US is around 2%. Probably less then that in other parts of the world. Given that the number of community developers are on the smallish side to begin with, that's going to greatly reduce the number of people that would be interested in programming for the church. Especially when you're talking about a project that's limited in application and doesn't benefit the population at large. I don't know the details, but I've gotten the sense that the church had made a effort at community development in the past and was disappointed in the results.

If you feel the desire for development, I'd suggest you head over to the Gospel Library for Windows. That's completely dependent on community developers and it has some catching up to do. Until that changes, and the Windows app can maintain pace with the iOS and Android apps, I doubt if the church would consider community development again.

I am a software developer which definitely feeds into my belief that it is a worthwhile goal. I'm not saying they should switch any projects to exclusively community development. I think it would be good if the church's projects we're source available with all of their development done in the open or "in the open".

I am curious if they have some sort of proprietary development environment that would cost money to install. That would be interesting. Several of their projects could be developed on GitHub and have a process for accepting community contributions if anyone decided to make one.

The old LDSTech process was pretty complicated. Maybe some day it will become a worthwhile goal again to the right people.

drepouille wrote:For security purposes, I would not make the source code of all church applications open source.

Certainly not all of them, but I'd think that just about any project that can be opened to volunteers should also be safe to open-source. Of course, licensing is another issue…

I think another problem is that many active church members with the skills are already so busy serving in their callings (on top of work and raising a family) that finding extra time to contribute may be quite difficult. In the day when the church was rolling out all kinds of technology tools (most of which have now been discontinued), I saw there were some projects to which I might be able to contribute, but I had no time. What I did find was that I could help test some of the tools and provide helpful feedback, as I understand what kind of information a developer needs to fix a problem, such as a reproducible scenario, but that's about all I could find time to do. Right now for me to make any contributions, I'd probably need to be retired or independently wealthy.

I remember a few years back, I thought it could be an interesting option if the church had "technical missions" where full-time missionaries with some pre-mission coding, QA, tech writing, etc. skills could serve a hybrid technical/proselyting mission. For example, they could spend 6 hours during the less productive daytime, Monday through Friday, working at the Riverton office building and then go to their areas in the afternoon / evening for proselyting duties. People could come out of this program with valuable work skills from an internship as well as the spiritual benefit of a regular mission. They might also have a better understanding of the connection that can exist between the spiritual and technical. I wouldn't start such a program with a lot of participants, but the church needs more technical people than the budget permits and this could be a way to help. It would also depend on how many church employees could be mentors, and it seems there aren't too many to begin with, so that might be a problem. But if that got the Notes/Journal feature fixed and kept much-missed tools like Lesson Schedules and Newsletter going (and getting improved), or helped keep Gospel Library for Windows going, it would be a really good thing. You could likely put interns on such projects.

Oh well, it's a thought, but, I'm not the church's CTO/CIO, and it's time to go to my day job

The Church did have LDSTech service missions for a while. I served a 6-month LDSTech mission, 3 or 4 years ago. My name tag had "LDSTech Mission" as a subtitle.

I'm incredibly late to this thread, but I also am sad to have seen LDSTech fade away over the years. One of my favorite moments of serving the church was the opportunity to take my skills as a Ruby on Rails developer to update the Washington DC's temple visitor's website for their Christmas lights invitation application. Shortly after that I was asked if I'd like to volunteer as an LDSTech missionary, but unfortunately I wasn't eligible at that time. I looked forward to the day when I could, but I believe it had already died off prior to that. It feels like we've taken a massive step backwards in utilizing all of these incredible technological advancements we've made. I believe firmly in the capabilities and contributions of OSS, but it requires there be a steward to own each project that is endorsed for official support, IMHO. That way you can avoid a project that has some success from simply dying off if someone's life gets too busy, they stop believing, etc. All that said, I look forward to seeing what the church can bring about in the future along similar paths of allowing our members to give back with the talents the Lord has blessed us with. I'm confident the spirit of LDSTech won't be benched forever - someday we'll be able to help again when the Lord says the time is right.

It's definitely diminished. I agree with you.

I've been on and following this forum since 2007. I think it lost a lot when full-time Church tech employees no longer helped moderate it. I'd like to see that return.

It's definitely still needed and valuable.

Hi everyone, I’m new here. I just finished high school and I’m currently serving a full-time proselyting mission. The topic of open-source software for the Church has always interested me, and I’ve wondered why it hasn’t been explored more especially in recent years.

I’ve worked with computers most of my life. I started programming in 4th grade, and over the last six years I’ve contributed to various projects and started a few of my own. I’d love to help with Church-related projects in my spare time. Since beginning my mission, I’ve been sending in feature requests for the PMG app. (Which has been fun to see them take my suggestions) From what I understand, the Church doesn’t have a central product or "vision" manager overseeing all of its technology efforts. It seems like each team is assigned deadlines, finishes one project, and moves quickly to the next. That kind of structure can create a bit of chaos and lead to burnout.

Open source isn’t inherently insecure; in the long run it can actually make software more secure. If it’s implemented correctly, it can be a powerful tool. One idea I’ve had is a Church-run Git server where contributions require a Church account. There are a lot of young people today who are learning advanced tech skills early, and many would be excited to help.

After my mission, I’d love to work for the Church, but I do worry about burnout. A shift toward open-source collaboration would alot take time, but I think it could be really beneficial.

For example, when I was in 11th grade last year, I built a fully functional basic Gospel Library app for WearOS in about three weeks. I’ve noticed that Android tends to receive less attention from the Church, especially compared to the recent improvements on iOS. When I saw my cousin using an Apple Watch with an official Book of Mormon app, I looked for a WearOS version, and when I couldn’t find one, I decided to build one myself.

Anyway, this is my first post. I’m not trying to sound accusatory at all. I just want to help, and I think there are many others who feel the same. If you’d like to check out my WearOS app, I have screenshots and the project is on my GitHub:
https://github.com/allancoding/Gospel-Library-Watch

alniles07 wrote: Sun Nov 16, 2025 6:04 pm Hi everyone, I’m new here. I just finished high school and I’m currently serving a full-time proselyting mission. The topic of open-source software for the Church has always interested me, and I’ve wondered why it hasn’t been explored more especially in recent years.

...

Anyway, this is my first post. I’m not trying to sound accusatory at all. I just want to help, and I think there are many others who feel the same. If you’d like to check out my WearOS app, I have screenshots and the project is on my GitHub:
https://github.com/allancoding/Gospel-Library-Watch

For the record, the Code of Conduct prohibits "Links to Web sites in an effort to promote or generate traffic to Web sites or businesses." However, for projects that are entirely non-commercial, we generally allow one announcement post.

alniles07 wrote: Sun Nov 16, 2025 6:04 pm If you’d like to check out my WearOS app, I have screenshots and the project is on my GitHub:
https://github.com/allancoding/Gospel-Library-Watch

Nice work on your WearOS app! I think there's a lot of good that members can do to support the Church and share the gospel outside of official Church projects, but I agree that it would be nice if more of the Church's official projects were open to volunteers. The team that develops the Windows version of Gospel Library is still volunteer-based and is led by a senior missionary, if you have any interest in helping with that, but that's the only one I'm aware of.

Embarrassingly, it wasn't until I joined this forum that I discovered the Church's apps weren't being developed in an ad-hoc, open-source manner by interested members.

Gratefully, the app quality has improved over the years... but it would be nice to submit features faster.

For me, I'm kind of at a weird place with Windows. I've developed for that platform most of professional career, but I'm really not on board with MSFT's new vision and I find myself basically using Linux exclusively for everything outside of work. I won't be surprised if I end up shifting my development career back into Linux exclusively in the near future.

mdigi wrote:
> MSFT's new vision and I find myself basically using Linux exclusively for
> everything outside of work. I won't be surprised if I end up shifting my
> development career back into Linux exclusively in the near future.

Yeah, the quality has definitely improved over the years. I really wish they documented some of the APIs, like the Quote of the Day and Scripture of the Day. I ended up reverse engineering the Android app just to figure out how to pull those quotes.

I’d love to develop a Linux version of Gospel Library someday. I’ve been using Arch Linux for the last two years and running Windows in a VM when I need it. I just like the way Linux gives people more control over how things run.

Also, I noticed this forum is running on good old PHP. It would be great to see it updated to a more modern forum platform there are plenty of solid open-source ones out there.

When I get back from my mission, I might have to start up some church open-source projects myself.

alniles07 wrote: Wed Nov 19, 2025 5:54 am..... I ended up reverse engineering the Android app just to figure out how to pull those quotes.....

Since this has come up again, I'd point anyone following this thread to a previous discussion on the same general topic area. Although the entire conversation contains helpful info, perhaps starting with this post
reverse engineering Church apps
in the "API for Directory Web App" thread, and then reading the many subsequent posts, will help provide additional context and perspective on Church data, API's, and member access. I don't know enough about all these things to be able to offer my own opinion about reverse engineering vs open-source member projects, I leave that to others who can speak with some level of coherence on those topics. Although I expect that some of the information posted in that thread may be out-of-date, I also expect that the same general Church policy remains in place.

BrianEdwards wrote: Wed Nov 19, 2025 11:01 am ... Although I expect that some of the information posted in that thread may be out-of-date, I also expect that the same general Church policy remains in place.

It's possible the policy might differ between the API(s) used by the directory web app (which accesses personal information about other members, which creates privacy concerns) vs. a Quote/Scripture of the Day feature (no apparent privacy concerns).

Yes, I would hope that’s the case. I can see why that policy exists for user data, there are privacy laws that have to be followed. That post was also talking about making a private API public, which really could become a problem.

The API I found for the quote and scripture of the day is already public data; it’s just not documented. I could have just had it pick something at random, but since it usually follows Come, Follow Me, I wanted mine to match what the Church is already showing.

I have some thoughts on recent discussions on this thread:

phpBB
phpBB isn't as popular as it once was. Yes, other options exist. I'm not sure which ones are free vs. paid. My guess is that since what we have now works, the church probably doesn't want to devote time and money to a conversion project. However, if the church wanted community assistance on something, a project such as migrating phpBB to another platform could be something where outside helpers might be able to reduce the amount of time required by church employees on the project. However, it's still going to require effort from church employees.

Church Members Contributing to Projects
As was mentioned in previous posts on this thread, I've also heard that it was difficult to get significant assistance from church members on the projects. There's been discussion on open source and possible reasons why the church would not want to go open source with many of its projects. While there is much free tooling available - especially for open source projects - it's important to realize that there's a cost behind "free" software and services.

My background is software development. Over the years, I've had positions at companies where I've been involved with developer tool procurement, licensing, and use - sometimes for hundreds of developers globally. These developers would often times get excited about "free" tools. However, "free" isn't free. "Free" software is a business and pricing model. It's wonderful for open source projects, students, hobbyists, and small start-up companies. However, when you look at the pricing and licensing terms, you'll find a price discrimination model that is designed to provide lower-cost (or free) services to small organizations and individuals, while charging significant fees to deeper-pocketed companies and organizations.

Depending on the tooling used, there are potential per-seat costs the church would need to pay for every "community" developer who helps with a church project. When these community members aren't actively participating and making helpful, timely contributions to a project, this can be a lot of expense for little gain. I could give examples and elaborate more, but I'm trying to keep this post short.

Technical Missions
In a previous post in this thread, I mentioned my thought on technical missions. @sbradshaw did serve an LDS Tech mission back in the day. I don't know what the requirements were, but my current idea is that a local service mission could work if the volunteers can make something like at least at 20-hour week commitment, are interviewed and recommended by their bishop and stake president, and can be available for scheduled meetings with church teams with whom they would work. Still, this is going to take time away from church employees who need to mentor these missionaries. Perhaps as part of their missions, these individuals would need to Utah for a week or two for training and to meet with church employees (the Riverton MTC).

The technology for remote development is better now than it was several years go. We have easy video conferencing and screen sharing. The church could set up a developer environment in a VM and require developers to VPN to the VM (probably with those annoying settings that block you from doing much else on your local computer while connected to the VPN). This would help a lot with current security concerns. I've used that model to hire remote contractors at companies and it worked pretty well. Yes, the church would have a cost to provide this, but if they're getting a missionary commitment of a minimum number of hours a week for 12-24 months, maybe it's worth the cost.

mevans wrote: Sat Nov 22, 2025 11:07 am Church Members Contributing to Projects
As was mentioned in previous posts on this thread, I've also heard that it was difficult to get significant assistance from church members on the projects. There's been discussion on open source and possible reasons why the church would not want to go open source with many of its projects. While there is much free tooling available - especially for open source projects - it's important to realize that there's a cost behind "free" software and services.

There was no difficulty getting significant assistance from church members, in fact, it was a huge group of silicon valley members that wanted to volunteer and contribute. However, they couldn't align well with the kind of approval process necessary for projects back in the day. Additionally, they wanted a feature-rich environment and wanted to help drive features rather than waiting on requirements from CHQ. It was more of a culture thing than anything else. Back in the day, there was plenty of resources to be found.