:: lindsey ::Lindsey, Patrick and I were yakking at Angelo's about this and that geeky topic, Patrick being generous with the beers.
Lindsey, a fresh face in Portland, shared her perception that FOSS (free and open source software) has meant "unsupported" in much of corporate America, or, as I'd sketch it: somebody's brother in law writes a custom application and then vanishes, what next?
Because the tools were free, the barrier to entry was low, but now company X is left holding the bag. This happens in the nonprofit sector all the time.
That's not really a FOSS issue though, as we had the same phenomenon when the tools were not free. The client either paid for the tools, or more likely the developer paid for a development environment, like Visual Studio, and the client had some runtime abilities, maybe with no source code whatsoever. If the brother in law vanished in this case, the situation would be more dire still.
If it's an important application with a long life span, you'll want continuity in personnel, even if individuals pass the baton and move on, meaning you'll want a bevy of developers (people tasked with developing), version control, and well documented source code. A company isn't expecting too much in wanting this for itself.
However, I was also schooled to promote self sufficiency and independence in the nonprofit sector, so the best solution of all involved training up geeks in-house, getting the application supported internally.
Sometimes you just need to outsource the initial design and first iteration, accomplished in tandem with developers, but then tweaking, enhancements, or even coding a whole derivative application (i.e. rather similar to the first one), becomes part of the job description of in-house personnel ("in-house" might include working off site on occasion).
For example, so-called "end users" liked Microsoft Access because they could add fields to the database and tweak the screens to show them. You didn't need to rely on some remote authority to make these little changes. Microsoft Access allowed for more autonomy (which sometimes meant a big mess, live and learn).
However, Access doesn't scale well as a multi-user application on the server. Microsoft would prefer you use SQL Server for that, with Access a client maybe, although these days a preferred client is the web browser itself. But once the application is on the server, what happens to all that autonomy? Aren't you at the very least now at the mercy of the IT department?
These are workflow issues, less than software issues. It's true there's no FOSS tool quite like Access, or at least Rekall and the database features in OpenOffice don't seem quite the same thing. But when it comes to server side applications serving out through an intranet (i.e. not "world facing"), FOSS shines.
What doesn't shine in many cases is the ability of in-house personnel to control their own destiny, with software tools of any kind, open or closed. From their point of view, it might just as well all be closed, because "source code" is just gobbledygook.
Per Guido's CP4E (Computer Programming for Everybody), a core goal is to demystify the code base to where company X is empowered to maintain more of its own applications, because the source is all there, along with the documentation and people who know how to tweak it.
If cube farmer Y is one of the five people tasked with database schemas (say some relational system in Postgres), and finds a job with a different company, then she trains her replacement and moves on. The company still has five people trained in that area.
Of course not every small business is big enough to put five people on anything. Nevertheless, if the developers demystify as they go, supply training and source code, plus serve as professional hand-holders if there's a serious overhaul in the cards, not just small fixes, then the resulting in-house culture will enjoy more autonomy and self-sufficiency.
If a field needs to be added, a template changed, even a sole proprietor might make those changes, between manning a cash register and baking scones in the back.
Bringing out your inner geek, training her, feeding her, could be a goal of some of your educational experiences. Offer to become your employer's point person in working with developers and suggest to your CTO or other manager that in-house autonomy, which requires access to source code, is a cost saving measure in many cases.
Of course many developers are snickering in their sleeves around now because they know their gnarly C++ or Java application is just way too complicated for any end user to enhance or debug.
Their job security depends on their being professional coders and their giant closed source application is for authorized personnel only, and that means clients will need a support contract and will just need to get in line for service. If the client ventures to make changes, that voids the support contract.
On the other hand, many clients don't realize how a simpler solution might actually fit the bill, how sometimes you just need a different tool set or a different set of developers more willing to empower client companies.
So if you're a company, shop around. Don't just assume you need to outsource indefinitely and think twice before investing heavily in source code you'll never get to see or modify, especially if you're Uncle Sam. If the public is funding your project, FOSS is the way to go, if you're serious about leveraging the net benefits (i.e. really serving said public).
Given my "empower the client" philosophy, you might see why I come off as such a fiend around overhauling math teaching. We need students to eyeball more source code, write more of it themselves. As a nation, we shouldn't be outsourcing everything. I see this as an opportunity to get real, pass on a lot of skills people actually need. Plus I don't skimp on the actual mathematics.
