Re: LedgerSMB companion projects (was: Light manufacturing modules....)

["Chris Travers" <..hidden..>]

On 1/29/07, William Hamilton <..hidden..> wrote:
> Chris Travers wrote:
> <SNIP>
> > This certainly has come up in the past.  I am not sure we have a
> > complete idea of how this is going to work yet.  I think we want to
> > get more of our own infrastructure developed and tested before opening
> > it up to other sub-projects, however.  I suspect that the next step
> > will probably to move the public email lists onto our own servers.
> I do not see the benefits of moving list in this manner, it creates a
> reliance on certain members of the core team.  If this is to continue to
> be a fully open development project these types of reliances should be
> at a minimum.  Google groups or the current sourceforge lists (I now SF
> has some issues) should be sufficient.

This discussion started after the Gmail/Sourceforge issues a while
back.  It has been a low priority.  But one advantage to moving it
in-house would be more control over mailman configuration, etc.
Right now, infrastructure development is taking much higher priority
over infrastructure expansion (look at how long it took us to install
Drupal).

We already have the core list on our own servers but that isnt the
same thing as manageing the other three lists....
> > And we need to get our community CMS better developed.  And we still
> > don't have a public demo up yet.
> Do you just mean more content or a new CMS?

Making sure it meets peoples' needs, more content, moving away from
the Drupal theme, etc.

> If the APIs etc are defined well enough then external products can be
> developed discretely.  For an example check out a CMS I do a lot of work
> with http://plone.org/products/ hundreds of products developed
> independant of core.  I would prefer a closer build relationship with
> developers rather than creating the wheel each time but reliance on the
> core developers means less core product development?

Agreed.  Eventually, I would like to see a documented (and fairly
stable) API existing in the following areas:

1)  Physical storage (for custom triggers)
2)  Model Access (stored proceedures)
3)  Perl modules
4)  Web services

At least a couple areas of the software (customer/contact management)
will feature these things in 1.3, but they may not be completely
stable for another release or two.

> Could we look at introducing teams to work on certain aspects.  At the
> moment I see us relying on the core team for technical development,
> system maintenance (offerings such as http://code.google.com/ could
> offload some of this burden), direction and vision, training support..
> all the stuff a project like this needs.

If I may say so, I think the purpose of the core team is to direct
core infrastructure and make final decisions about direction and
vision.  While it is important in these areas to see what the
community thinks is necessary, this is sort of the role that the team
has.

However, I do agree that we are too core-centric at the moment.  This
is largely because there isn't a huge degree of community assistance
in most of these areas at the moment.  I have been trying to encourage
two things in this regard:

1)  Community-maintained infrastructure (i.e. unofficial wikis,
documentation, companion projects, how-to's and the like hosted
outside the core infrastructure) and
2)  Community involvement in technical work.  Note that most, though
not all, of the patches supplied by the community have been accepted.

These areas not only create a larger, more viable community which is
less dependant on Core, but also make that community more visible,
which is good for everyone.
> Is it a viable option to break out into key areas such as marking,
> technical, infrastructure, documentation etc.  There will be overlaps in
> resources but this could allow a buinessperson with a marketing
> background, or an accounts person who likes to write documentation a
> great opportunity to get involved.

If anyone wants to get involved *in any way* please let us know how
you want to help.  We are here to help you get involved!
> Just my 2c worth.
>
> Just to add, I have not yet migrated over to LSMB but willing to provide
> assistance where I can.  I am not a Perl developer but have fiddled with
> LaTeX templates and can write good england sometimes.  Happy to work
> with technical people and translate into normal speak.
If you are interested in getting involved in the documentation, have
you looked through our manual?  If you are interested in helping out,
that might be a good place given what you say.  Currently, it is still
mostly applicable to SQL-Ledger too :-)

Best Wishes,
Chris Travers