[H-GEN] Re: [H-CHAT] Bring back quality (Was sun guns for the desktop and for bill)

[ben.carlyle at invensys.com]

Ooops.

Oh... and P.S. Never ever release anything under the GPL. Use the LGPL, 
for the companys' sake! The GPL has scary rammifications for companies. 
It's better not to co-orce in my opinion. According to the FSF's GPL FAQ 
even applications released under the GPL might require other applications 
that use them to be GPL. This is just scary, people. Enforce a GPL-like 
license on your own software, but don't require anything using your 
software to follow the same philosophy. I really can't see any reason that 
a company would contribute to a GPL product that doesn't also apply to an 
LGPL product. In fact, sqlite is actually public domain and my company 
still contributed it for strictly economic reasons. Sure, you might bully 
some companies to releasing their own software as GPL by using the GPL, 
but it's just as likely you'll scare them off free software entirely for 
another few years. I mean, think of the children. Really.

:)


----- Forwarded by Ben Carlyle/AU/IRSA/Rail on 23/01/2004 02:27 PM -----


Ben Carlyle
23/01/2004 02:17 PM


        To:     Trent Waddington <s337240 at student.uq.edu.au>@CORP
        cc: 
        Subject:        Re: [H-CHAT]    Bring back quality (Was sun guns for the desktop and for 
bill)

Trent,





Trent Waddington <s337240 at student.uq.edu.au>
Sent by: chat-bounces at lists.humbug.org.au
23/01/2004 01:08 PM

 
        To:     chat at lists.humbug.org.au
        cc: 
        Subject:        Re: [H-CHAT]    Bring back quality (Was sun guns for the desktop and for 
bill)


> David Jericho wrote:
> > Chosing equally arbitary figures,
> > 9/12 * $50000 * 3 = $112500.00
> > For that sort of money I can buy a very very hefty set of Oracle 
> > licenses. Some itches can be too big.

> When you're talking this kind of money, you're either going to have to 
> pay it or you're going to have to use something that is not exactly what 

> you need (that's the thing about off the shelf software, it's just like 
> off the rack clothing).  If there is an off the shelf alternative that 
> means there are a large number of people who are in the exact same 
> situation you are (otherwise the software manufacturer would go out of 
> business).  Why don't these people find each other and fund the 
> development of an open solution?  Then they could pay the (much smaller) 

> cost of getting that open solution customized for their exact needs. 
> The reason, I think, is because the software manufacturer keeps their 
> customer list secret, and customers are so used to using software that 
> isn't what they want.

If a commercial product isn't going to give you what you want 
off-the-shelf, it's likely that an open source product won't either. The 
economics doesn't change depending on whether or not it's OSS. Net Profit 
= Gross Profit - Purchase Price + Customisation Cost. Each of these values 
may have ongoing components, and there's probably a fixed time-frame on 
the analysis to reduce long-term risk. Chances are your company wants to 
break even 1-5 years. The sooner, the better :)

Commercial Model:
Purchase Price = Money spent by supplier / User Count + Their Profit 
Margin
Ongoing Purchase Price = ditto for their maintenence work
Customisation Cost depends on how closely your use fits with what they 
intended.

OSS Model:
Purchase Price = Probably $0.
Ongoing Purchase Price = Probably $0.
Customisation Cost depends on how closely your use fits with what they 
intended.

It looks like the OSS model should win every time, doesn't it? Well... to 
be honest that depends on how big the user comminity is. If you have a 
company with a hundred customers who have exactly the same needs as you, 
chances are there's already a bunch of traning material and code to help 
you build a turn-key solution quickly. If you're the only customer, the 
product will probably not suit your needs and you'll have to spend a bunch 
of money to make it do so.

This is the area where commerical companies have the head-start. They have 
a bunch of users already who are quite comfortable with them. They have a 
bunch of money already flowing in for maintenence. OSS is like a startup 
in an established market. Chances are in this environment that the OSS 
solution will be more expensive, because you'll have to do more work to 
make it do what you want. Money keeps flowing into the commerical system 
based on sound business decisions and the OSS product continues to develop 
based on users with idelogical positions, or users with unique and 
interesting requirements that are filled no better by the commercial 
systems.

If, on the other hand, we assume that the customisation cost is the same 
OSS works better. The previous situation can also achieve a critical mass 
that pushes it towards this situation. In this case, why wouldn't a 
company use the OSS product? It's cheap and it's good and you might as 
well :) Then comes the question of whether you should contribute back to 
the base. There are two conflicting goals, here:
1) I don't want my competitors to get what I've invested this money in 
providing for myself
2) I don't want to spend any more money on this
It's really a commercial decision. 2) is interesting because in OSS if 
your code is useful to others, everyone gets to share the maintenence of 
it so you effectively get it maintained for free. This still doesn't help 
you if the code you write is specific to you. That will continue to cost 
you, but in my company for example code has been contributed back to an 
OSS product[1] specifically because we wanted to save money on testing and 
maintenence. We know and trust the lead developer to do these tasks 
admirably.

While there are some good products in the "just as good as (or better 
than) commercial" camp, there are also a whole bunch of OSS products which 
are nowhere near there yet. gnucash is no MYOB or Quicken, for example. 
This is where I think money has to come into play, in two forms:
1) Donations from existing users (including of time)
2) Potential users getting together and funding the gap between actual and 
required functionality

1) is easy, and worthwhile. If you get a lot of mileage from a product 
that hasn't yet reached critical mass, and you wish it would, perhaps you 
can be part of the solution. 2) is tricky, because people really exect 
things for free in the free software realm. It's difficult to "hook up" 
with others who want the same thing. They're hard to find, and chances are 
the people who needed the features have moved on after finding your OSS 
product doesn't have them. Perhaps what we need is a way to organise these 
pushes for functionality better.

Is suspect that moving an OSS product to critical mass is perhaps the 
hardest problem facing OSS software. It's something that requires a lot of 
input from users who are not necessarily technical folk. It requires a 
bunch of requirements, architecture, and design engineering. You need a 
really good stable group of developers to make it happen, which again 
means a bunch of people who both care enough to make it happen and believe 
that's low-risk work. I guess the same formula applies: Net Profit = Gross 
Profit - Cost. Someone has to feel that their profit (in monetary, ego, or 
"other") will be enough to outweigh the cost.

Of course, I may be talking out of my arse. It's friday, after all.

Benjamin.
[1] www.sqlite.org, the early triggers code was developed by a fellow 
employee of mine.