[kwlug-disc] the business model for open source

[unsolicited]

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 
go FOSS.
- 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.

FWIW.

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
>> course.
> 
> 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.