“here’s the code so you can work on it for free but you can’t use the code for anything else.”

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).

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.

Tom

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).

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).

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

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.

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.

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.

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.