David Tangye wrote:
The limited resources of two people is more than the limited resources of one person...just a thought.Your ideas sound generally excellent to me. At this stage of embrionic development of LedgerSMB, it only a question of strategy, and what I thought would happen, is happening: LedgerSMB is quickly diverging from SL. I see no problem with this. Its only a question of realising this, and planning etc accordingly. Eg: with the still limited resources that we have, consider the decreasing likelihood of not being able to keep a migration option into LSMB, let alone reversing it. In fact forget reversing it as of now?
I agree. Diverging isn't a bad thing. Robustness is important. It is important in my mind to keep our options open though. I'm not ready to transfer my 3 years of accounting data to LedgerSMB but once I do, I would not expect to be able to go backwards. The data would somehow have to be verified to ensure it was compatible. I don't know if that means that certain id's would need to be modified to work with the unique id patch etc.I think that the best way forward is to be sufficiently confident to diverge. There is little point in just being SL with its data schema and a few patches and add-ons on the side. To get a more robust and flexible application you need a better more robust data schema anyway.
If by some chance the entire database cannot be ported forward, at the very least some tables such as customers and parts need to be portable.
Perhaps a good idea would be to have an irc meeting where several people can discuss some of these ideas. It's pretty easy to start a channel on freenode.net for this purpose. It only makes sense though if the developers are willing to use the resource. The fork/spoon/spork has been made. What we as a community need is a clear vision of what the plans are for the future. Both immediate plans and long term plans. If no roadmap exists, the project may not be as successful as we all hope it will be. (openpbx is a good example of this where several develops left the Asterisk project to create their own project which hasn't really done much)The best scheme will probably not be apparent until the scope of the application is defined, and architecture/design defined based on that, ie a bit more top-down development, rather than bottom-up.
Darrick -- Darrick Hartman DJH Solutions, LLC http://www.djhsolutions.com