Revision [1957]
This is an old revision of ExpectationsManagement made by PhilDaintree on 2011-01-01 02:11:18.
HomePage What Is webERP | WeberpFeatures webERP Features | WeberpFaq FAQs |
---|
WeberpSupport Support | Sourceforge Project Page | Download | Demo | Manual | WeberpDevelopment Development |
---|
webERP Administration and Roadmaps
webERP is administered by Phil Daintree. Help is needed particularly from those with skills in any of the following functions:
- Web-Site Maintenance
- Marketing - we do none currently!
- Writing Documentation
- Answering Support Queries
- Testing and debugging
Phil, as with most open source developers, gives his help voluntarily and on the clear understanding that he is NOT responsible for your installation and that the software is offered and used without warranty etc as per the GPL version 2.
Suggestions for improvement are certainly encouraged but most of all we welcome development work done in accordance with the ContributingtowebERP development guidelines against the latest SVN code. Bringing development work in that was made against older code is more difficult and if you wish to be in a position to use later versions of webERP with the new functionality made available with each release it pays to be pro-active in donating the development work you've done back to the project.
Development Philosophy - Road Map
- All those involved with webERP are involved for their own purposes be they altruistic or most likely for the commercial advantage afforded by the software.
- The aim is to maximise the benefits to businesses using the system.
- The advantage afforded is proportional to the functionality provided in the software and each of us has an interest in developing functionality specific to our own requirements.
- There is no doubt, some enterprises consider that donating that development back to the project reduces the commercial advantage they now enjoy, as their competitors will also have access to the functionality they developed.
- Although it is preferable to have development work (done in accordance with the ContributingtowebERP coding conventions) given back to the project it is understood that there is not a legal requirement (unless it is being redistributed - and the source is not published elsewhere)
- The more businesses that truly get behind the spirit of the project the additional functionality that would then accrue to all webERP adopters would be fantastic.
webERP's aim is to help businesses and to develop useful software. Obviously, software that is useful has a value and businesses are prepared to pay for this work. To ensure that future work is useful it is necessary to work with businesses with specific needs and for which they are prepared to pay for - on the understanding that it goes into the project in return for a reduced fee.
The road for webERP development can take a varied route depending on what functionality businesses wish to sponsor. If you have a road-map for development you require and are prepared to sponsor - then webERP is keen to work with you.
Work that is donated to the project will be included provided it does not compromise the ContributingtowebERP goals of the project and coding conventions - if it compromises the coding conventions then it may take some work to bring it inline with the existing code base. In practice there are a number of reasons why code contributions to webERP have been limited but are probably also the reasons why businesses seem to like the system:
- I suspect the coding conventions used by webERP are not widely appreciated by computer scientists since logic is mixed with presentation - a "no no" for the purist - my view is that the presentation code adds to the context of the logic and significantly improves the readability. A major goal of webERP is to have the scripts readable by business people. The ability to change the presentation (within limits) is still available through css and the theme structure.
- Additional layers of abstraction (eg smarty templates) are deliberately avoided in favour of readability. Computer scientists then feel alienated by webERP's coding structure.
- As eluded to above - business people predominantly (and understandably) only write code for their own business requirements and have no interest in helping other businesses naturally!
- Writing code with generic capability is more onerous that simple hacks to achieve a specific purpose. e.g. In a business environment where a page will always be presented in English for all users - it is not necessary to write the code encapsulated in the _(' ') function to allow it to be translated to other languages. It is hard to justify spending the extra time/investment to make the code generic and useful for the project. I am prepared to take some of this on - but if it amounts to a re-write then I am not so keen unless the functionality is a big advance - simple hacks are mostly just that.