The LDS Church’s Chief Information Officer, Joel Dehlin, called for help Wednesday in a post titled Mormon Open Source Open for Business. The project seeks help with a number of LDS Church projects, including, first on the list, a rewrite of the software that runs the Stake and Ward Websites.
When Dehlin admitted in the comments to his post that the program wasn’t quite a true Open Source program, I began to wonder why it isn’t, and what a true Open Source program might mean for the Church and for the LDS community.
I’m no experts in Open Source, nor am I even a programmer (I have taken a couple of classes, and mucked around in php code quite a bit, bu I’m not qualified to do much of anything). But I have read about Open Source and followed some of its developments. Code produced by Open Source projects is used by virtually everyone these days to one degree or another. Open Source code is the basic code behind the current Macintosh operating system, is frequently used even in Windows, and is the main driving force behind the most frequently used software on the Internet.
Open Source is like the cooperative road construction efforts made in pioneer communities. In many cases, no one go paid for constructing the common roads and much of the community pitched in to get the job done. When the job was complete, everyone got to use the results for free, even if they didn’t help in the construction.
This practice I think fits well with our Mormon communitarian heritage. You see something that needs to be done, you interest those in the community in the project, most of the community helps work on the project, depending on their availability, and everyone benefits.
The Open Source Initiative has basic definition of the term, and it is those rules that the Church’s project don’t quite follow, simply because unlike in a true Open Source project, the Church maintains ownership and control of the software (as I understand the project). No one outside will be able to obtain the software or its source code. Its a one-way street. The contributions are made to the Church, but the Church doesn’t make those contributions available to anyone else.
Now, I don’t want to suggest that the Church has to develop these projects using an Open Source model. I’m not conversant in all the factors that might go into such a decision. I certainly recognize that sometimes “too many cooks spoils the soup.” But I do see a need both in the Church and in the LDS community for Open Source projects.
Already the Church takes advantage of Open Source software in some cases. The wiki at tech.lds.org uses mediawiki, the same software that runs wikipedia, without any modification that I can see. The same site also includes a forum that also appears to be open source software. I’ll bet that many other Church technology projects also use open source software as part of the code developed.
The LDS community on the Internet also uses many pieces of free software, often software that is developed using Open Source. I myself use mediawiki for several of my projects (Mormon Translation, Mormon Terms), and use other Open Source software (such as WordPress, the software also used for Times and Seasons) for other sites. I’m hardly unusual — the majority of LDS websites I see these days use some Open Source software of some kind or another.
In developing the new software for wards and stakes, its even possible that some open source software might be useful. After all, in some respects these sites are similar to social networking sites or group management sites. Like social networking sites, they work off of a list of members, people who share something in common, share information with each other and who regularly meet for common goals. I don’t want to make too much of this comparison, but it seems likely that the stake and ward websites could incorporate some social networking features–and if the code for those features has already been developed by an open source project, why not use it?
This kind of attitude is critical, IMO, for many sites in the LDS community, especially as we discover ways to customize and modify the code we use to fit needs specific to being Mormon. Already sites in the community have developed code for things like home and visiting teaching and mission alumni groups.
This latter category is fascinating. It requires not only lists of who served in a mission and typical ways for alumni to communicate with each other, but also information about what mission president the alumnus served under, who were the alumnus’ companions and what areas the alumnus served in. The dominant force in this area is the Mission.net website, which seems to host the majority of alumni websites, and has code that was specifically written for such sites.
Unfortunately, Mission.net is looking a little dated, IMO. Its software appears to have last been updated in 2004, and where either social networking features or integration with existing social networks would seem like an obvious improvement, the site hasn’t included any features inspired by facebook, myspace and the like, nor can alumni integrate their mission.net experience with these sites. As a result, I’m already seeing some mission alumni effectively moving to the social networking sites.
Clearly Mission.net is an example of a part of the community that could benefit from ongoing Open Source development, even though it doesn’t appear to have used that development in the past (from what I can see on the site). I’m sure other sites in the bloggernacle and the LDS community will continue to use Open Source software. The interesting development will come as members of the online LDS community use Open Source to develop software specific to Mormon needs.
![Reblog this post [with Zemanta]](https://i0.wp.com/img.zemanta.com/reblog_e.png?w=860)
Open Source does not require that the Church give up control of its official version of the software, or the versions that it authorizes church units or departments to use.
What is does require is the possibility of forks that other organizations and private individuals could use. For example, if the Church places Personal Ancestral File under an open source license, there could be other derivative and potentially incompatible derivatives out there, which the official version could typically borrow from, but not dictate.
Of course the Church could certainly keep anyone else from calling their open source derivative “PAF” or “Personal Ancestral File”, the same way the use of the terms “Firefox” and “Redhat”, for example, are restricted.
If a commercial organization were to ask for volunteers for a “shared source” project that disallowed the possibility of independent distribution, most would politely decline. The Church is a special case here of course, because it commands an enormous volunteer base already.
Either way, how successful any open source or quasi-open source project is depends largely on the openness of the project leaders to outside ideas and contributions. Any refusal had better come with a principled explanation or volunteers will give up in disgust. In terms of software, that means making Church policy on certain matters radically more transparent than it currently is. We won’t add that nice feature that you have developed due to policy considerations that we won’t explain is not going to fly.
Mark D., very insightful. I agree completely.
Again, I’m not an expert, but I can’t see a downside to the Church making their projects open source, for many of the reasons you outline.
Exactly. The “shared source” project that Dehlin annnounced will definitely get a lot of volunteers — and probably many volunteers that will even accept the explanation “policy considerations that we won’t explain” you forsee.
BUT, ideally, more transparency in areas that aren’t that important to privacy and the like, would be a good thing, or, failing that, more and better explanation of why the transparency can’t be given. Why there isn’t more disclosure of the Church’s budget, or things like the overall number attending Sacrament Meeting throughout the Church (giving us an idea of the number of active members) is something I don’t understand at all. I’m not suggesting that the Church has to disclose this information, but I would like an explanation as to why it doesn’t.
I can say, however, that Dehlin’s policies as the Church’s CIO have been exemplary, substantially more open than what we’ve seen before he took over. At least in IT, there is some reason for hope for more transparency.
I’d be interested in knowing what the church’s restrictions are. I can’t think of a way to implement or enforce a policy of “here’s the code so you can work on it for free but you can’t use the code for anything else.” Are all volunteers going to sign NDA’s? Maybe I skimmed too quickly.
I think you are not considering the paranoia (for lack of a better word) within the Church. We fear the evil that can be done and has been done by being too open. When you start opening up the software that will eventually contain private and personal information, not only will people be able to point out and fix glitches in the software, but also discover and take advantage of glitches in the software. A truely gifted programmer could even create such a glitch. The likelihood is remote, but paranoia knows no reason and does not understand the difference between probability and possibility.
3: Copyright law is more than adequate to keep the code itself (and any obvious derivatives) from being deployed on a systematic or organized basis in any manner you disapprove of. No NDA required.
Most open source projects tend to be dominated by people who actually use or professionally support the people who use the software on a production basis. If the type of software concerned is stuff that you can’t effectively use on a personal basis or are aren’t allowed to in any other organized context, contributions will be limited because most of the contributors won’t have the practical deployment experience to care very much about the warts, weaknesses, and idiosyncrasies of a given software package, nor the experience to develop effective enhancements.
Most follow on open source software contributions (such as feature enhancements and bug fixes) are oriented towards solving the problems that the contributors themselves have with the software. Comparatively few volunteer to solve the problems of others, especially problems that they don’t understand or appreciate.
In other words, making software that is not only usable by the Church but also by private individuals, non-profits, other denominations and (horror of horrors) people engaged in gainful employment is likely to attract far more contributions, and contributions of considerably higher quality. Is there a principled reason why we can’t make software that (with appropriate modifications) is usable by the Presbyterians? If they contribute back?
Bruce Crow (4): I admit your point. Paranoia could very well derail any Open Source idea in the Church (and even among efforts in the LDS community).
Ideally Open Source efforts would use enough programmers checking each other that someone taking advantage would be caught. But paranoia wouldn’t care that such a check exists. Just the possibility that something could be missed might derail a project.
We’ll see what comes of it.
I have to look at it from my viewpoint as a software QA manager. Open Source software does have uses for leveraging an organization’s resources. In the products that my firm develops we use Dojo, which is open source, and Syncfusion, which is cheap enough relative to our sales that it might as well be open source. Both of these toolkits give us features that would take us an inordinate amount of time to create on our own. That being said, these two products are the biggest creators of problems that my staff has with testability. Both products can be used in a way that negates our test automation and gray-box testing efforts. We continually have to remind the developers of that issue.
I think that the whole discussion about how far ICS ,the IT department of the Church, is willing to go with open source is tied to concerns about protection of personal and financial data. The efforts that the church goes to in protecting the personal information of it’s members is extensive. While there are technically feasible ways to secure data in an open source environment, encryption schemes and the like, the easiest way is to lock down access to the code.
Also, I think that calling legitimate risk management concerns paranoia is a little disingenuous. I used to have a poster that said “it’s not paranoia if they are really out to get you.” the bottom line is that the security goal of the ICS people in Salt Lake City is zero breaches of personal information of members and financial information of the church. Potential security threats need to be assessed and guarded against. And again, while there can be sophisticated ways to ensure that goal is met, from a development management standpoint, the first and simplest step is to control the source code itself and access to it.
While there are technically feasible ways to secure data in an open source environment, encryption schemes and the like, the easiest way is to lock down access to the code.
This assertion has so many things wrong with it I hardly know where to start. (1) There is absolutely no technical reason why a need for data encryption has any necessary connection to the choice of a software development process.
(2) If anyone hasn’t heard, open source software has a radically superior security track record compared to that of comparable commercial software. Every version of Windows prior to Vista is infested with security vulnerabilities, many of them designed in in the name of “ease of use” and thousands more discovered, analyzed and exploited on mass scale without any access to the source code. Mass compromise of Linux systems is almost unheard of by comparison.
(3) The idea of maintaining security by “locking down the code” is known in the field as “security by obscurity” and it is far and way the most discredited computer security concept on the planet.
(4) No self respecting open source software project accepts code contributions without reviewing them and making sure they meet a set of guidelines typically rather more demanding than a comparable closed development process. As a consequence the internal architecture and source code quality of open source software is often far better than that of direct closed equivalents.
I have participated in the early stages of the first open-source project, which envisions volunteer programmers working with a core group of church IT professionals. I think it has great potential, but is also difficult to manage. Volunteer programmers are not employees with supervisors; nor are they called by a priesthood authority. Thus it is difficult to impose design by fiat.
So, for example, one of the first things the volunteer developers did was to question the high-level design objectives postulated by the church IT department (and its sponsor, the priesthood department) questioning management’s priorities. So running the project is a bit like herding cats.
Remarkably, all that discussion occurred in an open forum online.
(It may turn out, BTW, that this particular project is inherently too ambitious a choice for the first open-source effort. So it might be unfair to judge the open-source concept by whether this particular project succeeds. Not all IT projects do succeed.)
Overall, I am very impressed with Joel Dehlin’s open approach to managing technology. There is an unfortunate tendency for any large IT organization to be walled off from its stakeholders, but the best IT executives in the corporate world align themselves closely with their customers, whom they listen to and involve. That is what Dehlin is doing.
Anyone with an interest in such projects, as well as the operation of existing church IT systems, can do so by logging on to public web sites operated by the church IT department. A good place to start is LDSTech.
re: #8 – your point #2 is irrelevant as the usage patterns of the vast majority of open source OS installations is so radically different from the majority of Windows and OS X usage as to be comparing apples to oranges. (Highly secured data centers running with only remote access opposed to huge numbers of open desktops being run by people who bought computers at Best Buy.)
For the rest, there is always a dynamic tension between management and IT staff about security technology, like everything else. The IT people will pitch for the best technology possible and management is only willing to pay for the cheapest possible solution. That is why simpler methods like access control to data are so common. Are they the best? No, but they are effective enough and management will cut the check for that.
In the case of the church, they are going to be sensitive to the cost because this is being paid for with sacred funds. Their approach to securing the source code and data will be to do what is good enough to meet their objectives.
James (#8) I might respond with “just because someone is out to get me doesn’t mean I’m not paranoid.”
The paranoia in the Church leadership is more than “legitimate risk management concerns.” They go above and beyond that which is necessary to keep private information private. I work in Healthcare IT, where a leak of private information carries a large potential fine. We take great care in ensuring privacy. But I can get access to my data base to work remotely. A person can pay their hospital bills online. The equivalent is just not available within the church framework. Why should the EQP have to schedule time to get to the Ward Clerck’s office to enter HT stats. Why can’t I pay my tithing online and have it appear on my annual tithing statement? Paranoia. The technology is there and we don’t need “open source” development to make it happen.
James (10) wrote:
I’m not sure how it fits in your analysis, but you have open source situations on both sides of these usage patterns. Yes much open source OS is server driven, but OS X is built on unix — which, as I understand it, was significantly influenced in its development by open source projects.
And, to be honest, its unix in both cases — the “open source OS installations” are unix and Mac OS X is unix.
Moreover, even on windows, there has been a lot of application programming (which is, after all, what were talking about here) done using open source.
So, I’m not sure how these different usage patterns really make a difference in the end.
10: In my experience one of the Church’s most fundamental management problems is that “sacred funds” are considered radically more sacred then member time. Wasting member’s time doing pointlessly menial tasks has a tendency to be done with hardly an afterthought. Occasionally those tasks are rewarding in and of themselves, but many are not – making members on occasion feel like their time is a resource to be squandered in comparison to sacred funds accounted to the last penny.
Bruce C (#12), I couldn’t agree more. Weekly tithing processing is one of the greatest resource sinks in the Church, one that could be virtually eliminated with the ability to make contributions online, and with very little cost especially if restricted to electronic checks or ACH transfers.
When I was ward financial clerk not so long ago I also spent considerable time and effort reconciling two independent financial systems that contained the same transaction level information but contradictory and inconsistent handling of corrections and adjustments. That is sort of the thing that the so afflicted individuals have a strong personal motivation to want to help fix.
If leaders have other priorities that volunteers are unlikely to comprehend or appreciate, perhaps they should issue actual callings. However, I seriously doubt that there are many willing to do volunteer programming by management checklist. No one does open source work like that except paid employees.
Bruce Crow #10: “Why can’t I pay my tithing online and have it appear on my annual tithing statement? Paranoia.”
Mark D. #14: “I couldn’t agree more.”
That explanation is simplistic at best. Tell me, how would on-line tithing payment work in Orina Del Toro*, Chihuahua, Mexico? A big part of the reason why the Church hasn’t “come out of the stone age” technologically is because it has to design things that work well not only in Salt Lake City, but also in Cochabamba, Bolivia.
*OK, I admit—I stole that locale from the Salt Lake Tribune’s Robert Kirby, who claims it was one of the areas on his mission. Personally, I doubt it: for those of you who are, shall we say, less than conversant in el idioma celestial, “Orina Del Toro” means, um, “Bull pee.” ;-D
Ken, (1) You quoted my agreement out of its total context, and (2) a statement like “couldn’t agree more” should clearly be read as hyperbole.
In addition: (3) I have not suggested that the Church refuse donations made with ordinary paper checks. (4) Unit level financial processing already varies significantly by country – there is no unified procedure. (5) Means for accepting online payments are readily available in Latin America and most other countries. Of course one would start with countries with a large number of online members first.
(6) I don’t think that a decision not to accept payments online was driven by “paranoia”, however I have a hard time thinking otherwise when it comes to the ward website system, which is restricted beyond the point of usability. For example, the notification emails don’t actually contain any pertinent information.
Not only that, temple recommend holding members of the church are not considered trustworthy enough to read the equivalent of an announcement board for a ward in a neighboring stake. That is a rather severe impediment for members who participate in more than one ward for a variety of reasons (singlehood and language, in particular).
I’ve discussed employment with ICS on and off, and given the Church’s dismal abilities to recruit potential employees (who will stick around ICS long enough to make it worthwhile), I think the new strategy is brilliant.
Here’s what they are basically trying to do (my take):
– We can’t get more employees in SLC, so we’ll open it up to the Churchwide masses who will helping out as a personal mission.
– They won’t hand over core algorithmic and core logic to the masses. That will be performed by the folks internal to ICS. What the masses can work on are non-essential projects that roll back into essential projects or support essential projects.
– It’s not really open source, by the classic definitions. But basically they’ll give you enough code access to modify things that need to be modified.
– ICS absolutely is not going to put in features in core tools like MLS that can’t be made available to other countries. If it can’t work in Africa, it won’t be a priority here. The focus for this stuff will be non-core work (maybe a new tool to help wards with HT and VT reporting, but you’re not going to be working on MLS).
I’m in charge of implementing this program for the Church. Some of the projects will be open source and some will not be. To be honest, some projects do not make sense to be open source because they have such a narrow and complete LDS focus AND/OR because we may have licensed code that we are using within a project that does not allow for an “open source” model AND/OR the project deals with membership or other sensitive information. Where we can, we will try to use open source licenses. Feel free to track me down via tech.lds.org and I can be more specific with your questions.
Tom
Howdy everyone. Thanks for the interest on the topic.
1) Open Source. We do loads of Open Source (both using and contributing). Nagios. Linux. eLearning. Translation software. And so forth.
2) Community Development. What we’re doing with community development is, as queno postulates, augmenting ICS staff with a worldwide community of passionate, smart people who want to help. Since my post, we’ve received a ton of interest from folks wanting to help out. We’re having a hard time keeping up with the new people who want to help. But keep coming!!
3) Sign on the dotted line. Because there are many who would love to make trouble (none on this site, of course), we require people to sign a document before getting access to source code. And for legal reasons we can’t let the code that is written be taken back by people. Has to do with commercial/non-commerical use, intellectual property, blah, blah.
4) John Dehlin, my awesome brother, rocks.
5) Web Services. We will be exposing some web services as part of these new apps. I can see a more typical open source ecosystem building around some of these services.
6) “Dismal ability to recruit potential employees.” Uh…
7) Toe in the water. The cool thing is that the Church is allowing this to happen at all. Can you imagine this 20 years ago? Or even 3 years ago? We’re taking it a bit at a time. Line upon line, you might say. We’ll make some mistakes. And we’ll do some great things. And over time we will harness the energy of thousands of saints across the globe who have the passion, smarts, time and desire to make things happen that might never happen otherwise.
And I think that’s just nifty.
My understanding is that you can use any code you contribute, but not any code the Church hands you.
I remember emailing the Church about 10 years ago asking why PAF wasn’t open sourced instead of allowing it to wither on the vine. That email was forwarded to somebody else internally who (1) mentioned that some of PAF’s code was written by contractors and the Church did not have the necessary legal rights to open it up, and (2) did not appear to believe that volunteers would be willing to work on such a project (apparently projects like Linux, Apache, Eclipse, etc. weren’t on the Church’s radar at the time).
Yes, I would prefer a more open approach. But I am happy to see the Church come this far, and I expect that with time we will see actual open source projects coming out of ICS (even Microsoft has released open source projects). Currently open source use is something of a one-way street. But as the Church gets stuck with the bill of maintaining internal versions of open source projects, it will eventually reconsider the economics of the equation ( http://www.onlamp.com/pub/a/onlamp/2005/06/30/esr_interview.html , http://esr.ibiblio.org/?p=928 , assuming the Church isn’t already pushing patches upstream). From there it isn’t much of a logical leap to opening code that originated with the Church (say, BitMountain).