Licensing question

[Chris Travers]

On Tue, Mar 9, 2010 at 8:12 AM, Mark James <mrj at advancedcontrols.com.au> wrote:
> On 03/08/10 04:32, Chris Travers wrote:
>

> 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've worked with a lot of software, and most of it is not very well
polished.  The polish usually comes from resources, but these aren't
necessarily just money.  Community help, etc. is important.


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

A lot of the customization I do I carefully divide into two levels:

1)  What is generally applicable and needs to go into future releases.

2)  What is customer-specific and needs to be separated from the
future releases.

We work hard on maximizing the first category and minimizing the
second.  The benefit for the customer of doing this is that they still
get competitive advantages of their workflows being protected from
being further inclusion, but all the base business logic usually gets
included in future releases.

All of that work is billable and while I also do some non-billable
development time in things I think will make me money later....

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

No. I am arguing less risk because you can start with a smaller
release and bill for time making it work for more users.  Yes, you
have to have some original code (and presumably an application which
works to some extent), but if you are selling software, you really
need to start with something that is closer to what is immediately
needed.  It's the difference between selling the effort of building a
solution for a customer and selling the solution.
>
> 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.
>
In my experience many users eventually turn to customizations of
business software (even small businesses with modest incomes) because
a modest investment in minor customizations may go a long way towards
bettering a given business's internal processes.

Back in the day, Microsoft commissioned a set of studies called the
"Get the Facts" campaign.  One of the things that the IDC, Gartner,
and others concluded in these studies was that FOSS solutions usually
cost customers more to implement and maintain than proprietary
solutions.  Microsoft tried to take the position that they were the
low cost solution and everyone laughed at them.

However, a close look at these studies fit my experience fairly
closely and suggested to me that the interpretation, rather than the
data, was what was flawed.  Yes, companies were (and are) spending
more on FOSS than they would on proprietary software over the life
cycle of the product, but if you look at where the extra effort comes
from, it is usually hired consultants.  And in my experience, this
extra effort is simply a matter of ensuring that the solution
implemented is optimized for a business.  Businesses are putting more
money into the solutions because they get more benefits out of doing
this.  My experience is that businesses which would not otherwise
purchase services for a commercial solution are often happy to
purchase services for an open source solution.  Probably a third of my
customers are in that category.



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

Depends on the software.  Vim will require users to be sophisticated,
as it should.  So will LaTeX.  So too will LedgerSMB.  These packages
are aimed at individuals with specialized needs.  If you don't have
specialized needs, use GNUCash instead of LedgerSMB, Scribus instead
of LaTeX, gedit or notepad instead of Vim.......

As far as rough edges, we are working on removing the rough edges. A
lot of this though has to do with proper design and we forked from
program that had, and still has, serious fundamental design flaws
(though I am sure all of us have written a few of those) which have
tended to get in the way.

There are certain things I pay for.  When we get to 2.0, I expect to
raise money (one of the few exercises in asking for donations) to try
to get the software certified by Veracode.  I may pay for a lot of
that out of pocket.
>
> 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?

Some do, some don't.  The application is architected in order to allow
for multiple points of integration and in 2.0, this will become a
major feature.  I suspect inheriting our db mappers and base utility
classes would make the GPL binding.    However a lot of this is fairly
light-weight automation stuff and could be implemented differently by
a different programmer.

Our community documentation is BSD-licensed for a couple important
reasons (in particular, I was concerned that allowing for aggregation
but not deep modification would mean that anyone who wanted to publish
the docs in a different book would simply get around the GPL by
putting it in a separate part along with a copy of the GPL, and the
project clearly agreed the GFDL was not free enough for the project).
The BSD license for the docs here actually is likely to increase our
ability to use them as a fundraising project because unless you get
from a trusted source (the project), you don't necessarily know you
are getting the authoritative version.

Best Wishes,
Chris Travers