Hi,
In September, the LedgerSMB project will have its 10-year anniversary. A
great milestone!
Not having been there at the time of the fork, I get the feeling that on
the outset, the "vision" or "goal" of the project was to be the "more
secure, more maintainable, more compliant, stabler" side of the fork.
While not all of the original goals have been entirely completed, huge
steps have been made toward most of them:
- 1.2 fixed most SQL injection problems
- 1.3 introduced XSRF protection
- 1.3 separated large parts of the business logic from the HTML generation
- 1.3 introduced separation of duties
- 1.3 introduced enforcement of access control
- 1.3 introduced many, many data integrity controls
- 1.4 completed separation of duties
- 1.4 introduced a modern UI with HTML widgets
- 1.4 introduced a framework for efficient implementation of reports
- 1.4 completed the ability to attach documents in lots of places (started
in 1.3)
- 1.5 makes the "modern UI" move complete
- 1.5 has loads of code cleanup at all levels
- 1.5 introduces "code quality" tests
- 1.5 introduces "browser based" tests
- etc.
With all these changes, LedgerSMB and SQL Ledger have an on-going
divergence where the original goal probably isn't working too well any
more. The question then becomes: if this vision doesn't work any more, then
we'll have to come up with a new vision, a way to define ourselves.
Over the past years, I think we have used the following guiding principles:
- Build a technically sound basis
a. Separate business logic, storage logic and representation
b. Create a database model which supports much broader use-cases than the
UI demands, simply because we can
c. Make sure we implement all the industry wide accepted -required-
security measures for web-apps
- Be as open as we can be on each level:
a. Provide APIs on database, Perl and web(service) level, or try to move
there
b. All development (and discussion) in the open, on GitHub, IRC
c. Using web-based services for easy contribution where possible (e.g.
Transifex for translations)
d. Involve our users, e.g. discuss requirements (where possible) on the
public mailing lists
Some of these come from the project's inception. Others, I believe come
from the conviction that the world around us is (or has) quickly changing
(changed) where not all functionalities can be built into the base
application, meaning that integration on a multi-system level should be
supported by the use of web services and exchange formats. In that world,
LedgerSMB would/could take a central place handling PayPal/CreditCard
payment confirmations, integrating with web shop and POS systems and others
which don't have full ledgers of their own.
Hence the slogan on the LedgerSMB.org frontpage: "Foundation for your
business" - which is also closely related to the "Statement of direction" (
http://ledgersmb.org/statement-direction-ledgersmb).
While the above does say something about the way we treat our users and how
we solve our problems, it doesn't really define for whom LedgerSMB is
trying to solve problems nor which exact problems we consider ours to solve
and which ones we don't - or for whom we don't.
As Chris puts it <<We went from being 'everything to everybody' (SQL Ledger
approach) to being 'anything to anybody'>> with the underlying assumption
that it's better to have people customize their instance for their specific
use-case ("mini-fork") than to try and fit all possible use-cases
(workflows) into every screen.
For example, we've just recently seen a very active discussion on the users
mailing list where a few different types of users can be recognized:
- Single person businesses doing their own accounting
- Accounting offices doing the accounting (once or twice a year) for small
(typically single-person) businesses (in arrears, that is)
- Multi-person businesses who have their own accountant who is also in
charge of payments and subject to peer-review requirements
These types of businesses come in various configurations:
- Sending (sales) invoices from LedgerSMB
- Sending (sales) invoices from other sources, later booking in LedgerSMB
for VAT reporting
(and maybe others)
These groups seem to have different lenience for workflow inefficiencies,
also based on different legal requirements depending on business size.
These are some of the things we're seeing with our users today. Other
trends we're seeing, where I guess we should want to define our position as
well:
* Digital data delivery requirements [ formats differ per jurisdiction ]
- Chambers of Commerce/Companies House
- Tax authorities
- Banks
* Digital invoicing requirements [ formats differ per jurisdiction ]
These requirements being put on businesses, raise questions for us to
answer:
- As a "foundation for your business", should we be able to support these
use-cases? And if we do, what building blocks do we need to put in place in
order to be able to quickly develop jurisdiction-specific extensions?
- *Can* we support all of these use-cases (data delivery) given the fact
that most governments require certification of the software? (And if the
independent vendors want to file for certification, what does that mean for
our project?)
And if we look further down the road, what more would you expect will
become part of the sales/purchase workflows and accounting&reporting in the
next 10 years? And how should the LedgerSMB project position itself in
respect of these expectations?
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
