Licensing question

[Mark James]

On 03/08/10 04:32, Chris Travers wrote:

> I don't know that the evidence supports the idea that open source
> software is necessarily more buggy than proprietary software.  If we
> look at security hole metrics, for example Veracode's recent report,
> they seem to be about the same.  The fact is that reliable, secure,
> robust software begins in the design stage with solid design
> decisions.  Certainly some FOSS programs are buggy, but so are some
> commercial apps.  I have even known one FOSS developer to refuse to
> fix bugs reported by customers with proper support accounts, but I
> suspect this is less common in the FOSS world than at, say, Microsoft
> (where bugfix effort is strictly limited to one team and where most
> likely making enough noise will get it fixed.... years later.... in
> the next release--- see IE7 handling of button elements).

Of course the advantage of open software is that one does not have to
beg some unresponsive god to make and release a fix, but can fix it
themselves, with or without help.


> The issue Mark was trying to resolve is a business model issue, which
> IMO is entirely orthogonal to the software quality issue.

I would argue a strong causal relationship between funding model and
software polish. Some FOSS software is polished simply because some
big companies see it as a competitive bulwark, or as an adjunct to their
proprietary offerings.


> I am going to offer a different perspective here as well on mass
> production.  I personally don't see anything "evil" about charging
> license fees, but I think that mass production is highly overrated.
> It certainly works very well for some products, but I don't think that
> small developers are in much of a position to capitalize on it today.
> Trying to make one's money off license fees poses greater risks for
> small developers.  Although the maximum rewards are often smaller as
> well, I think the risk to reward ratio is higher for a small developer
> doing open source work in many cases (not all cases, mind you--- it's
> HARD to make money off consumer segments with FOSS so perhaps
> consumers are better off with more choices for proprietary software).
>
> Basically when you look at the economics, the way a company like
> Microsoft develops software is that they pay a bunch of people to
> write it.  They aren't earning money during that time for that
> product.  When the product is finished, they try to recoup their
> losses and make a profit by requiring that people charge money for
> that product.  Not all Microsoft products ever make a profit (Bob, for
> example, never did), but Microsoft cross-subsidizes this and produce a
> wide variety of software which it hopes to eventually make money on,
> directly or indirectly.
>
> Startup businesses which do this either have to rely on savings of the
> founders, startup capital or the like during the initial development
> phase since they likely do not have other revenue streams during this
> phase.  Afterwards, the hope is the same:  find enough customers to
> make this money back and support development of the next version.
> However, in this case, you are starting in a hole you hope to dig
> yourself out of.  The more complex the project, the deeper the hole.
> The more competition, the harder it is to dig out of that hole.  In
> the early days of the industry, the calculation would probably have
> been different, but today, I think it is extremely difficult to make
> such money back as a small development shop without cutting all sorts
> of corners in the development and QA process.
>
> FOSS does this differently.  A small developer can often charge for
> development up front, and then use this work to find more customers.
> It's true this doesn't necessarily scale as well, but it in fact
> scales in different ways.

What do you mean Chris by "charge for development up front"? To earn a
living from FOSS one must either sell support services for a package one
has either written or has become familiar with, or to parley that knowledge
and reputation into work that is funded from non-FOSS sources. The only fast
road to income is to attach yourself to an existing project rather than to
write your own.

For the common situation where a substantial amount of software is being
written for general release, I think you are arguing that FOSS carries a
lower risk for developers than proprietary due to (1), community participation,
and (2), the marketing power of free. My response to that is the creation of
a licence that encourages community participation for open but non-libre
software, and to apply that licence to certain software niches, along with
support services and fair licence-fee schedules, such that most (happy)
free-trial users will willingly purchase licenses.

For most types of software, the services market is a small fraction of
the overall market (people willing to pay for a capability). So I
don't see why open-software developers shouldn't tap the whole market by
selling both licences and services, without being forced to go closed.
In my view the biggest risk for a start-up would be to limit itself to the
smaller services market.


> I am involved in FOSS not because I see it as fundamentally ethically
> superior, and I don't begrudge other developers the attempt to earn
> money off their hard work, but rather because I see it as the best way
> for the little guy to find a niche that provides a sustainable source
> of income.

I like open software because I see it as fundamentally superior in a
practical sense. But it's been tied to licences that make it harder
than it should be to earn a living by keeping things open.


> I think what Mark is trying to do is to sell his library to others who
> will then charge money for finished products.  Since he is upstream,
> that seems logical, but I make finished apps.  LedgerSMB isn't going
> to compete head-to-head with Quickbooks if folks want to buy a
> commercial solution.  Instead, we can offer something Quickbooks
> cannot offer, which is an open source, customizable, etc. which allows
> businesses to spend some money optimizing their own operations
> (building the software workflows around their processes, not building
> their processes around the software workflows).  Many of these
> customizations are small ($300 range).  A few are large ($50000 or
> more).  When 2.0 comes out, it will be suited for both the low end and
> mid-range.

Yes, open software is easiest to sell when:

   1. Aimed at users who demand or appreciate the ability to tinker,
   2. The software is a unique solution,
   3. The software benefits from being individually tuned,
   4. The software clearly saves the purchaser time and money, or when
   5. A low price is important (work contributed by a community
      on a gratis or speculative basis is cheaper than salaries).

But if development is properly funded and managed, open software needn't
require users to be sophisticated, and able to handle some rough edges.

For LedgerSMB, only points three and four are working in your favour.
You may be able to use your planned component architecture to
exploit point three for certain users -- giving power and exposure to
small developers like Apple did with its App Store. Do these modules
link in a GPL-viral way?

Perhaps a way around the GPL would be for someone to charge for
some polished documentation -- not as a book from a normal publisher,
but as a book, PDF, or interactive system for which "patches" are
accepted and possibly rewarded with free copies or revenue shares.

Mark