[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GNUe] Re: Meeting Summary for Monday Jul 26, 2004
[GNUe] Re: Meeting Summary for Monday Jul 26, 2004
Fri, 06 Aug 2004 02:52:51 -0700
Mozilla Thunderbird 0.5 (X11/20040306)
Hi guys. Sorry for the delay.
The following is a summary of the Meeting Held on Monday, July 26,
2004. The minutes are organized by topic for clarity, and the
commentary is heavily paraphrased as IRC discussion threads tend to be
non linear - a diametrically opposing format to a linear summary
document. I hope I got everyones intent correct, my appologies
aforehand for any errors - please file corrections to the group if you
feel your commentary and or intent were misrepresented.
*** MEETING STARTED ON Mon Jul 26 13:07:21
Topic #1 - Packages and standards:
- First suggestion was to better define the gnue packages, how complete
they should be, should they comply with any standards
- With regards to standards, the question of what would be worthy
standards to follow came up. It was suggested that maybe a better idea
would be to push the envelope and the sate of the art first as standards
tend to be designed by committe and as such reflect the 'design by
- We ought to observe standards that deal with segments of packages so
as not to reinvent the wheel, only use standards that are worth using,
for example, 'accounting standards' as published by various standards
groups would need to be followed (particularly as accounting standards
vary from country to country).
- Overall, it was suggested to have the packages follow the KISS principle.
Topic #2 - The competition:
- There are a lot of freely available packages that deal with ERP
- It is suggested that we take the best parts of each and improve on
them - look at what works and what doesn't by example as the research
and development has already been done to some degree.
- Some examples of packages to to be looked at: SQL Ledger, GnuCash,
Topic #3 - Gnue related deails:
- A data dictionary or list of all tables, one does not exist yet
outside of the domain of knowledge of the principal programmers on each
- A common db format should be established as all modules will
eventually need to interact
- The modules should be kept small, without too many features.
- Security needs to be implemented. For example, most organizations
don't let the same person open Purchase Order and and Accounts Payable
module (they are usually separate jobs).
- Currency is one example of where featuritis/complexity tends to creep
in, however this is an issue that does not need to be addressed in the
- Some feature ideas:
---- gl ar and ap are all related, should ship together or be
---- payment reminders
---- good clients fore example may get the first second reminders, but
never threats of going to court, wheras bad clients would get the
---- suggestion for gl ap ar to be the core group, not separable as they
are dependent, but separately installed maybe (some need gl and ar, but
not ap for example)
Topic #4 - Eat your own dogfood:
- It is suggested that to improve thequality of the product, that we use
our own tools to manage the development of the ERP packages, the eat
your own dogfood principle
- The first suggested tool to be built is a project management and bug
tracking software such as DCL for internal use.
- UML is not discarded as a tool, but is looked upon as more of a burden
than a tool. Will be used selectively by developers as they deem necessary.
Topic #5 - Goals:
- It is suggested that we co-ordinate development on a much higher
level, then drill down into the details.
- As an example, the tried and true open source route is to try
something and learn from it, rather than approach it from a strictly
academic perspective. Build something now, something that works and
meets the groups (and potential clients) immediate needs.
- Our goals should not aim too highat first, don't aim for replacing
SAP, aim for smaller achievable goals
- It was noted that the SAP market is saturated, suggestion that small
business is still looking for ERP solutions they can afford
- The development cycle needs milestones clearly set - perhaps as part
of the implementation of our own project management software. As
refactoring is expected as par for the course, python was the perfect
choice for a development language to take care of that need and UML
would simply duplicate the effort.
Topic #6 - Current reality:
- Some developers wish to make a living with the releases, not aim for
pie in the sky projects.
- Gnue is ready for a serious push into the marketplace and deployment
into small business scenarios.
- Applications Server is ready for support contracts.
- As well there are 3 people working on packages currently: invoicing,
accounting and hr.
Topic #7 - To Do list:
- The packages that are immediately needed are: General Ledger, Account
Recievable, Account Payable, Human Resources.
- Packages that would be helpful are: Project Management and Bug
- As it pertains to the packages listed above, what should be built
first would depend on the teams needs initially, and further development
would be paid for by the client.
- Gnue-SB (Small Business) edition is suggested as the initial release
- Navigator needs some refactoring before it is ready for use by the
typical Small Business owner. Currently it is only suitable for developers.
- As Navigator and Forms will be the most used front ends, both need
- Currently there is no graphical User Interface for Reports - this
needs to be remedied.
- In terms of Reports, users need to be able to generate "spontaneous"
reports easily as they will have needs outside of the premade batch
reports. Currently Reports module does not have enough functionality to
satisfy this need.
- Navigator needs a lot of work to work in embedded scenarios. It only
supports wxWindows currently on embedded platforms.
- Navigator should let you launch more than 1 form, it should track open
forms as well.
- Navigator is lower on the TO DO list overall as it needs a lot of work.
- Higher on the priority list is to start creating packages and
fine-tuning the tools as we go along.
- It is suggested for Gnue-SB to have single directory per module for
Topic #8 - Tutorials
- The need for tutorials is obvious. Mentoring is suggested as a "teach
the teacher" method of expanding the userbase.
- Suggested to have 1 hour tutorials on:
---- tutorial on basics of accounts receivable
---- a tutorial on basics of accounts payable
---- a tutorial on basics of general ledger
---- a tutorial on basics of human resources
---- a tutorial on basics of ebXML
**** MEETING ENDED AT Mon Jul 26 15:41:15 2004
- Thanks again for all the great work you guys do, this is a little bit
of my contribution to the effort ( I hope to allocate more resources as
time goes on.)