I think you misunderstand the problem I am trying to solve. More below.
On Sat, Feb 11, 2012 at 2:21 PM, Erik Huelsmann
<..hidden..> wrote:
Hi Chris,
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.
The problems that I see with localized features such as taxes (in any number of areas) is the fact that any default settings we are providing are getting dated quite quickly. Even with VAT we're already seeing this happen.
Yes. And it's not just default settings. If we really want to compete and support, say, electronic filing of taxes, then this opens up whole new areas where the software will get out of date fast. I think you'd agree that we cannot solve this with the current community we have and the current structures we have.
Add things like payroll witholding logic and reporting and we'd have a tremendous mess.
The only way we will solve this is if there are businesses on the ground in these locales which are proviidng updates to us. Otherwise it's too many jurisdictions to track.
You write that the number of developers between our users is a problem. And in fact, it may be. However, what about actively advertizing that we're looking for vendors - people wanting to sell their services - to provide local and localization support?
That's actually part of my plan. The idea is to work with folks on the ground in these areas. I'd do development, and they'd resell subscriptions and keep me informed of necessary changes. However, the sort of interesting part here is that the add-ons would be non-GPL just for the subscription life, thus providing a codebase for anyone who wants to start up open source modules of these sorts and keep them current. But I can't even track the required changes myself.
If we were able to provide a way to allow users to script the tax calculations using parameterized calculation rules we frequently see in the typical areas of application, then the user may feel like he's specifying something as simple as an excel calculation rule. Most of our users understand how to do that.
Again that's fine for some things. Payroll though often gets very complex, and if you get into electronic formats, then you have a bigger maintenance point, and a greater opportunity for things to break.
I guess that for now I'm not really seeing where the difference between 'coding correct bulk payments and bulk payment reversals' and 'coding a system allowing locale specific tax and payroll calculations' comes in. In either case, a large effort is involved and nobody is (directly) paying for them - other than you and me taking the effort to make the investment.
The big difference is this: bulk payments/reversals are features that everyone needs and are well defined/understood in terms of their requirements. Once we get it right once, then it is just a matter of maintaining code, not updating it for annual rules changes. Something like electronic reporting of revenue to the government, or payroll tax withholding logic is something which is locale-specific and frequently changes. Because it is locale-specific we would need someone on the ground in that locale monitoring the requirements. Moreover we have to budget annual effort to update the changes.
In essence I see really three areas of effort needed to make LedgerSMB viable for the masses:
1) Major features development which are widely applicable. (Bulk payments/reversals qualify here)
2) Something like a sales tax rate which may need to be updated periodically but is only minimal effort in doing so.
3) Something like payroll tax withholding or annual forms changes where regulatory compliance is a moving target, and local in scope.
I don't see a case to be made for me to donate a lot of time to #3 unless my business is affected, and the problem with saying that someone can pay me to do it is that this means that there is no way of dividing the costs up in a reasonable manner without passing the hat every year, and as I say I would feel funny about using a US donor's money to support Singaporian payroll tax withholding.
Hope this distinction makes some sense.
The main problem that I see with the locale specific stuff is not to be able to code it, but to acquire the knowledge to do it correctly. I see that as a problem we can put on the shoulders of local vendors: people who should know their local markets.
Yes. But in the absence of a strong market there, I think the best we can do is create partnerships that are structured so they can grow into that.
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.
Looking at the two options you have now, I'd like to go with the first option as well. However, I'd even more like people to donate money (or the effort/rules themselves) so we can implement the rule engine and the localized rules and release them with our software like we do with all other functionalities. Hmm. I see me iterating myself. I guess I'm not used to the idea yet.
What are your comments to my reaction?
I think we are both on the same page. I think a lot of my ideas are intended to try to jump start this process rather than simply wait for it to happen. Ideally someone who acts as a subscription reseller and takes on the responsibility to inform me when something needs to change can evolve into an actual maintainer, and may even be able to share effort with other developers.
Best Wishes,
Chris Travers