My earlier post on how we migrated to using Linux raised some questions. Some wondered why other churches, schools and Christian ministries did not do this (though there are many that have). Others wondered how they could do it themselves.
If I were to visit another church, Christian school, mission field, or other ministry for the purpose of upgrading their technology and moving to open source software, here is a basic outline of what I would do. Hopefully, you can use this as a guideline for doing this in your own organization.
Assess what you already have
Many times, people do not necessarily need to upgrade to the latest and greatest hardware. Especially in places where money is tight, reusing hardware you already have can be a great savings. A 10-year old computer running a modern operating system is possible and easy with Linux.
Along with that, I would need to know what infrastructure is there. Is there already a network in place? Are the buildings already wired? What servers, if any, are there? What is the current backup strategy? What type of printers are you working with?
Are there any proprietary programs that your ministry depends on? If so, some thought is going to have to go into how to export and import that data into another program. In some cases, there just isn’t an open-source alternative. In an instance like that there are options such as dual-booting, virtual machines, WINE or keeping a computer as-is solely for those programs.
What are your goals?
Technology is a tool. I can use a really expensive sledgehammer to put a nail in the wall so that I can hang a picture, but because it is expensive doesn’t make it the right tool for the job. You may not need the latest and greatest computer out there for what you plan to do. But, you need to know what it is that you plan to do.
Do you really need to be playing those graphic-intensive 3D games on your computer at church? Will you be recording services to digital audio? Will you do any video editing at all? Will you be using a projector? How many computers do you want and where do you want to put them? You need to have an idea what you want to do with the computers in your ministry not only now but 5-10 years from now. Have a vision, or you will be disappointed.
3. Explore your options
One wonderful thing about Free and Open Source Software is that there are numerous options. This can be a two-edged sword, though! What works for others may or may not work for you. Ask questions and do research.
One thing that is consistently at the top of my list is the support and the community that surrounds the project. A good community is good assurance for the integrity and lifespan of any program. Linux itself would not have survived if it weren’t for the incredible community that has grown since its humble beginnings in 1991.
Speaking of support, if you haven’t already done so, it may be a good idea to enlist help from others who have done this before. As helpful as people are on the internet, or even a phone call, nothing beats having someone there in person to help when you are having trouble.
4. Setup a schedule
Once you have some goals in place and have settled on what your needs are, you need to schedule a time to put your plan in action. Will it be a gradual roll-out or will it be done all at once? Do you have a plan for backing up files and importing them to the new systems? I would make sure that it was done a time that would be the least disruptive. Communicate with those whom the migration affects. Don’t delete the pastor’s sermon notes just before he goes to print them!
5. Do it!
At this point the only thing left is to execute the plan that was developed. Download the distribution of your choice (I use Ubuntu, but there are many, many others that may fit your needs better), burn the CD, stick it in your computer, boot it up and follow the prompts. You may get stuck at some point in the process, – don’t be afraid of asking for help.
These are some rough guidelines for switching to Linux and open-source software in a ministry, or really, any other setting. I would like to flesh this out into a nice flowchart or more detailed checklist at some point in the future. What did I miss? What other areas would you focus in on? If you have suggestions or even helpful criticisms, let me know in the comments.