This chapter of Allen Tucker’s Client-Centered Software Development got me thinking about a lot of aspects of software deployment that I’d never really considered before. The dynamic of working with the client and the hosting service to try to negotiate the best means of integrating the software into the client’s website or web service was the first thing I came across (also the first topic of the chapter) that I hadn’t thought about. One thing I’m not too sure of is how, when using the “hands-off” approach in which the code base is physically on the server, organizations such as the NPFI actually update the code base themselves as opposed to relying on the hosting service. Perhaps this is done through a series of requests to the software running on the server?
Another element to deployment I hadn’t thought about before is providing support for different distributions of the software, assuming it was designed for this purpose in mind. I could see how managing support for multiple distributions could cause a headache, thus explaining why entities such as the NPFI are so widely relied upon. To fix bugs in these software distributions, which may pop up all the time or only intermittently, one would need someone dedicating a decent amount of time to the software either way to be effective. Say for example I don’t touch a piece of software for months and someone comes to me with a bug in a new distribution that I now have to understand and fix for the client to use the software. Then, my task is made infinitely more difficult by the fact that I probably forgot many of the finer details for how the software was supposed to work in the first place (i.e the distribution I worked on or was most familiar with). That’s why building a community and giving an incentive to work on a CO-FOSS project is so important, and in practice, I’m sure that not many CO-FOSS projects rely on just one or a handful of developers to fix all of the bugs that appear in the future. We have now all had experience with the management and oversight needed integrate changes to a piece of software made by the community, and this chapter has given some good insight into just why those practices can be so valuable.
Noah Drake's Blog 