[kwlug-disc] the business model for open source
unsolicited at swiz.ca
Mon Aug 3 19:19:01 EDT 2009
OK, but, and Bob can correct me if I've misinterpreted what he was
looking for / where he was trying to go ...
Aren't consumers expecting things to work completely and correctly for
their needs out of the box? [Whereas the examples below pertain to
after purchase, or go against the common non-FOSS perception that if
something's broke that's just the way it is, live with it.]
i.e. Is 'more readily fixed' an argument that will fly with what Bob
is trying to present?
Perhaps it's pertinent to think ... Mr. Consumer, the better you are
able to define the functional points you need, the better your chances
at unveiling a successful result from the get go. [And if no solution
out there, FOSS or not, delivers 100% of the functional points upon
installation, look to Richard's message below for the advantages /
talking points Bob was looking for.]
So, some (no doubt already thought of) points for Bob would seem to be:
- people are looking for solutions. That it's FOSS or not is irrelevant.
- if there's an appropriate FOSS solution out there, it makes sense to
keep more money in your own pocket. Or, take some of the money you
saved and invest in the solution. The fact that everyone benefits from
your investment, not just yourselves, is at the least a more
humanitarian use than just pouring it down the drain into the
proprietary provider's pockets.
- the world is becoming more open/compatible = you will ultimately
increase your vendor / client / employee compatibility with the rest
of the world, sooner.
- there are very few widely used / compatible solutions out there that
don't have FOSS equivalents. MS Project and Visio come to mind as the
only two - in an office desktop environment. There is no reason not to
- FOSS lets your data be under your control. e.g. In-house e-mail
server / ability to recover should the worst happen. (vs. having to
have someone delve into a proprietary system, perhaps after paying
them to effect an NDA with the provider.)
- consumers want a quick fix solution and grab low hanging fruit, on
the assumption that the magic wand wave will make everything go away
and be solved and happy. When it doesn't, they just ignore the lack of
those functional points and get on with their day. PYWWYP - the better
they define their needs and plan up front (particularly before a life
or death critical cut over) and take the time to find a matching
solution (FOSS or not), the smoother the implementation with less stress.
- lets get off the upgrade treadmill. Will MS Outlook v.432 really add
value beyond Evolution v.2, particularly given the aggravation of all
the upgrades necessary before v.432 is available?
- Size matters. If you're a 4 person shop, go FOSS and get on with it.
If you're large, FOSS or not, consider a lab / test / staged
implementation of the solution. The grass isn't greener over the hill
until you've peeked over the top to verify it, and not been crippled
along the way such that you can't walk to the top of the hill to check
things out. Having done due diligence and implemented your solution
... see upgrade treadmill comment above.
Richard Weait wrote, On 08/03/2009 6:40 PM:
> On Mon, Aug 3, 2009 at 2:42 PM, Robert P. J. Day<rpjday at crashcourse.ca> wrote:
>> yes, i realize there's lots of this out there, but a friend wants a
>> small number of references to online explanations that lay out the
>> compelling reasons to adopt open source IT infrastructure, as opposed
>> to proprietary solutions -- as much as possible targeted at the
>> *business* people, not the techies. for example, simply saying that
>> the source is available has no interest to these people. after all,
>> they never read their developers' code, so why would they care?
>> so ... any pointers to high-level *business* defenses for open
>> source in the corporation? relatively recent stuff preferred, of
> I'll start with only two reasons, there are hundreds. Personal
> attention and Continuous improvement.
> Personal attention.
> This anecdote was told in the first person at KWLUG some time back.
> One of our members was using a particular FLOSS project at work. He
> decided that adding a specific feature to the project would make
> things better for him at work. He contacted the project leader and
> asked about the new feature. Our member provided a modest feature
> bounty to the developer and was provided with the improved software
> within days.
> Continuous improvement.
> This anecdote was told in the first person at a software course. A
> developer found a bug in a FLOSS project and had time to file a bug
> report before attending a previously scheduled event. The bug report
> included how to reproduce the bug, what the expected result was, what
> the actual result was and the version of the software that exhibited
> the bug. When he returned from walking on the beach with his family,
> another developer had found the bug, created a patch and submitted the
> patch for approval from hundreds of miles away.
More information about the kwlug-disc