Re: Request for developer community feedback

[Chris Bennett <..hidden..>]

On Fri, Feb 10, 2012 at 05:57:44PM -0800, Chris Travers wrote:
> Hi all;
> 
> One of the issues which can limit LedgerSMB long-term is the question of
> areas of the software which may require periodic, locale-specific
> maintenance.  These include areas like payroll reporting and revenue
> reporting to relevant tax authorities.  The difficulty here is that
> typically in an open source model assuming that we aren't dealing with a
> lot of developers among our users, this creates an economic problem:
>  Someone has to pay for the periodic changes to reporting formats, rules,
> etc.  The ideal way to deal with this is through some sort of a
> subscription.  You pay, you get the relevant updates, and nobody has to pay
> the fill cost of maintenance.  The problem is making this work in an open
> source application which is community centered.
> 

This is a tough problem to solve well.
Tax laws change constantly and at many government levels.

A question:
How many different locales are actually in use right now?

I really prefer to see things left open, in case anyone decides to do
the development. People can convert into developers at any time. (Not
that many actually do it). Splitting off these items into non-GPL
modules sounds like a great idea.
I would think that once a separate module is broken off, updating a
local problem would be much easier. In Texas, we have national taxes,
county taxes, city taxes, state taxes. Each location in Texas would need
to have a module for each of these levels. Ugly, no?
I am looking right now at opening some locations in Guatemala, if that
works out. Yet another level of different taxes.
Still, a national US module, state modules as needed, county modules as
needed, city modules as needed might be the most effective way to deal
with this mess. How many levels do other countries have to deal with?
I would guess that perhaps a set of master templates could be
used as a fill in the options to get your special modules, adding any
quirks that aren't standard? Or is that a silly idea?

I do notice that there is no link on the site for donations.
This would need to be split between individual and business donations as
OpenBSD had to do.
OpenBSD has a setup to make a money payment through PayPal
automatically. This is a nice way to consistently donate without having
to remember anything to do each month.
I don't know how much money that would bring in, but couldn't hurt to
try it.

> I am looking at two options here.
> 
> The first is to create add-ons which do not inherit core modules but rather
> use them as an API.  These by our current interpretations would not need to
> be under the GPL.  My current thought at this point would be to release,
> say, annual updates to subscribing members under licenses which would
> revert to the GPL approx a year later.  The expiration of the restrictions
> would be set in the license itself.  The idea is that we would not be
> trying to perpetually hold the market, or even stifle open source efforts
> at such functionality, but just protecting our economic interest in a
> specific year's subscription updates.
> 
> The second is to create a contract which would tie restrictions on
> redistributing these addons to specific services offered, with the option
> of cancelling.  The problem I have with this is that I think that in order
> to make this work, we'd have to bundle the updates with additional
> services, and we'd have to make the contract more restrictive than I would
> like.  For example, we might make these available only to those with
> support agreements.
> 
> My sense though is that before I make such a decision, I would like to
> consult with the community, see what folks think.   I don't want to come
> across the wrong way or be accused of pushing for crippleware.  In fact, I
> would entirely support distributed approaches to these problems in
> competition to the services I am trying to develop.  I just don't see the
> market supporting such right now.
> 
> Best Wishes,
> Chris Travers

Chris Bennett