Here's what I have observed. Agree or disagree as you wish. Please don't flame me (I'm human too!).
0) There is a level or resentment/hostility within the O/S community towards organisations which are interested in 'commercialising' the purity of O/S.
1) Certain Open Source (O/S) projects are outstanding in the level of commitment and contribution and development from a wide range of parties (amateurs, hobbyists, enthusiasts, commercial interests, community groups etc.). PN is certainly a remarkable 'upgrade' from the closed PHP-Nuke circuit, has suceeded in delivering a teriffic rewrite and code cleanup, great new features and a new version every 12 weeks or so with lots of improvements - it is going places and in the right direction.
2) There is not widespread adoption or support of Open Source products in a corporate/commercial environment. To a substantial extent there is ignorance of the existance of quality software other than through traditional vendors of proprietary solutions. How do you submit a Tender Document or RFP to the Open Source community?
3) The GPL's protection of 'without warranty' is appropriate to enable the development and use of O/S applications [in the public domain] while ensuring that there are no warranties expresssed or implied on the part of the authors. WYSIWYG! This is not an acceptable level of 'support' for a business critical application and is what scares most corporates away from even investigating the O/S route. In reality there is not much better 'protection' afforded by proprietary vendors/licenses but they are used to those and do not look as deeply as they should. At the end of the day they think, regardless of the legal protection of a license, "I paid the guy to do X, he didn't, get him in and whip his ass". As a paying consumer you have independent rights to protect your investment - the absense of contract or payment means you take what you get and shut up if you are not happy.
4) Because it is 'public' and 'open to anybody' to adopt/present Open Source solutions and because the 'barriers to entry' are so low (free) - anybody can set up shop and 'sell' O/S products and support. This is fine, but the lack of viable commercial model (i.e. revenue stream) on the part of many sole-traders/consultants is not reassuring the commercial world as to the practicality of considering O/S - this is the so-called 'Geek Factor'. The 'Geek Factor' is the most difficult marketing message for commercial proponents of O/S to counteract. Wear a wolly jumper, work from home, grow a beard, write O/S, sell mugs and caps on your website so that you can buy pizza and beer. Suits like to deal with other suits, in person, eye-to-eye.
5) No large corporate would consider adopting an Open Source product unless (a) there was a team [not an individual] of developers/support people in house with the skills OR (b) there was an external software house with the skills and a team [not an individual].
6) Free software is only value for money in the up-front licensing sense. The "cost of ownership" models (service, maintenance, adaptation) which apply to proprietary software still are the same if a corporation is adopting an Open Source product to use.
What we (proponents of O/S philosophy) need to make clear is that ...
=================
1) We are going to make money selling and supporting this. If we don't make money we won't be in business for long and the support will cease. Problem. The profit motive is a compelling case.
2) We have a team of developers/support personnel. The one-man-band is not viable for 'critical' applications. Most corporates regard the website as critical and also any services which are web-based. You have to be able to provide a credible SLA (service level agreement) and have the capacity and depth to meet the commitments.
3) There is no "Mickey Mouse" pass-off of responsibility (as defined in the GPL). In the GPL you take the software 'without warranty' etc.. A business will need better than that if it is to depend on the applications. This is the most essential clause in the GPL (to protect an author from any form of liability or responsibility). I know that most 'proprietary' product License Agreements actually make the same pass-off of liability/responsibility but they are not as blatant and people/organisations feel that there is some leverage with a vendor who is getting paid for software to ensure that it meets the documented functionality.
4) They are going either (a) to save money or (b) get better systems/service i.e. value by going down the proposed O/S route. The initial 'savings' are only valid if the total cost of ownership (TCO) shows savings.
5) No medium-large company will want to adopt a system if it contains a single critical point of failure. While the co-operative model may be 'nice' it breaks down if I can't sue a vendor of substance if they mess up. This is why it is difficult, even with small companies, to be successful at outsourcing software development or support if you are a 1-man-band. The exception is where there are clearly defined projects which can be outsourced and where there is the in-house team to take over at completion/delivery.
6) There are other benefits to O/S software which are somewhat more intangible but of value - especially the availability of the source code so that the traditional 'golden handcuffs' syndrome with proprietary vendors is not a factor.
Conclusion:
What is really boils down to, I believe, is that the real assessment of whether a solution is a GOOD SOLUTION is more dependant on the party proposing than the software itself. I (personally) sold accounting systems for years with lots of happy clients. Other resellers of the same product had lots of unhappy clients. Same product, different service, different customer experience.
My favourite line.. "Good, quick and cheap; which 2 do you want?". Quality, Responsivness and Cost are intrinsically linked in the real world.
Here's what we (Experience IT) would like to achieve:-
===============
1) To be able to tap into the expertise in the general community with parties who do not wish to have 'customers' only projects that pay fairly from time to time.
2) Be able to call on some of the core development team (email or otherwise) for that special level of support (from time to time) as might be required (and pay for the service).
3) Be able to work with specialists in areas (e.g. theme designers/graphics artists) who would be prepared to accept a brief and agree a fair price for the work.
4) Have a means to 'give-back' either through donation, revenue share, code share, hosting or other tangible form of support to the community which created such wonderful products.
1658