Revision history for ExpectationsManagement
Additions:
|=|{{image alt="webERP logo" title="webERP Logo" url="images/webERPlogo.gif"}}|=|[[HomePage What Is webERP]] |=| [[WeberpFeatures webERP Features]] |=|[[WeberpFaq Documentation]]||
|=|[[WeberpSupport Support]] |=|[[http://www.weberp.org/forum Forum]] |=|{{image class="center" alt="Sourceforge Logo" title="Sourceforge Logo" url="http://sflogo.sourceforge.net/sflogo.php?group_id=70949&type=9" link="http://sourceforge.net/projects/web-erp"}} |=| [[http://sourceforge.net/project/platformdownload.php?group_id=70949&sel_platform=3757 Download]] |=| [[http://www.weberp.org/weberp/index.php Demo]] |=|[[WeberpDevelopment Development]]||
|=|[[WeberpSupport Support]] |=|[[http://www.weberp.org/forum Forum]] |=|{{image class="center" alt="Sourceforge Logo" title="Sourceforge Logo" url="http://sflogo.sourceforge.net/sflogo.php?group_id=70949&type=9" link="http://sourceforge.net/projects/web-erp"}} |=| [[http://sourceforge.net/project/platformdownload.php?group_id=70949&sel_platform=3757 Download]] |=| [[http://www.weberp.org/weberp/index.php Demo]] |=|[[WeberpDevelopment Development]]||
Deletions:
|=|[[WeberpSupport Support]] |=| [[http://sourceforge.net/projects/web-erp Sourceforge Project Page]] |=| [[http://sourceforge.net/project/platformdownload.php?group_id=70949&sel_platform=3757 Download]] |=| [[http://www.weberp.org/weberp/index.php Demo]]|=|[[WeberpDevelopment Development]]||
Additions:
|=|[[WeberpSupport Support]] |=| [[http://sourceforge.net/projects/web-erp Sourceforge Project Page]] |=| [[http://sourceforge.net/project/platformdownload.php?group_id=70949&sel_platform=3757 Download]] |=| [[http://www.weberp.org/weberp/index.php Demo]]|=|[[WeberpDevelopment Development]]||
As with most open source projects, help is provided voluntarily and on the clear understanding that the developers or project managers are //NOT// responsible for your installation. The software is offered and used without warranty etc as per the GPL version 2.
Many open source projects have a development road map which determines where the focus of the developers will be in future. However, webERP is now a mature system, offering a highly functional ERP system.
The road for webERP development has now opened up and 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 developers are keen to work with you to develop the systems you need.
All development 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. Also, code that duplicates existing functionality will not be included.
As with most open source projects, help is provided voluntarily and on the clear understanding that the developers or project managers are //NOT// responsible for your installation. The software is offered and used without warranty etc as per the GPL version 2.
Many open source projects have a development road map which determines where the focus of the developers will be in future. However, webERP is now a mature system, offering a highly functional ERP system.
The road for webERP development has now opened up and 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 developers are keen to work with you to develop the systems you need.
All development 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. Also, code that duplicates existing functionality will not be included.
Deletions:
As with most open source projects, help is provided voluntarily and on the clear understanding that they are //NOT// responsible for your installation and that the software is offered and used without warranty etc as per the GPL version 2.
~- 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.
Additions:
As with most open source projects, help is provided voluntarily and on the clear understanding that they are //NOT// responsible for your installation and that the software is offered and used without warranty etc as per the GPL version 2.
Deletions:
As with most open source developers, help is provided voluntarily and on the clear understanding that they are //NOT// responsible for your installation and that the software is offered and used without warranty etc as per the GPL version 2.
Additions:
webERP is administered by Phil Daintree.
As with most open source developers, help is provided voluntarily and on the clear understanding that they are //NOT// responsible for your installation and that the software is offered and used without warranty etc as per the GPL version 2.
As with most open source developers, help is provided voluntarily and on the clear understanding that they are //NOT// responsible for your installation and that the software is offered and used without warranty etc as per the GPL version 2.
Deletions:
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.
Deletions:
~-Web-Site Maintenance
~-Marketing - we do none currently!
~-Writing Documentation
~-Answering Support Queries
~-Testing and debugging
Additions:
webERP is administered by Phil Daintree. Whilst Phil was the original developer of the code back in 2003-2003, in the last few years Tim Schofield had been administering webERP. Unfortunately, [[TimSchofieldDisagreement disagreements over approach]] caused irreconcilable differences and Tim has moved on forking the codebase to Launchpad. Tim has conveniently named his fork webERP! and is at http://www.web-erp.org and http://sourceforge.net/projects/weberp
Deletions:
Additions:
webERP is administered by Phil Daintree. Whilst Phil was the original developer of the code back in 2003-2003, in the last few years Tim Schofield had been administering webERP. Unfortunately, [[TimSchofieldDisagreement disagreements over approach]] caused irreconcilable differences and Tim has moved on forking the codebase to Launchpad.
Deletions:
Additions:
webERP is administered by Phil Daintree. Whilst Phil was the original developer of the code back in 2003-2003, in the last few years Tim Schofield had been administering webERP. Unfortunately, [TimSchofieldDisagreement disagreements over approach] caused irreconcilable differences and Tim has moved on forking the codebase to Launchpad.
Help is needed particularly from those with skills in any of the following functions:
Help is needed particularly from those with skills in any of the following functions:
Deletions:
Additions:
~- 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.
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.
~-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!
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.
~-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!
Deletions:
~- It follows then that development work that does get undertaken and given back then is predominantly from those with more altruistic motives.
It follows from the above circumstances that a road-map for webERP development can take different roads depending on what developments businesses wish to sponsor. If you have a road-map for development you require and are prepared to sponsor - then please do let me know.
Work that is donated to the project I will include provided it does not compromise the [[ContributingtowebERP goals of the project and coding conventions]] - if it compromises the coding conventions I will make an honest attempt to convert it to be consistent 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. The argument against mixing presentation and logic is largely academic philosophy (in my view).
~-As eluded to above - business people predominantly (and understandably) only write code for their own business requirements.
Additions:
webERP is administered by Phil Daintree. Help is needed particularly from those with skills in any of the following functions:
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.
~- The aim is to maximise the benefits to businesses using the system.
~- 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)
~- It follows then that development work that does get undertaken and given back then is predominantly from those with more altruistic motives.
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.
It follows from the above circumstances that a road-map for webERP development can take different roads depending on what developments businesses wish to sponsor. If you have a road-map for development you require and are prepared to sponsor - then please do let me know.
~- 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. The argument against mixing presentation and logic is largely academic philosophy (in my view).
~- Additional layers of abstraction (eg smarty templates) are deliberately avoided in favour of readability. Computer scientists then feel alienated by webERP's coding structure.
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.
~- The aim is to maximise the benefits to businesses using the system.
~- 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)
~- It follows then that development work that does get undertaken and given back then is predominantly from those with more altruistic motives.
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.
It follows from the above circumstances that a road-map for webERP development can take different roads depending on what developments businesses wish to sponsor. If you have a road-map for development you require and are prepared to sponsor - then please do let me know.
~- 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. The argument against mixing presentation and logic is largely academic philosophy (in my view).
~- Additional layers of abstraction (eg smarty templates) are deliberately avoided in favour of readability. Computer scientists then feel alienated by webERP's coding structure.
Deletions:
Tim, as with most open source developers, gives his help voluntarily and on the clear understanding that we are //NOT// responsible for your installation and that the software is offered and used without warranty etc as per the GPL version 2.
//Note: This is a personal statement of Phil Daintree's and not necessarily the view of Tim Schofield the other project admin of webERP//
~- My aim is to maximise the benefits to businesses using the system.
~- Although I would like development work (done in accordance with the [[ContributingtowebERP coding conventions]]) given back to the project I understand and accept that there is not a legal requirement unless it is being redistributed.
~- I conclude that the development work that does get undertaken and given back then is predominantly from those with more altruistic motives.
I want to use webERP 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 my work is useful I want 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 my charging a reduced fee. This is a win-win, since :
~-I get to develop software which I enjoy doing (I am not allowed to spend too much time on webERP these days since I have a family and my wife expects there to be a return for the work I do!)
~-webERP gets the additional functionality and the value proposition increases for the whole community
~-The sponsoring business gets discounted development work
It follows from the above circumstances that I am not able to publish a road-map for my development because different roads get taken depending on what developments businesses wish to sponsor. If you have a road-map for development you require and are prepared to sponsor - then please do let me know. I am not sure how Tim's development agenda works.
~- 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. The argument against mixing presentation and logic is largely academic philosophy (in my view). Additional layers of abstraction (eg smarty templates) are deliberately avoided in favour of readability. Computer scientists then feel alienated by webERP's coding structure.
Additions:
webERP is administered by Tim Schofield. Help is needed particularly from those with skills in any of the following functions:
Tim, as with most open source developers, gives his help voluntarily and on the clear understanding that we are //NOT// responsible for your installation and that the software is offered and used without warranty etc as per the GPL version 2.
Tim, as with most open source developers, gives his help voluntarily and on the clear understanding that we are //NOT// responsible for your installation and that the software is offered and used without warranty etc as per the GPL version 2.
Deletions:
We, as with most open source developers, are both voluntary and offer our services on the clear understanding that we are //NOT// responsible for your installation and that the software is offered and used without warranty etc as per the GPL version 2.
Additions:
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.
Work that is donated to the project I will include provided it does not compromise the [[ContributingtowebERP goals of the project and coding conventions]] - if it compromises the coding conventions I will make an honest attempt to convert it to be consistent 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:
~-As eluded to above - business people predominantly (and understandably) only write code for their own business requirements.
~- 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.
Work that is donated to the project I will include provided it does not compromise the [[ContributingtowebERP goals of the project and coding conventions]] - if it compromises the coding conventions I will make an honest attempt to convert it to be consistent 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:
~-As eluded to above - business people predominantly (and understandably) only write code for their own business requirements.
~- 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.
Deletions:
Work that is donated to the project I will include provided it does not compromise the [[ContributingtowebERP goals of the project and coding conventions]] - if it compromises the coding conventions I will make an honest attempt to convert it to be consistent with the existing code base. In practise 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:
~-As eluded to above - business people predominantely (and understandably) only write code for their own business requirements.
~- Writing code with generic capability is more onerous that simple hacks to acheive 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.
Additions:
|=|{{image alt="webERP logo" title="webERP Logo" url="images/webERPlogo.gif"}}|=|[[HomePage What Is webERP]] |=| [[WeberpFeatures webERP Features]] |=|[[WeberpFaq FAQs]]|=|
Deletions:
Additions:
|=|{{image alt="webERP logo" title="webERP Logo" url="images/webERPlogo.gif"}}|=|[[HomePage What Is webERP]] |=| [[WeberpFeatures webERP Features]] |=|[[WeberpFaq FAQs]]||
|=|[[WeberpSupport Support]] |=| [[http://sourceforge.net/projects/web-erp Sourceforge Project Page]] |=| [[http://sourceforge.net/project/platformdownload.php?group_id=70949&sel_platform=3757 Download]] |=| [[http://www.weberp.org/weberp/index.php Demo]] |=|[[http://www.weberp.org/weberp/doc/Manual/ManualContents.php Manual]] |=|[[WeberpDevelopment Development]]||
|=|[[WeberpSupport Support]] |=| [[http://sourceforge.net/projects/web-erp Sourceforge Project Page]] |=| [[http://sourceforge.net/project/platformdownload.php?group_id=70949&sel_platform=3757 Download]] |=| [[http://www.weberp.org/weberp/index.php Demo]] |=|[[http://www.weberp.org/weberp/doc/Manual/ManualContents.php Manual]] |=|[[WeberpDevelopment Development]]||
Deletions:
Deletions:
Deletions:
There are a couple of forks of webERP and the reasons for the forks are a useful history lesson that teach us what to expect in the future:
1. Open-Accounting forked for a number of reasons - the main one at the time was that Sherif (Omar - the developer of OA) required right to left language (Arabic) and gettext which I was not ready to explore at the time. Also, one of webERP's primary goals has always been to have code readable by business people (of which I am one). I am not interested in programming niceties and avoid object orientation techniques (OO) because it is not intuitive (at least to me and I believe most business folk). That's not to say that OO will not be used where the code re-use argument is overwhelming - it is used quite extensively in transaction scripts. I suspect that Sherif, steeped in programming theory was not prepared to carry me along and put up with my whinging! Open Accounting has become Front Accounting and it is probably "better" than webERP in terms of programming niceties OO, functions everywhere, a maize of directories etc. However, webERP has left it behind in terms of functionality (I think this can be regarded as a fact) and certainly code readability (my opinion!).
2. edgeERP forked in 2007 because Steve was uncomfortable with my stance described above where I require a sponsor for development and this apparently is anti-open-source. This angered him to the point where he became very abusive in an email to me and I not wishing to have any more involvement with him, removed him as a developer as a consequence. I was also critical of the contribution of some purported developers of webERP - where development work they had done for clients on webERP had not been given back to the community (and I think may still not have been published). Whilst I accept this may not be a legal requirement it is certainly contrary to the spirit of open-source and definitely contrary to the reasons why I donated the code in the first place. Ultimately, actions (or lack of) speak much louder than all the words and promises. A lovely irony is that my requiring sponsorship for development only came about because I felt like I was carrying a team of consultants who were making money from my efforts - my wife felt I was a mug to carry on with it and this was the compromise (hey I enjoy it - at least when there are no nasty conflicts!) The lesson here is that people who are developers of webERP will only stay listed as such if they are actively contributing - and will not be allowed to stay listed indefinitely possibly for self promotional purposes - unless they are contributing code. We are much better off with less ego and more development work!
Additions:
====The Reasons For webERP Forks====
Additions:
There are a couple of forks of webERP and the reasons for the forks are a useful history lesson that teach us what to expect in the future:
1. Open-Accounting forked for a number of reasons - the main one at the time was that Sherif (Omar - the developer of OA) required right to left language (Arabic) and gettext which I was not ready to explore at the time. Also, one of webERP's primary goals has always been to have code readable by business people (of which I am one). I am not interested in programming niceties and avoid object orientation techniques (OO) because it is not intuitive (at least to me and I believe most business folk). That's not to say that OO will not be used where the code re-use argument is overwhelming - it is used quite extensively in transaction scripts. I suspect that Sherif, steeped in programming theory was not prepared to carry me along and put up with my whinging! Open Accounting has become Front Accounting and it is probably "better" than webERP in terms of programming niceties OO, functions everywhere, a maize of directories etc. However, webERP has left it behind in terms of functionality (I think this can be regarded as a fact) and certainly code readability (my opinion!).
2. edgeERP forked in 2007 because Steve was uncomfortable with my stance described above where I require a sponsor for development and this apparently is anti-open-source. This angered him to the point where he became very abusive in an email to me and I not wishing to have any more involvement with him, removed him as a developer as a consequence. I was also critical of the contribution of some purported developers of webERP - where development work they had done for clients on webERP had not been given back to the community (and I think may still not have been published). Whilst I accept this may not be a legal requirement it is certainly contrary to the spirit of open-source and definitely contrary to the reasons why I donated the code in the first place. Ultimately, actions (or lack of) speak much louder than all the words and promises. A lovely irony is that my requiring sponsorship for development only came about because I felt like I was carrying a team of consultants who were making money from my efforts - my wife felt I was a mug to carry on with it and this was the compromise (hey I enjoy it - at least when there are no nasty conflicts!) The lesson here is that people who are developers of webERP will only stay listed as such if they are actively contributing - and will not be allowed to stay listed indefinitely possibly for self promotional purposes - unless they are contributing code. We are much better off with less ego and more development work!
1. Open-Accounting forked for a number of reasons - the main one at the time was that Sherif (Omar - the developer of OA) required right to left language (Arabic) and gettext which I was not ready to explore at the time. Also, one of webERP's primary goals has always been to have code readable by business people (of which I am one). I am not interested in programming niceties and avoid object orientation techniques (OO) because it is not intuitive (at least to me and I believe most business folk). That's not to say that OO will not be used where the code re-use argument is overwhelming - it is used quite extensively in transaction scripts. I suspect that Sherif, steeped in programming theory was not prepared to carry me along and put up with my whinging! Open Accounting has become Front Accounting and it is probably "better" than webERP in terms of programming niceties OO, functions everywhere, a maize of directories etc. However, webERP has left it behind in terms of functionality (I think this can be regarded as a fact) and certainly code readability (my opinion!).
2. edgeERP forked in 2007 because Steve was uncomfortable with my stance described above where I require a sponsor for development and this apparently is anti-open-source. This angered him to the point where he became very abusive in an email to me and I not wishing to have any more involvement with him, removed him as a developer as a consequence. I was also critical of the contribution of some purported developers of webERP - where development work they had done for clients on webERP had not been given back to the community (and I think may still not have been published). Whilst I accept this may not be a legal requirement it is certainly contrary to the spirit of open-source and definitely contrary to the reasons why I donated the code in the first place. Ultimately, actions (or lack of) speak much louder than all the words and promises. A lovely irony is that my requiring sponsorship for development only came about because I felt like I was carrying a team of consultants who were making money from my efforts - my wife felt I was a mug to carry on with it and this was the compromise (hey I enjoy it - at least when there are no nasty conflicts!) The lesson here is that people who are developers of webERP will only stay listed as such if they are actively contributing - and will not be allowed to stay listed indefinitely possibly for self promotional purposes - unless they are contributing code. We are much better off with less ego and more development work!
Additions:
//Note: This is a personal statement of Phil Daintree's and not necessarily the view of Tim Schofield the other project admin of webERP//
Deletions:
Additions:
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 CVS 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.
Deletions:
Additions:
Work that is donated to the project I will include provided it does not compromise the [[ContributingtowebERP goals of the project and coding conventions]] - if it compromises the coding conventions I will make an honest attempt to convert it to be consistent with the existing code base. In practise 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. The argument against mixing presentation and logic is largely academic philosophy (in my view). 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 predominantely (and understandably) only write code for their own business requirements.
The "Road Map" for webERP is up to the reader then - in the words of MS "anywhere you want to go..." subject to the caveats above !
~- 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. The argument against mixing presentation and logic is largely academic philosophy (in my view). 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 predominantely (and understandably) only write code for their own business requirements.
The "Road Map" for webERP is up to the reader then - in the words of MS "anywhere you want to go..." subject to the caveats above !
Deletions:
~- I suspect the coding conventions used by webERP are not widely appreciated by computer scientists since logic is mixed with presentation - 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. The argument against mixing presentation and logic is largely academic philosophy (in my view). Additional layers of abstraction (eg smarty templates) are deliberately avoided in favour of readability.
The "Road Map" for webERP is up to the reader then - anywhere you want to go... subject to the caveats above !
Additions:
~- I suspect the coding conventions used by webERP are not widely appreciated by computer scientists since logic is mixed with presentation - 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. The argument against mixing presentation and logic is largely academic philosophy (in my view). Additional layers of abstraction (eg smarty templates) are deliberately avoided in favour of readability.
Deletions:
Additions:
Work that is donated to the project I will include provided it does not compromise the [[ContributingtowebERP goals of the project and coding conventions]] - if it compromises the coding conventions I will make an honest attempt to convert it to be consistent with the existing code base. In practise there are a number of reasons why code contributions to webERP have been limited:
~- The coding conventions used by webERP are not widely appreciated by computer scientists since "Object Oriented" (OO) coding concepts are not widely embraced where they do not enable significant code re-use - since they have a heavy penalty in code readability. Some OO code is evident in webERP - where it's advantages (code re-use) outweigh the disadvantages (readability). Cmputer scientists appreciate the unquestioned beauty of OO concepts more than business people in my experience. Computer scientists write most of the code though and business people like myself and Tim are relatively rare.
~- Writing code with generic capability is more onerous that simple hacks to acheive 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.
The "Road Map" for webERP is up to the reader then - anywhere you want to go... subject to the caveats above !
~- The coding conventions used by webERP are not widely appreciated by computer scientists since "Object Oriented" (OO) coding concepts are not widely embraced where they do not enable significant code re-use - since they have a heavy penalty in code readability. Some OO code is evident in webERP - where it's advantages (code re-use) outweigh the disadvantages (readability). Cmputer scientists appreciate the unquestioned beauty of OO concepts more than business people in my experience. Computer scientists write most of the code though and business people like myself and Tim are relatively rare.
~- Writing code with generic capability is more onerous that simple hacks to acheive 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.
The "Road Map" for webERP is up to the reader then - anywhere you want to go... subject to the caveats above !
Additions:
I want to use webERP 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 my work is useful I want 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 my charging a reduced fee. This is a win-win, since :
Deletions:
Additions:
|=|{{image alt="webERP logo" title="webERP Logo" url="images/webERPlogo.gif"}}|=|[[HomePage What Is webERP]] |=| [[WeberpFeatures webERP Features]] |=|[[WeberpFaq FAQs]]|=|[[WeberpSupport Support]] |=| [[http://sourceforge.net/projects/web-erp Sourceforge Project Page]] |=| [[http://sourceforge.net/project/platformdownload.php?group_id=70949&sel_platform=3757 Download]] |=| [[http://www.weberp.org/weberp/index.php Demo]] |=|[[http://www.weberp.org/weberp/doc/Manual/ManualContents.php Manual]] |=|[[WeberpDevelopment Development]]||
----
=====webERP Administration and Roadmaps=====
----
=====webERP Administration and Roadmaps=====
Deletions:
Additions:
~-Web-Site Maintenance
~-Marketing - we do none currently!
~-Writing Documentation
~-Answering Support Queries
~-Testing and debugging
~-Marketing - we do none currently!
~-Writing Documentation
~-Answering Support Queries
~-Testing and debugging
Deletions:
~*Marketing - we do none currently!
~*Writing Documentation
~*Answering Support Queries
~*Testing and debugging
Additions:
~-I get to develop software which I enjoy doing (I am not allowed to spend too much time on webERP these days since I have a family and my wife expects there to be a return for the work I do!)
~-webERP gets the additional functionality and the value proposition increases for the whole community
~-The sponsoring business gets discounted development work
~-webERP gets the additional functionality and the value proposition increases for the whole community
~-The sponsoring business gets discounted development work
Deletions:
~*webERP gets the additional functionality and the value proposition increases for the whole community
~*The sponsoring business gets discounted development work
Additions:
~- 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.
~- My 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 I would like development work (done in accordance with the [[ContributingtowebERP coding conventions]]) given back to the project I understand and accept that there is not a legal requirement unless it is being redistributed.
~- This is a shame since the following that webERP could gather if businesses were to truly get behind the spirit of the project and the additional functionality that would then accrue to their business is foregone by themselves and the rest of the webERP community. The community grows but slower than it would otherwise if there were more support for the philosophy of creating something much bigger than we could each develop on our own.
~- I conclude that the development work that does get undertaken and given back then is predominantly from those with more altruistic motives.
I want to use webERP to help businesses and develop useful software. Software that is useful has a value and businesses are prepared to pay for this work. To ensure that my work is useful I want 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 my charging a reduced fee. This is a win-win, since :
It follows from the above circumstances that I am not able to publish a road-map for my development because different roads get taken depending on what developments businesses wish to sponsor. If you have a road-map for development you require and are prepared to sponsor - then please do let me know. I am not sure how Tim's development agenda works.
~- My 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 I would like development work (done in accordance with the [[ContributingtowebERP coding conventions]]) given back to the project I understand and accept that there is not a legal requirement unless it is being redistributed.
~- This is a shame since the following that webERP could gather if businesses were to truly get behind the spirit of the project and the additional functionality that would then accrue to their business is foregone by themselves and the rest of the webERP community. The community grows but slower than it would otherwise if there were more support for the philosophy of creating something much bigger than we could each develop on our own.
~- I conclude that the development work that does get undertaken and given back then is predominantly from those with more altruistic motives.
I want to use webERP to help businesses and develop useful software. Software that is useful has a value and businesses are prepared to pay for this work. To ensure that my work is useful I want 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 my charging a reduced fee. This is a win-win, since :
It follows from the above circumstances that I am not able to publish a road-map for my development because different roads get taken depending on what developments businesses wish to sponsor. If you have a road-map for development you require and are prepared to sponsor - then please do let me know. I am not sure how Tim's development agenda works.
Deletions:
~>My 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 I would like development work (done in accordance with the [[ContributingtowebERP coding conventions]]) given back to the project I understand and accept that there is not a legal requirement unless it is being redistributed.
~>This is a shame since the following that webERP could gather if businesses were to truly get behind the spirit of the project and the additional functionality that would then accrue to their business is foregone by themselves and the rest of the webERP community. The community grows but slower than it would otherwise if there were more support for the philosophy of creating something much bigger than we could each develop on our own.
~>I conclude that the development work that does get undertaken and given back then is predominantly from those with more altruistic motives.
~>I now develop functionality that businesses are prepared to sponsor on the understanding that it goes into the project in return for my charging a reduced fee. This is a win-win, since :
I am not able to publish a road-map for my development because different roads get taken depending on what developments businesses wish to sponsor. If you have a road-map for development you require and are prepared to sponsor - then please do let me know. I am not sure how Tim's development agenda works.
Additions:
We, as with most open source developers, are both voluntary and offer our services on the clear understanding that we are //NOT// responsible for your installation and that the software is offered and used without warranty etc as per the GPL version 2.
Deletions:
Additions:
====Development Philosophy - Road Map====
//Note this is a personal statement of Phil Daintree's and not necessarily the view of Tim Schofield the other project admin of webERP//
~> 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.
~>My 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 I would like development work (done in accordance with the [[ContributingtowebERP coding conventions]]) given back to the project I understand and accept that there is not a legal requirement unless it is being redistributed.
~>This is a shame since the following that webERP could gather if businesses were to truly get behind the spirit of the project and the additional functionality that would then accrue to their business is foregone by themselves and the rest of the webERP community. The community grows but slower than it would otherwise if there were more support for the philosophy of creating something much bigger than we could each develop on our own.
~>I conclude that the development work that does get undertaken and given back then is predominantly from those with more altruistic motives.
~>I now develop functionality that businesses are prepared to sponsor on the understanding that it goes into the project in return for my charging a reduced fee. This is a win-win, since :
//Note this is a personal statement of Phil Daintree's and not necessarily the view of Tim Schofield the other project admin of webERP//
~> 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.
~>My 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 I would like development work (done in accordance with the [[ContributingtowebERP coding conventions]]) given back to the project I understand and accept that there is not a legal requirement unless it is being redistributed.
~>This is a shame since the following that webERP could gather if businesses were to truly get behind the spirit of the project and the additional functionality that would then accrue to their business is foregone by themselves and the rest of the webERP community. The community grows but slower than it would otherwise if there were more support for the philosophy of creating something much bigger than we could each develop on our own.
~>I conclude that the development work that does get undertaken and given back then is predominantly from those with more altruistic motives.
~>I now develop functionality that businesses are prepared to sponsor on the understanding that it goes into the project in return for my charging a reduced fee. This is a win-win, since :
Deletions:
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.
My 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 I would like development work (done in accordance with the [[ContributingtowebERP coding conventions]]) given back to the project I understand and accept that there is not a legal requirement unless it is being redistributed.
This is a shame since the following that webERP could gather if businesses were to truly get behind the spirit of the project and the additional functionality that would then accrue to their business is foregone by themselves and the rest of the webERP community. The community grows but slower than it would otherwise if there were more support for the philosophy of creating something much bigger than we could each develop on our own.
The development work that does get undertaken and given back then is predominantly from those with more altruistic motives.
I now develop functionality that businesses are prepared to sponsor on the understanding that it goes into the project in return for my charging a reduced fee. This is a win-win, since :
Additions:
====Phil's Development Philosophy - Road Map====
Although I would like development work (done in accordance with the [[ContributingtowebERP coding conventions]]) given back to the project I understand and accept that there is not a legal requirement unless it is being redistributed.
This is a shame since the following that webERP could gather if businesses were to truly get behind the spirit of the project and the additional functionality that would then accrue to their business is foregone by themselves and the rest of the webERP community. The community grows but slower than it would otherwise if there were more support for the philosophy of creating something much bigger than we could each develop on our own.
I am not able to publish a road-map for my development because different roads get taken depending on what developments businesses wish to sponsor. If you have a road-map for development you require and are prepared to sponsor - then please do let me know. I am not sure how Tim's development agenda works.
Although I would like development work (done in accordance with the [[ContributingtowebERP coding conventions]]) given back to the project I understand and accept that there is not a legal requirement unless it is being redistributed.
This is a shame since the following that webERP could gather if businesses were to truly get behind the spirit of the project and the additional functionality that would then accrue to their business is foregone by themselves and the rest of the webERP community. The community grows but slower than it would otherwise if there were more support for the philosophy of creating something much bigger than we could each develop on our own.
I am not able to publish a road-map for my development because different roads get taken depending on what developments businesses wish to sponsor. If you have a road-map for development you require and are prepared to sponsor - then please do let me know. I am not sure how Tim's development agenda works.
Deletions:
Although there is at least a moral obligation to give the development back I understand and accept that there is not a legal requirement unless it is being redistributed.
This is a shame since the following that webERP could gather if businesses were to truly get behind the spirit of the project and the additional functionality that would then accrue to their business is foregone by themselves and the rest of the webERP community. The community grows but slower than it would otherwise if there were more support for the philosophy of creating something much bigger than we could develop on our own.
I am not able to publish a road-map for my development because different roads get taken depending on what developments businesses wish to sponsor. I am not sure how Tim's development agenda works.
====Mailing List Etiquette====
There are all sorts of people involved with webERP and we embrace this diversity.
Polite and cordial exchanges with good humour get the best responses.
Please do not respond to an email if you are angry at what someone wrote. Email stays written long after you have calmed down and will embarrass you later.
Email can be a little impersonal and whilst the information published on the list is very public we do encourage the use of first names at least in list communications.
Commercial arrangements with other list members should be kept off list.
Advertising of services should be limited to web-site information at the end of emails.
Additions:
There are all sorts of people involved with webERP and we embrace this diversity.
Polite and cordial exchanges with good humour get the best responses.
Please do not respond to an email if you are angry at what someone wrote. Email stays written long after you have calmed down and will embarrass you later.
Commercial arrangements with other list members should be kept off list.
Advertising of services should be limited to web-site information at the end of emails.
Polite and cordial exchanges with good humour get the best responses.
Please do not respond to an email if you are angry at what someone wrote. Email stays written long after you have calmed down and will embarrass you later.
Commercial arrangements with other list members should be kept off list.
Advertising of services should be limited to web-site information at the end of emails.
Deletions:
Confrontation, vengeful, egotistical oneupmanship and diatribes about how good or bad you or anyone else do not belong in an email and certainly not on our lists - please do not respond if you are angry at what someone wrote. Email stays written long after you have calmed down and will embarrass you later.
Commercial arrangements with other list members should be kept off list. Advertising of services should be limited to web-site information at the end of emails.
Additions:
Confrontation, vengeful, egotistical oneupmanship and diatribes about how good or bad you or anyone else do not belong in an email and certainly not on our lists - please do not respond if you are angry at what someone wrote. Email stays written long after you have calmed down and will embarrass you later.
Deletions:
Additions:
~*Web-Site Maintenance
~*Marketing - we do none currently!
~*Writing Documentation
~*Answering Support Queries
~*Testing and debugging
~*I get to develop software which I enjoy doing (I am not allowed to spend too much time on webERP these days since I have a family and my wife expects there to be a return for the work I do!)
~*webERP gets the additional functionality and the value proposition increases for the whole community
~*The sponsoring business gets discounted development work
~*Marketing - we do none currently!
~*Writing Documentation
~*Answering Support Queries
~*Testing and debugging
~*I get to develop software which I enjoy doing (I am not allowed to spend too much time on webERP these days since I have a family and my wife expects there to be a return for the work I do!)
~*webERP gets the additional functionality and the value proposition increases for the whole community
~*The sponsoring business gets discounted development work
Deletions:
~>Marketing - we do none currently!
~>Writing Documentation
~>Answering Support Queries
~>Testing and debugging
~>I get to develop software which I enjoy doing (I am not allowed to spend too much time on webERP these days since I have a family and my wife expects there to be a return for the work I do!)
~>webERP gets the additional functionality and the value proposition increases for the whole community
~>The sponsoring business gets discounted development work
Additions:
~>Web-Site Maintenance
~>Marketing - we do none currently!
~>Writing Documentation
~>Answering Support Queries
~>Testing and debugging
~>I get to develop software which I enjoy doing (I am not allowed to spend too much time on webERP these days since I have a family and my wife expects there to be a return for the work I do!)
~>webERP gets the additional functionality and the value proposition increases for the whole community
~>The sponsoring business gets discounted development work
~>Marketing - we do none currently!
~>Writing Documentation
~>Answering Support Queries
~>Testing and debugging
~>I get to develop software which I enjoy doing (I am not allowed to spend too much time on webERP these days since I have a family and my wife expects there to be a return for the work I do!)
~>webERP gets the additional functionality and the value proposition increases for the whole community
~>The sponsoring business gets discounted development work
Deletions:
~Marketing - we do none currently!
~Writing Documentation
~Answering Support Queries
~Testing and debugging
~I get to develop software which I enjoy doing (I am not allowed to spend too much time on webERP these days since I have a family and my wife expects there to be a return for the work I do!)
~webERP gets the additional functionality and the value proposition increases for the whole community
~the business gets discounted development work
Additions:
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.
My 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 there is at least a moral obligation to give the development back I understand and accept that there is not a legal requirement unless it is being redistributed.
I am not able to publish a road-map for my development because different roads get taken depending on what developments businesses wish to sponsor. I am not sure how Tim's development agenda works.
My 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 there is at least a moral obligation to give the development back I understand and accept that there is not a legal requirement unless it is being redistributed.
I am not able to publish a road-map for my development because different roads get taken depending on what developments businesses wish to sponsor. I am not sure how Tim's development agenda works.
Deletions:
It is difficult to publish a road-map for my development because different roads get taken depending on what developments businesses wish to sponsor. I am not sure how Tim's development agenda works.
Additions:
====Phil's Development Philosophy====
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 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 there is at least a moral obligation to give the development back I understand and accept that there is not a legal requirement unless it is being redistributed.
This is a shame since the following that webERP could gather if businesses were to truly get behind the spirit of the project and the additional functionality that would then accrue to their business is foregone by themselves and the rest of the webERP community. The community grows but slower than it would otherwise if there were more support for the philosophy of creating something much bigger than we could develop on our own.
The development work that does get undertaken and given back then is predominantly from those with more altruistic motives.
I now develop functionality that businesses are prepared to sponsor on the understanding that it goes into the project in return for my charging a reduced fee. This is a win-win, since :
~I get to develop software which I enjoy doing (I am not allowed to spend too much time on webERP these days since I have a family and my wife expects there to be a return for the work I do!)
~webERP gets the additional functionality and the value proposition increases for the whole community
~the business gets discounted development work
It is difficult to publish a road-map for my development because different roads get taken depending on what developments businesses wish to sponsor. I am not sure how Tim's development agenda works.
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 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 there is at least a moral obligation to give the development back I understand and accept that there is not a legal requirement unless it is being redistributed.
This is a shame since the following that webERP could gather if businesses were to truly get behind the spirit of the project and the additional functionality that would then accrue to their business is foregone by themselves and the rest of the webERP community. The community grows but slower than it would otherwise if there were more support for the philosophy of creating something much bigger than we could develop on our own.
The development work that does get undertaken and given back then is predominantly from those with more altruistic motives.
I now develop functionality that businesses are prepared to sponsor on the understanding that it goes into the project in return for my charging a reduced fee. This is a win-win, since :
~I get to develop software which I enjoy doing (I am not allowed to spend too much time on webERP these days since I have a family and my wife expects there to be a return for the work I do!)
~webERP gets the additional functionality and the value proposition increases for the whole community
~the business gets discounted development work
It is difficult to publish a road-map for my development because different roads get taken depending on what developments businesses wish to sponsor. I am not sure how Tim's development agenda works.