Software acquisition and development
From MissionTechWiki
When it comes to getting software to support your work there are two main options: buy or build.
Contents |
Buy or build?
You can either buy some "off-the-shelf" software to do what you need, and then customise it to make it work within your organisation, or you can build it. Building, or developing, it can be done by an outside organisation or in-house.
Buy - pros and cons
Pros:
- Support - you will probably pay for some sort of support contract so that if bugs develop in future, or if the software needs to change, as a result in a change in government legislation for example, then you get an updated version. Although it costs money, once you've paid you have peace of mind.
- If you need staff to work with the system then it is possible they may have worked with it previously.
Cons:
- What you buy isn't going to do all you need.
- If the supplier goes out of business then you have no support.
- Staff will have to learn a new system when it goes live, or when they join you.
Build - pros and cons
Pros:
- If you specified it properly, which is not a simple thing to achieve, then you should get what you want.
Cons:
- This is probably going to be more expensive than buying off-the-shelf software.
- If the software is developed by an outside organisation and they go out of business then you have no support. Escrow is a good way of getting around this problem, if your supplier agrees.
- If you build it in-house then you are going to have to commit yourself to supporting it in-house. This may means the constant overhead of salaries for support staff.
Open or closed source?
Sweeping generalisations needed
Software development
Outside suppliers
For a list of software which may be useful in your ministry, consult the Church Related Software Index. There is also a list of free software in the Computer Re-use Optimisation Project. gjs
Need some good advice on dealing with these
In-house staff
Give them lots of coffee and pizza.
Volunteers
These are singled out for special mention because some volunteers come in and develop a system and then disappear without leaving any documentation. If you have a volunteer come in and do some software development then make sure that you get adequate documentation, not only on how to use the system, but also on how to maintain it. There should be some good technical overviews on how the system is built. It is good to get another software developer, even from outside the organisation if you don't have any inside, to review the documentation so that you can be sure that it is adequate for anyone needing to maintain the system in future.
Software always needs maintaining. Even if it is bug free, you may want it changed in the future, or if not you, then your successor. Your organisation may change the way it works in a way that means that that system needs changing.