There are compelling reasons for a nonprofit to migrate to FOSS. There are also some pitfalls that can be encountered if the needs of the nonprofit are not thoroughly analyzed – as the following story illustrates.
In 2002, two Circuit Riders travelled to a small town in Missouri to help migrate a small low-income organizing group called GRO from Windows to Linux. Robin, the lead organizer, had her computer completely wiped out by a virus, and she'd had enough. So they spent a week installing Linux on the GRO computers, training the staff and leadership. Everyone was surprised at how easy the Linux desktop was to use and seemed happy with the suite of applications that came along with it. This was done as part of the LINC Project, whose Circuit Riders were charged with helping low-income community-driven organizations use technology more effectively. At the end of the week, everyone was enthusiastic about the migration, and they congratulated themselves for a job well done and went home.
Less than a year later, GRO had migrated back to Windows. Why? Clip Art! Brochures and posters were the lifeblood of the organization, and Robin missed the Clip Art that was available to her in Microsoft Word. Another key element was planning for ongoing support and maintenance. The Circuit Riders were based in New York City, which was not an optimal place to be doing ongoing support for computer systems in Missouri. GRO was more likely to find help for Windows systems than they were to find help with Linux.
Migration has always been a key focus as a strategy for working with nonprofits and civil society organizations, moving people away from proprietary systems that were expensive, trapped their data and gave them a lot of grief in return. But as the story above illustrates, migrating to FOSS first requires that you accurately determine your needs. You might choose to conduct a total migration of all your software or just a partial one. It might mean you're adopting a software package that has been specifically designed to meet the needs of your sector, such as FLUXX, CiviCRM or TOR. Or you might be working under some very unique circumstance and want to either modify an existing piece of FOSS software or start a development project from scratch. Where should you start the process of making such an important decision?
The process for choosing FOSS is pretty much the same as choosing to use any technology within your organization. The place to start making that decision is quite simple, start by reading your mission. Then ask what are the key challenges your organization faces in fulfilling its mission.
Once you have a list of key challenges your organization faces, your next step is to assess your current use of technology. Identify the key tasks and functions that your organization engages in to fulfill your mission. Some key areas to explore are communications, stakeholder engagement and fundraising. Also look at things like planning and project management. How well does your technology support your key tasks and functions? What works well? What should remain untouched? What needs changing? If you can prioritize your tasks in relation to what's most important to your mission, you can start prioritizing changing your systems.
If you've gotten this far, you are well on your way to creating a technology strategy for your organization.
Though one of the winning things about FOSS is the ability to modify it, that's not necessarily something you should do. You want software that will meet your needs without having to modify it. The key functions that you created in the previous exercise are the most important checklist you can have in conducting a search for the right FOSS solution. Start asking: what else is out there? What software/tech solutions already exist that might help you address your challenges?
When you are researching solutions here's some key questions to ask:
Will it meet all of our needs right out of the box? While the potential to create and modify FOSS is always there, you're a nonprofit and not a software developer. If the software doesn't meet most of your needs out of the box, it's probably best to look elsewhere.
What will the costs be to support and maintain? You may need to employ a computer professional, skilled in FOSS, who can make the needed changes and provide periodic maintenance.
Will your staff/stakeholders find it usable? Productivity is key, you don't want your staff wasting time because they can't access the functionality they need. Also, as software is more and more available via a web-browser, you don't want your staff turning to unsecured and untested solutions that are available online to get their work done.
How much training will it take? Training on any technology is always advisable. Whether you conduct a training in-house (led by a staff person) or bring in a specialized trainer, trainings give an opportunity to ensure everyone has the expertise they need plus it gives an opportunity to raise any issues/problems that people may have.
Will it run on the hardware you have? Always check on the system requirements. It's not going to be cost effective to have to replace computers just to run software.
Is it secure? If your work is highly sensitive, is this software that has been "hardened" to provide extra layers of security?
Can it be shared/deployed with your partners and collaborators? Are any of your partners/colleagues/allies already using it?
Will you be able to get technical support for it? If you have a problem, will you be able to find a local consultant to fix it for you?
Does it have a healthy support community? Are there other nonprofits who use the software and with whom you can exchange tips and solutions?
Is development still active? Have there been recent releases? Are new releases in the works? Are periodic updates issued, ensuring there are patches for bugs and security holes?
Once you've identified solutions, the next step is to create an implementation plan. Key elements to explore here are:
Pilot opportunities: Can you deploy it with a few individuals on staff to test it out before making wider deployment? When you do deploy it throughout your organization, these individuals can help guide other users in how to use the new software.
External expertise: Your software should work optimally out of the box – but you might need to hire someone to help with the initial setup or make some minor tweaks to get it right.
Evaluation: Build in opportunities for user feedback. Make sure you stay on top of what works and what doesn't once you've deployed it.
Timelines: Tech projects ALWAYS take longer than imagined. Map out a time line and then quadruple the amount of time it will take.
Organizational Calendar: Are there slower times in coming months when disruption of systems can have minimum impact?
And of course, you will need to create a budget; make sure you have enough resources for implementation. Remember, with FOSS (and most software) costs typically begin AFTER you install it.
And the final step: Implement the plan (and don't forget to include evaluation in your implementation)
During and after your implementation, always participate in the development community that is around the software – report any bugs, ask for new features, tell them what works. If you do want to modify the software, do it via the developer community. Remember, if you modify it outside the developer community, you'll not be able to make use of upgrades or security releases.
There has been error in communication with Booktype server. Not sure right now where is the problem.
You should refresh this page.