On Sun, 2011-03-27 at 22:01 +1100, chris moloney wrote:
> Well, I'm not able to make much of a technical contribution here,
> nevertheless I appreciate your interest and commitment in what is a
> very worthwhile project. I would be willing to support these efforts
> by road testing documentation as it is produced.
My aim is to make it extremely easy for people to edit the user and
administrative type documentation. The developer documentation is
already fairly complete, it just suffers from a few indexing issues on
the site (but those are no real barrier to developer types who are going
to browse the source files and accompanying text anyway -- some of the
prose explanations of how the main module code works is excellent). As I
get going on this I will definitely need feedback (and proofreading),
particularly if we decide to write English first for more exposure (very
likely at this point).
> To enlarge on my earlier comments, the naive user just expects the
> system will work. He (or she) assumes when an item is posted it will
> turn up in exactly the right places correctly coded across the system
> and all the appropriate reconciliations will occur seamlessly. I
> assume Tryton achieves this. However, despite days of effort, we have
> been unable to prove it because we have been unable to perform
> fundamental procedures. Let me define my terms properly. By
> "fundamental procedures" I mean such procedures as:
> 1) Setting up a chart of accounts
> 2) Setting up an assets register
> 3) Configuring an inventory system to fit our different kinds of stock
> 4) Creating client files
> 5) Setting up to produce purchase orders.
> etc.
>
> These tasks are not normally performed by rocket scientists so we need
> some very simple ABCs. Similarly accounting routines like "End of
> Month" reporting, "End of Year" reporting need to be quite
> straightforward to produce.
>
> I have no doubt these capabilities all exist in Tryton or that they
> work perfectly, but how do we do prove it? What screens should we have
> open? What permissions do we have to create and where do we do that?
>
> These are examples of the real world obstacles we have not been able
> to go around, despite several days of evaluation efforts.
>
> I hope these comments help.
> Regards
> Christy
I am completely sympathetic to this sort of sentiment; they, and the
issues I cited about marketing problems, are the exact same concerns we
have. While it is not so difficult for us to privately become well
versed in the system ourselves and start supporting clients, that would
not be much benefit to the community and would essentially mean that
someone else somewhere would have to duplicate the work we will have to
do ourselves in any case. This would hamper community growth and in the
end shoot everyone in the foot -- a stupid move for anyone involved in
open source.
As far as the tasks you cited above, our initial efforts were guided by
our previous experience evaluating OpenERP which functions much the same
way and suffers from some of the same documentation shortfalls. OpenERP
does have user and administrator level documentation, it is just poorly
written and structured in a somewhat confusing way (and was obviously
not written by native English speakers, a point that made for confusing
reading in a few places). Tryton does things a different way (a bit more
natural in some cases), but OpenERP was similar enough that the
experience generally translated well.
Anyway, OpenERP failed for two fundamental reasons:
1. It does not offer significantly better or more expansive
functionality than other freely available ERP systems but
entails a much higher overhead (the community is much more
closed and closeted off than initially seems)
2. The licensing terms are absolutely unacceptable to any serious
open source effort (and the aims of the company are highly
questionable)
Tryton offers very similar functionality, but lacks a few good starting
places for non-systems people to latch on to at the outset. It also
seems much easier to add new modules to, something we are not at all
afraid to try doing (it will be interesting to see us flounder at first
considering our currently poor SQL Fu, though). OpenERP adheres to some
pretty arcane coding principles, and the code base is not very uniform.
This is a major concern for an enterprise system that might be fielded
and maintained for many years through many layers of continuing
customization.
I have some infrastructure work to do to create an editing forum with a
very low barrier to entry for newcomers. Ultimately it makes the most
sense to run that over at b2ck, but there are a few details to iron out
first. I might just take the plunge first and temporarily host a small
wiki/Publican site myself (imitating the way we write manuals at Fedora)
until b2ck is ready (and has the time) to incorporate it more formally.
Whichever way is the fastest to get a prototype up and moving is the way
I will probably proceed.
More to follow.
-Iwao
--
[email protected] mailing list
