Creating a plan for your FOSS Project can you save you many, many headaches. Creating timelines and budgets will help you think through the resources you need and preempt many potential problems that come with most technology implementations. In this chapter, we give you pointers for planning in four different areas: working with consultants and developers, creating a budget, migration, and interacting with the FOSS Community.
You've decided that migrating to FOSS would be beneficial for your nonprofit. But you are not a computer expert yourself. So your first step will likely be to bring in a consultant or developer who is experienced with FOSS and can help you work through the numerous steps – and avoid the pitfalls – of migration. The consultant/developer can also help with the next step, preparing your budget for the project. Importantly, your consultant might even advise you that a migration is not appropriate for you at this time. (For more on finding a consultant or developer, see Chapter 5 below, "How to get support for your FOSS project.")
It's also likely that you will need to hire someone to help you set up and configure your FOSS package, and for long-term support. In some instances you may need to hire a developer to customize and modify the software so that it works better for the needs of your organization. Whomever you hire, you will be best served if they are part of the development community for that package. Here are some good reasons for this:
Your experience with the software can be feedback to the developer community and they will learn from your use of the software, both good and bad.
If there are features that the software lacks, having contact with the development community means that you can be informed as to whether they plan to address those features in a future release or if they can consider addressing it.
Also be very wary of any customizations of the software being done outside the development community. This might be presented to you as a cheaper option but in the long run it will cost you more money as any custom code that is not fed back to the development will mean you are prevented from upgrading to new releases.
Along with strong engagement with the development community, some other good practices in hiring a consultant are:
Initially utilize a short term discovery/scoping contract where the contractor spells out costs and time for a second longer term contract.
Make sure you understand exactly what you are paying for – how much time and how that time is being spent. If you are paying for long term support, make sure you clearly understand the parameters of that support.
Keep part of your budget for a consultant in reserve – only reveal 2/3rd of your budget to the consultant.
After working with your consultant/developer, you should have a general plan in place. Now you can address the details of budgeting and migration.
Switching to new software is not a step to be taken lightly. Preparedness is key. Even with the most careful planning you will undoubtedly come across unseen problems, but the trick is to minimize the likelihood of unforeseen disaster. Here's a checklist for your migration.
You're assured the new FOSS will meet your needs as best it can.
You've identified all the resources, financial and technical, and the expertise you will need.
You've involved your staff and included them in the decision making process.
You have a training and support plan.
Your data is exported in a format that can be imported by the new software.
You've conducted pilots, testing with a few staff people.
You've checked the organizational calendar and have chosen dates that are less busy for the organization.
Stay one version behind in your upgrading – this will avoid any headaches with new releases. Thats one major version behind! A major version is usually demarcated by a whole number, such as "5." A minor version is demarcated by a decimal point, such as "5.1."
Use software that other NGOs are using. For instance, use Ubuntu as there's a large NGO user base that helps ground it in NGO needs.
Though FOSS software is free to acquire, as with all software, most of the cost comes after you install it. This is in both time and money. The "Free" in Open Source Software does stand for free as in "freedom," rather than free as in "free beer." A more accurate analogy, as far as costs, might be free as in "free kitten." The costs for acquiring the software might be nothing, but you'll find you will have to spend money after you acquire it – whether it's just for setting it up and configuring it or needing to have minor adjustments made.
Hopefully, the software you've chosen is one that works right off the shelf, and there's no reason it shouldn't. But once you've installed it, then what? You'll need to make sure it's configured, that your staff is properly trained, and that you have time to install security patches.
Some General Rules for budgeting
What you think you'll need in terms of money and resources, will probably be only 50% of what you really need. This includes the amount of time needed to set it up and configure.
Never reveal to a vendor or a developer the maximum level of your budget, always act as though you have just 2/3 of what you actually have. This will give you some cushion in case there are unseen costs.
A major proportion of you budget should be set aside for training. A good ballpark is 70%, but this should be a one time cost. Make sure key staff are adequately trained to teach others.
If you are using a FOSS Content Management System (CMS) to support your website, your costs should be in the range of zero to 10,000 USD. If you are edging closer to 20,000, there's something wrong with your costings.
Remember that developers and consultants need time to interact with the software community – it's good practice if the consultant is letting you know that you are spending money on time for them to do that.
Spending money on software is not a bad thing, and it's important to realize that everyone involved in software development projects need to make a living to sustain themselves.
Even after your migration, there are important reasons to continue interacting with the FOSS community. FOSS improves and succeeds because of the willingness of its many participants to contribute back to the wider community. That's how the software gets better, and the FOSS community is the well from which you can draw when you need assistance.
The FOSS Community, in general terms, is a group of people that believe FOSS should be promoted and is comprised of advocates, experts, developers, and end-users. Within the FOSS Community there are many subsets of communities, some supporting use of specific software or software types (such as Linux user groups); some, such as the Nonprofit Open Source Initiative, who advocate for use of FOSS in specific sectors; and ones created to support the development of a specific piece of software. Any one of these communities may be able to provide support for your FOSS project, it's just a matter of a) knowing how to find them, and b) understanding how to engage them.
User groups are often built around specific software or types of software (such as Linux User Groups). User groups are often regional, such as the New York Linux User Group (http://www.nylug.org/home/index.shtml) and will hold face to face meetings and events. A Linux user group will hold install fests which are great ways to get hands on help. They also usually have an online discussion forum where you can get remote help.
Organizations like NOSI and Aspiration hold meetings that are designed to bring together end-users from a specific sector with FOSS developers in the hopes of incubating new projects or to help take existing projects to a new level. An example of this are Aspiration's Nonprofit Dev Summit (http://aspirationtech.org/events/devsummit12) and Penguin Day (http://penguinday.org/) that is held in conjunction with the Nonprofit Tech Conference (NTC).
As most FOSS is developed by a community of software developers, there is usually a number of different ways to interact with the developers connected to a software project. Most commonly are Internet Relay Chats (IRC), which is similar to instant messaging, where the developers communicate in real time. There are also email based bug tracking systems, specifically set up for end users and testers to communicate problems and document the efforts to address them. Wikis often act as up-to-date manuals and also contain Frequently Asked Questions (FAQ's).
There has been error in communication with Booktype server. Not sure right now where is the problem.
You should refresh this page.