While answering some questions from Imparo, I also made a call to the community with a few suggestions for how the community members can get more involved (https://sourceforge.net/forum/message.php?msg_id=4211497). I wanted to create this thread to help keep us organized and keep all of the suggestions together in one new, clean thread.
As a background, Compiere has been working closely with EnterpriseDB (based on PostgreSQL) to provide an open source alternative to Oracle. Right now this work is at an alpha stage, but we would like to get additional people testing it in April. This is in addition to our continued support of Oracle allowing our customers and users to select from multiple databases.
With our new CEO just coming into the company, we are reprioritizing our new product features, but right now our focus is on fixing some bugs. New features / improvements will start with the UI / HTML UI, and we will share additional plans when we have decided exactly where to focus next.
The best way the community can get involved now is by doing these 3 things:
1) use this thread to suggest where you would most like to see Compiere focus on new product features and improvements.
2) make sure that any bug you find in Compiere gets submitted.
3) get ready to do some testing with EnterpriseDB in April.
As your community liaison within Compiere, my plan is to collect the community suggestions and use them as part of our prioritization efforts.
Here they are my two cents:
1) Compiere Localization
I feel this is a very important issue that hasn't been duly attended and the Community could be of great help, as for instance I have seen other OS projects such as OpenBravo that are already taking good initiatives towards accomplishing this, http://wiki.openbravo.com/wiki/index.php/How_To_Localize
Let me further point out that this shouldn't involve just language translations but also good language localization as it is the case with Spanish Language Pack, I'm sure the terminology looks good for argentinans but for mexicans it looks awkward.
Also things like date/numeric format and accounting/tax issues, I am sure every country has its very own requirements and Compiere should take these into consideration and prioritize them, I am sure the community can play a big role here too because if Compiere,Inc hasn't enough time/resources to provide these fixes, then we could all help determine the requirements and maybe look for some sponsors, then when the development/effort cost/time is covered, Compiere,Inc or its Community e.g. can perform these fixes.
2) Compiere Manufacturing
I undertand an ERP is like the brains of the organization, so for a company to take on this type of investment, the solution better be good! Once I had a light manufacturing company as a customer and they dropped Compiere a little after I had a conversation with the owner where he told me "but the system doesn't tell me how much raw materials and which ones I need to buy to fulfill my customer's orders", then I had to tell him he had to figure that out manually and he was really disappointed after that.
I know there is a Plan from Compiere to provide this long awaited functionality, and I know some people from the community were working on that at least about 2 years ago, they even anounced that it would be available in 2005 or so. I don't know what happened afterwards, but this is still an open issue and a strong one. I propose this issue should be 'reopened' and that a roadmap is presented and reviewed by the community.
Hope anyone else may further elaborate on these issues.
I fully agree with Enrique on both issues. Especially Manufacturing is a crucial piece of functionality that should not really be supported by extensions or plug-ins from partners or others but rather it should be supported in Compiere core code - at least the cross-industry part of manufacturing functionality. I know that there is some production-related features currently but to me it seems like most often partners build significant additional manufacturing functionality as an extension since there is a lot of unmet production-related requirements in the existing core functionality. Rather than having partners add the manufacturing functionality, I think the cross-industry manufacturing functionality should be in the core Compiere code and partners should provide additional vertical industry-specific functionality as extensions.
I'd like to think as well that manufacturing-support needs to be base-line. On top of things, extentions are great! I'm for example pretty charmed with the ease with which one can apply extentions to SugarCRM. I haven't taken Compiere's technical training yet :-( but i've got the feeling that there's no real infrastructure in the product to support easy integration of extentions. If i'm right, that would be one of the first things to take care of. Once that's in place and Compiere provides a new community environment away from Sourceforge, we hopefully get the sparks back in the community. Working with extentions also takes care of possible IP-issues that have been raised previously as a barrier to contribute code.
Thank you very much for starting this discussion - you have paved a positive way for providing input.
It is great that Compiere are now looking at EnterpriseDB .. I knocked on EnterpriseDB's door mid last last year asking if they were looking at providing support for Compiere. At that stage EnterpriseDB weren't ready so it is heartening to see the two organisations cooperating for a common benefit.
The main reason I began looking for an Open Source ERP solution was based around previous dealings with other ERP vendors and the amount of lock-in customers experience, effectively giving the customer little leverage in the relationship.
I have a vision for our organisation which involves integrating a number of data sources into our ERP system - call centre phone call details, call centre agent scripting, and delivery logistics information. This is a system with end-to-end visibility of our interaction with our customers. As far as I am aware this has not been achieved by any vendor ERP system. I want to take Compiere and sponsor this additional functionality into the system. I have no interest in privately owning such functionality as I see more benefit in others having it's use and perhaps enhancing it even further than I can imagine .. that's the power of Open Source. It's also our way of saying thank you to others who have gone before us and created the underlying system.
As I researched Compiere more I became aware of some disquiet around how bugs and enhancements were treated and what appeared to be an unusually slow rate of progress for an open source application. I certainly can't claim to fully understand the root cause of all the disquiet and at this stage I have my suspicions but I do have some suggestions for what I am looking for in an open source project.
The following would be licenced under open source:
- All the system itself
- All underlying infrastructure & testing tools;
- Version Migration Tools (no vendor lock-in please)
- Library of Module add-in sub-projects (usually partner/community contributed)
- Module Add-in Tools
- Documentation materials (no vendor lock-in please)
The following should be available:
- Public Roadmap on display
- Training & Training Materials
- Release Structure – Development & Supported Release pattern (release early, release often)
The following people should be adding code & documentation:
- Individuals contributing
- Customers contributing
- Commercial organisations contributing
Public patch posting policy – with reasons for inclusion/rejection
Open Forums – Customer nomination and voting for new functionality (Partners, Contributors and Customers with support can vote). Ability for Partners, Contributors & Customers to financially sponsor new functionality (supply code or whole/part funding) to bump up priority.
Compiere Partners – Priority Access to support; Local User Group coordination, local Seminar and Conference coordinator; Partners are paid for approved functionality enhancements where Customer provides sponsorship.
Compiere Support – priority response for customers with paid support - complete with SLA's (assistance & bug fixes); paid rewards for contributor if solution & documentation publicly supplied (and acknowledged as adding value) for a paid support customer.
Seminars – Web seminars open to all
Functionality Suggestions (my current priority order)– Return Material Authorisations; Pentaho Integration; Human Resources (non-payroll); Forecasting; Payroll;
My request is that the effort to add DB2 support to the migration utility be started as soon as the next training starts this May. I understand the priority of EnterpriseDB/PostgreSQL, however DB2 support in Compiere is paused at Alpha level and needs to be continued to reach Beta and eventually Production. And "DB2 support in the migration utility" is crucial to take it beyond the current Alpha level.
1. Provide official training (class room training)in Asia.
2. Ease of applying 3rd party add-on/extensions.
3. Online training material for distance learning.
4. Online pre-sales material / webcasts. (more to target business ordinance)
5. Publish Solid and Real reference sites. Success stories with customer C level endorsements.
6. Get real implementers (people with hands-on experience in implementing Compiere) to support your support sites.
Looking forward to help you test EnterpriseDB
Hi Dawn, my last post here was Nov-17/2006, since Yves considered cross-posting our participation here, and you know that most of the time we're just treated as screamers :-))))
But anyway, just for the record, I'm attending your invitation in Compiere blog:
"We certainly hope that customers and other users of Compiere (including those currently participating in Adempiere) will choose to work closely with Compiere by participating in our community."
Hopefully with the opening of this thread to discuss Compiere Direction you could be near to community, but take care this can be easily another unattended wishlist if you don't keep the communication open. Past experiences have shown that periodically you (as company) opened some threads and then left them unattended without advance info, etc.
My 0,02 cents can be divided in two areas, technical suggestions and community directions. (Just for clarity I'll divide this post)
0,01 - COMMUNITY DIRECTIONS
This is really easy, Dawn, you just need to read history, specially the fork discussion here:
Lots of things discussed by community there, and very few things have changed since Sep-1/2006
I'll try to give you the summary, but is better if you read the whole discussion and feel by yourself the community feelings.
1. Promote and support a community friendly environment
2. Use community feedback for enhancing and improving the product
3. Leverage community resources for development and testing
4. Mantain open and clear communications with the community
5. If a business model is developed, establish rules that are fair for both the community and the business
Partners have never determine the direction of the product. Even if this ever happens it will be very far from being the bazaar we foresaw in this project when we originally joined.
If Compiere ERP-CRM is going to be open source then we need to have access to source code. And we need to be able to submit fixes.
Just that in ADEMPIERE we give out CVS rights as merited and regulate the dynamic versioning and support.
We also resolve the issue of not been held back for selective release of the core to give commercial advantage to paid partners vs bugs resolved by the community that must be released immediately back to the world.
afalcone pointed from "The Cathedral and the Bazaar":
6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
7. Release early. Release often. And listen to your customers.
1 - my major problem with Compiere is that they can't integrate localizations neither customizations.
2 - Compiere has all those business rules inside the code
3 - I like the Callout, the ModelValidationEngine, etc. But this can and must be extended a lot
4 - i.e. documents doesn't have that flexibility
5 - All technical improvements asked and mentioned repeatedly
- acceptance and publishing of contributions of community and partners
- bug fixing (and acceptance of bug fixing of community and partners)
- stable releases
- REALLY OPEN CODE (not private unstable releases)
- not partners as guinea pigs when community can test better
Also other aspects I raised in forums:
3 - Are you going to keep the CVS private repository?
4 - If yes, are you going to keep both repositories synchronized?
5 - If not, how much dealy must we expect to see changes on public repository?
(actual synch was delayed 5 months)
6 - Are you going to accept and integrate external contributions, probably from Compiere forks?
7 - Are you planning to share some control on the roadmap, or keep it centralized?
8 - Are you planning to share some control on the policy for accepting contributions, or keep it centralized?
Remember that is not only a matter of being open source. I think that community is very tired with the management and addressing of the whole project. PERSONALLY I think that some rapprochements can happen if JJ decentralize direction of the project.
I must ask, why to sign a contributor agreement translating all IP and rights to Compiere if project is GPL?
Why reinvent the wheel with every technical approach (POS, database independence, reporting tools)?
Why valuable contributions are simply ignored or even fighted (postgres port, manufacturing, fixed assets, migration tools, documentation projects, deploying tools)?
This reading too http://www.dwheeler.com/oss_fs_why.html#forking
<-- snippet -->
... common reasons (to fork) given include:
* a belief that changes are not being accepted fast enough,
* that the project governance is too closed to outsiders,
* that the licensing approach is hampering development,
* or that the project’s technical direction is fundamentally incorrect.
<-- end of snippet -->
OPEN QUESTIONS FOR COMPIERE INC.
When are you solving all those issues?
When are you going to publicly state how are you going to solve all those issues?
Or maybe is better to ask:
Are you really interested on solving those issues?
Do you have a different business model in mind? Maybe just you see community as partners-paying, but non-paying are invisible for you?
COMPLETELY PERSONAL CRITICISM FOLLOW:
1 - SVN migration outside of sourceforge looks like the way to keep the sources out of reach from non-paying community (and possibly from paying-customers).
What's the meaning of maintaining two repositories
a - public repository synched from time to time and the sync schedule determined by the Inc according to their commercial needs?
b - private repository just for partners signing an NDA?
I'm wondering if customers paying for Compiere are contracting a "GPL project+priority support", or they are really signing a "GPL project+proprietary patches"?
How can you call this GPL? proprietary patches are not allowed in GPL, possibly proprietary extensions, but not bug fixing.
I know this can be your company secret - but I really like to see the EULA that partners and customers are paying for. Is this really GPL? Is this a support contract? Are you prohibiting the disclosure of code (just like Shared Source initiative from Microsoft), that can be poisonous.
I ask all of this because I'm just wondering if I would like to contribute in a non-GPL project, or a project that will put aside all my contributions that put in risk their "business plans".
2 - Honestly I have always seen Compiere Inc is worried by the existance of a non-paying community.
I've never seen movements to help the non-paying community, in fact, I have seen lots of movements to obstruct the community.
I feel that you (as company) looks community support in forums against your business plan, maybe because you think that a good unpaid support on forums (or IRC) is against pushing people to sign support contracts.
And I feel that you (as company) try to obstruct every contribution related to migration tools, documentation projects, database independence,
IMHO, this is a very short sight vision. We (at Adempiere) are not seeing the possibility of having 100 paying customers.
We're really seeing this product can be the killer-app on ERP area. Do you know what does it mean?
Do you know what's the meaning of having a little slice of a big pie, against having a big slice of a little pie? (Thanks Redhuan for teaching me that ;-)
MY PERSONAL WISHLIST:
I would like to see Compiere Inc. having strategies for:
- partners (must be called paying community? customers of Compiere Inc?)
- users (customers of partners?)
- non-paying community
And I would like to see strategies to encourage and highlight contributors
I would like to see:
- Dawn Foster as "Director of Compiere Partner Community"
- Redhuan Daniel Oon as "Director of External community" with complete voice and vote in the directions of the Inc.
- A member of Adempiere community with voice and vote in the roadmap and contribution acceptance policy
(this is very personal, completely un-consulted with Adempiere council and/or Leader)
I would like to see a Compiere Inc growing leveraged by a vibrant community, and Compiere Inc RESPECTING such community.
Really I think technical problems are not difficult to solve. But the approach way is very difficult if you don't correct at least some of the issues raised by community.
This is not a matter of just saying "we're open source and have a community", it's about of really being open source and really having a community.
to be really open source:
- to have only one public repository
- give commit access to key developers in community
- give public access to trackers via mail-list
- keep communication with community, with daily communication, not a post every 3 months
to really have a community
- RESPECT the community
- and all points that rvergara raised in fork discussion (copied above)
Hi again, second part of my looooooooooooong post:
0,01 - TECHNICAL SUGGESTIONS
1 - Short term - Stable support a real open source database (postgresql)
2 - Open Wiki (really open, even if wiki grows against paid manual)
3 - open for extensions
3a - not changing core classes every version release
3b - allowing ModelValidator events for every before/after event on tables and documents
3c - allowing a tool to easy integrate external packages
3d - allowing a free tool to sync development, testing and production environments (like 2pack)
4 - Why to reinvent the wheel?
4a - itext integration for pdf generation
4b - JasperReports integration
4c - jfreechart (for dashboard graphics)
4d - functional POS
4e - ZK (Ajax client)
4f - Change the database independence approach, Convert layer is not the best approach, there are proven architectures to achieve this in a better way
5 - Complete flexibility
5a - Rule Engine for Accounting
5b - Rule Engine for Taxes
5c - Rule Engine for status on documents (I mean, completeIt must be modularized and allow reuse on workflows of new user-definable documents)
6 - Visibility
6a - open repository
6b - key committers with commit permissions
6c - open mail list for commits
Allow me to say that in Adempiere:
- 1, 2, 3a, 3b, 3c, 3d, 4a, 4b, 4c and 4d are ready
- 4e is in POC status
- 4f and 5b are being studied
- 6a, 6b and 6c (do you need comments on the openness of Adempiere?)
I'm pretty confident that most of the Adempiere community is eager to contribute all those developments back to Compiere if some of the points raised in my previous post are solved.
And anyway, all the Adempiere code is completely GPL, so you can take it and integrate it back into Compiere without problems.
Just for the record, let me explain the 1st point:
1 - Why Compiere Inc state that is going to support an open source database, when EDB is not open source?
Enterprise DB Advanced Server is as open source as oracle-XE :-)
EDB is free as oracle-XE within certain limits, that is not open source
In other words : Postgres is open source, EDB is not
Googling EDB License I found:
What are the proprietary components of EnterpriseDB?
Astor: EnterpriseDB is a commercial open source product which means that the extensions that we've done – the Oracle compatibility for example – is code that we share with customers who subscribe to our service but it is not under the BSD or the GPL license. It's an EnterpriseDB license. They can do anything they want [to the code], they just can't redistribute it.
Q. What open source license(s) do you use?
A. The PostgreSQL database is BSD licensed. EnterpriseDB uses a traditional license.
Thinking about features, i started to recall the ones that i've entered under the feature-requests. I've noticed that lot's of them only have the default priority of 5. Have you given those a thought yet? I guess we need to re-prioritise them and clean out the list a bit. Maybe you can establish a priority-definition which we can use to review the ones that we've entered.
Open Mind Consultancy BV
First of all, please take this as suggestion rather than someone who is venting anger.
On Direction, Wish List
1. Compiere really need to seriously look into the issues of remote deployment. While in some countries there maybe abundance of bandwidth, this is not the case with majority of the countries. Currently the only way to do this is via terminal services like NX, WTS or Citrix, this is still rather slow especially that broadband service in many places are really like yoyoband with bandwidth and round trip delay fluctuate throughout the day, roundtrip delay can goes from the normal 30ms to 900ms. I wouldn't even go into remote sites like in some places in Australia that are using vsat. Direct jdbc is not really possible for most cases. That pretty much leave the web interface, this is however, a feature in perpetual beta that never seems to work properly after so many years. When I first look into compiere,I was in awe by the replication features of compiere that was taunted on one of the slide, only to find out that this too is on perpetual beta and don
't even work. I seriously think compiere should look into this problem and fix it or even look into availability of test based client like what GNU Enterprise (text form client) has done.
2. Compiere seems to be moving rapidly on the technology in the whole application stake, I feel that this is really the wrong stuff to focus on. There are so many outstanding bugs and features that has not been fix or added... a short list of some examples
a) When you reverse a document currently, it doesn't reverse the attribute correctly.
b) when do material receipts without an attribute, it just gives a - entry in attribute set instance table, if you have many of this it pretty much become unmanageable.
These are just some examples that ought to be focus on and fix to make the application more useable instead of chasing for the latest version of jboss compatibility etc...
3. Decide if you really want to focus on ERP or CRM, I really think that you can't be both, compeire CRM can't really be called CRM at this stage.
4. Some of the skin entry is really awkward, you need to switch from screen to screen to get data.
5. There are plenty of security issues in the currently form. I am not talking about the hard security that make the os vulnerable but rather information that suppose to be locked can be access if someone know where to look. such as purchase price can be view by just about anyone, business partner info screen that allows people to view all customers and suppliers, zoom across that don't enforce security.
6. overhaul the framework to make it easily modifiable and provide add-on module possibility like the way tinyERP does it.
I paid for compiere support, not that I really need it but, because I believe and think compeire inc is doing a good job with creating and maintaining the program, I convince management to pay for it. Even though it is not a large sum, the few time I do try out the support and by browsing through the support form you can see a few things
1)most of the answer are short and cryptic that don't really answer the question.
2) say that a problem is fixed in the nightly build (when sometimes it is not), no one deploy such a sensitive application in production on nightly build, the amount of customization to reinplement and retest would take months.
3)Compiere need to make money from somewhere, and I think many people would be happy to pay if the support contract is actually useful, otherwise, you will find that people don't renew their support contract.
4) investigate ways to lower down support contract cost. 1500USD is not a lot of money in some countries but it can be quite a lot form some developing countries... look into farming out the support to some partners, certified them and since their cost are much lower. Even Novell and MSFT has local pricing for their products, and this is the same thing with SAP B1.
1) come out with a more comprehensive partner certification and support program to allow the userbase to grow. Revamp the pricing strategy for some countries.
To be very honest with you, this was a features that I look forward to when I first look into compiere, but are not so sure about this or the way ComPiere Inc is planning to do it. Nevertheless, I strong urge caution on this one. First of all, like someone said it, the that it is done currently deserve a second look. Secondly, looking at past history with Sybase and PostgreSQL, you must forgive me for being skeptical... support for Sybase only exsit for 1 release and was quietly dropped later. The donation drive for postgresql porting went no where. Seriously, if db independence is someone need to be done at least serious about it and keep it constant and predictable. immagine that someone who had purchase Sybase licenses and later found out it was dropped a few release later. Otherwise just focus on one or two database instead of multiple database.
Porting to EnterpriseDB is also rather questionable. Even it is based on postgres, it is still not postgres. Although it does provide a lower cost alternatives to Oracle but you must admit it is still cost and the difference to Oracle Standard Edition One is not much if you have say only 10-15 users. In the mean time, DB2 Express-C allow for up to 2 processor and 4 gig of memory for free.
Compiere is database intensive, even if you are using it for a small companies, immagine a small hardware distribution companies has 7000 products with 5000 BPartners, multiple BOM,multiple attribute and bom explode...even with just 10-15 users, it is going to eat up significant processing power and slows things down even on Oracle. In fact, I am willing to bet that without proper tuning on Oracle, it will be very slow. While on postgres, anything after 3 joints slow things down significantly even with indexing, and proper tuning. In compiere, on some operation with attributes, it involved up to 5 joins per query. My point is, if this is something that compiere wants to do it, better do it well rather than a half-hearted effort for database independance. That may means overhaul the approach to db independance. Otherwise, it is going to be just another nice to have features on paper only.
I just hope this attempt won't become like Dell's IdeaStorm, which was bound to fail if all this is for fake publicity or just to pretend you care and deep in your heart you have some hidden agenda!! On ideastrom the highest no of requests are for pre-installed linux and so far we haven't heard anything from Dell!! M$$$$$!!
Hmm... Dell does offer Linux:
That was not point... read on idea storm (Offer the 3 top free Linux versions for free pre-installation on all Dell PCs).
... and true, Dell offers linux for servers (read the page you provided and you will see how great is to run LAMP on Dell) and not for desktops (e.g. http://linux.slashdot.org/article.pl?sid=07/03/12/0128257 )
What mdsahni tries to explain, is like when you say that you offer PostgresSQL support, with 2 minor exceptions, not postgresql but EnterpriseDB, not fully supported but beta.
Let me tell you a joke from Eastern Europe Comunism Era:
Q: Is it true that Ivan was given a car ?
A: True, true ! with 2 exceptions: not a car but a bicycle, not given but taken.
I think you are getting something wrong here:
1) Enterprise DB is in final beta and will be supported / is suppoted, if you look at all the support requests users get active help
2) It should run on Postgres to, but as compiere does not have a Postges Support team it will not officially support it, but it should work
Hi Yves Sandfort,
> 1) Enterprise DB is in final beta and will be supported / is suppoted, if you look at all the support requests users get active help
> 2) It should run on Postgres to, but as compiere does not have a Postges Support team it will not officially support it, but it should work
Ok, i rephrase my last post:
...is like when you say that you offer PostgresSQL support, with 2 minor exceptions, not postgresql but EnterpriseDB and "as compiere does not have a Postges Support team it will not officially support it, but it should work", not fully supported but "final beta and will be supported / is suppoted".
Btw, did you like the joke ?
On EnterpriseDB and PostgreSQL:
Honestly, this is a current debate within Compiere. At this point we know that we will support EnterpriseDB, and we are still deciding on exactly how to "officially" handle PostgreSQL. The community has spoken loud and clear about the desire to have support for PostgreSQL, and I have communicated this back to our management team.
I would like to let this debate lie for a few weeks until the EnterpriseDB port is in better shape. In a few weeks, we will know exactly how well (or not) the EnterpriseDB port works with PostgreSQL. At that point, we can figure out exactly what (if anything) we need to do to get it working with PostgreSQL.
In regards to EnterpriseDB and PostgreSQL, you could tell the management team that they could consider something similar to IBM's WebSphere Application Server Community Edition vs. Apache Geronimo support model. WebSphere Application Server Community Edition is an application server that is based on the open source Apache Geronimo application server, just like EnterpriseDB is based on PostgreSQL. In WebSphere Application Server Community Edition, they add more tools and added stability and performance to Apache Geronimo. IBM primarily promotes WebSphere Application Server Community Edition, however they also provide official support for Apache Geronimo as well. They do not actively market their Apache Geronimo support however they still support it since the product is pretty similar to WebSphere Application Server Community Edition which is based on the former and hence they can leverage their WebSphere Application Server Community Edition support team to also support Apache Geronimo.
As you can see their WebSphere Application Server Community Edition website is a lot spiffier and marketing-oriented than their Apache Geronimo support page on their website, which indicates that their marketing is behind WebSphere Application Server Community Edition, however support for Apache Geronimo is still there, although not actively marketed:
IBM page for WebSphere Application Server Community Edition
IBM page for Apache Geronimo
My understanding is that if Compiere works on EnterpriseDB it will also work on standard PostgreSQL (as long as they don't use proprietary EnterpriseDB features which I don't think they will). In fact in the Compiere 2.6.0c RUN_Setup program, it doesn't even mention EnterpriseDB under the database type field, it just lists postgres, which I understand that it will also work on standard PostgreSQL with no problems (although of course not when it is beta but later when it is production quality). EnterpriseDB is just a more stable version of PostgreSQL also with some additional tools so it may still make sense for a serious operation to use EnterpriseDB rather than standard PostgreSQL. But I believe the choice to run it on standard PostgreSQL will be available too.
The joke was really funny though :-) Thanks..
It was pretty difficult to summarize so much information into a concise summary, but here is what I have so far. The summary only contains requests that appeared in more than one post indicating that the items were desired by multiple people. This is also focused more heavily on new product features and improvements, since this was the request in the original thread, and Compiere is currently working on product prioritization right now. Please feel free to make any suggestions for improvement, but keep in mind that the goal is to keep this summary short and point people to the SourceForge thread for details. We want Compiere and the community to stay focused on a few things and do those really well.
Please keep in mind that this is a SUMMARY, not a response. Before I distribute this widely within Compiere to get a response, I want to make sure that I have accurately captured the spirit of the community feedback.
Existing Activities Already Underway:
Compiere is very focused right now on fixing bugs and making the existing product better, and some specific ideas were mentioned in various threads. Again, please make sure that you submit all of your bugs!
HTML UI and other UI issues were also suggested, and as mentioned in the beginning of this thread, this is another current area of focus for Compiere.
The EnterpriseDB port is underway, and we have a few people testing now. We would like to get even more people testing this port in April! There are also ongoing discussions about PostgreSQL.
Top Priority: Manufacturing
Many of the requests related to having manufacturing functionality within Compiere. Here are a couple of representative quotes from the SourceForge thread:
“I know that there is some production-related features currently but to me it seems like most often partners build significant additional manufacturing functionality as an extension since there is a lot of unmet production-related requirements in the existing core functionality. Rather than having partners add the manufacturing functionality, I think the cross-industry manufacturing functionality should be in the core Compiere code and partners should provide additional vertical industry-specific functionality as extensions.” – Mete (Touchtone)
“I'd like to think as well that manufacturing-support needs to be base-line.” – Reinier (Open Mind Consultancy)
Other Product Feature Requests:
On the topic of Database support, Several community members are excited about the upcoming EnterpriseDB support and are eager to begin beta testing. People are also curious about support for PostgreSQL. Database independence and support for additional databases (DB2 / Postgres) was also a common thread.
Improving localization was another common suggestion: “I feel this is a very important issue that hasn't been duly attended and the Community could be of great help … Let me further point out that this shouldn't involve just language translations but also good language localization as it is the case with Spanish Language Pack, I'm sure the terminology looks good for argentinans but for mexicans it looks awkward. Also things like date/numeric format and accounting/tax issues, I am sure every country has its very own requirements and Compiere should take these into consideration and prioritize them, I am sure the community can play a big role here too because if Compiere,Inc hasn't enough time/resources to provide these fixes, then we could all help determine the requirements and maybe look for some sponsors, then when the development/effort cost/time is covered, Compiere,Inc or its Community e.g. can perform these fixes.” – Enrique Ruibal
Misc. Feature Requests:
There were also a number of additional feature requests mentioned in individual threads on SourceForge. I have already been asking several key people at Compiere to look at the details in these threads.
Make it easier to write and apply third party extensions to Compiere.
Improve training, documentation, and marketing by providing official training (class room training) in Asia, and creating more online training / sales materials: Online training material for distance learning, online pre-sales material / webcasts / webinars. Publish Solid and Real reference sites / success stories with customer C level endorsements.
More frequent communication and engagement with the community including shared roadmaps, increased acceptance of community contributions, and more participation from Compiere on the SourceForge forums.
I agree with a number of items mentioned already that are technology-related or common across many types of customers: such as completing the EnterpriseDB port, delivering a very easy to use and extensible (via AJAX) HTML UI, the AD export / import feature we've talked about for some time now (aka "transportable components") and so on.
I would add to that list one common requirement: an easy to use report generation tool. Every customer wants reports and they all want it done their own way. We've integrated Jasper in each implementation we've done, because people like the ease of use you get with iReports. Of course, you've got know know SQL to use that. I'm not sure how things work with something like Pentaho.
But there is one thing wrong with the process that is troubling me. ERP is such a big sell - after all, our potential clients are looking to run their *business* on this. Therefore, I believe strongly that instead of (or in addition to) getting a long list of random features, you need to look at the verticals that you want Compiere to be a success in. By doing that, you can ensure that as you prioritize, that you are positioning Compiere well in different verticals and better enabling us to close deals.
For example - are we serious about retail? Then we need a best-in-class (and working) POS system. It doesn't have to be a hardware-specific system, but just a very good PC based system. The current one simply doesn't work. Retail also demands a real Returns Management capability. The negative Sales Order is ok for very small places, but even medium-sized retail outfits want something better. Then there is CRM - each retail place we've pitched has needed a better core CRM set of functions, such as to remind their sales people who to call today, log notes from calls and so on. Doesn't have to be Sugar or SalesForce.com, but needs to have some core capability. Each place I've pitched has not wanted to use a CRM system in conjunction with Compiere, but to have a core set of CRM in Compiere.
Serious about light manufacturing and distribution? We have gaps in serialization at a minimum. We've had to build a feature to ease the process of receiving serialized items, which require one receipt line per unit, no matter how many were ordered on a single PO line. Have to have that in order to enter in all of the serial numbers. (By the way, retail often needs this as well, and a retail prospect of ours - if we win it - will need this feature as well). Incidentally, Don has a spec from TDS for this feature, and I'm hoping to contribute this latest version we're building.
Related to serialization is product instance attribute sets. I wasn't able to use them for Vertex for several reasons that are now fixed, but i believe 1504883 is still open.
Finally, both distribution and retail need label barcode printing! We've had to deliver that twice as well. Oh, and I forgot about Packing. Distribution companies in particular repack parts they've purchased in order to sell them. The current Pack feature is half done.
Then there is professional services firms. We tried pitching to a product design services firm recently, and I simply won't do it again. There are too many gaps in the existing projects, services and resources / time reporting features in Compiere. Most of the problems that I've seen are already listed as bug reports in the SF bug system. (In fact, there is an exchange on the partners forum with Jorg about many of these issues, including supporting Time and Materials versus Fixed price projects, etc). These are known issues - or rather, they are features that were never really finished.
So I feel strongly that we should get out of the "ad-hoc" feature lists, and look hard at what it takes to be a strong solution in each vertical. Or at least include with the ad-hoc lists a different view by vertical and include that 'view' as you are prioritizing.
Since TDS has the most experience with distribution and light manufacturing, that is probably where I'd like to see the greatest emphasis. But we've tried to land some retail opportunities and lost on each of them so far because of missing / incomplete features. We would sure like to be competitive there.
Transitional Data Services.
Thanks Dawn for the positive feedback so far.
1) Rental Billing / Rental Agreements
Such functionality would be applicable to a wide range of businesses (Car Rental, Office Equipment rental like Photo copier rental, Video Rental, etc.) I have been working on a specification document which will be done hopefully soon.
2) Contract Billing
3) Better UI and HTML UI - Some competitive products (such as MS Dynamics GP) win hands down when it comes to the presentation of their products, and I have to admit that Dynamics GP 10 looks very appealing. And lets face it, aesthetics play a pivotal role in peoples opinion and first impressions of anything.
4) Integration / commonality between Content Management and the Webstore. These two components should be inherent in each other, not separate.
5) Improvements to Webstore - it is very basic currently.
6) Exporting and Importing of workflows, alerts, performance, print formats, content management templates and webstore templates. This would allow for faster deployment.
7) Better Resource scheduling and calendar - making it possible to look at all (or a group of) resources on one calendar, identified by color coding. This will assist in the overall activity of resources....when they are assigned and utilization.
An area where some effort may provide a really good improvement is in the area of Financial Reporting. The accounting facts records provide a wealth of information that could be reported on but some limitations in the Financial Report Writer make it hard to benefit from information. Many people change their ERP system because of complaints about inability to easily report on things that are important to them.
Below is a series of bugs and enhancement requests that show the nature of the improvements that could be made, hopefully without huge effort. I have tried to list them all and I apologise if I have left out anyone else's important issue - ours are all there ;-)
Bugs with category value of "Financial Report" lodged by others..
Number Open Date Lodged By
1657771 Account Elements in Report Source 12/02/07 owteldessy
1579248 Financial Report: Range bug 18/10/06 digitalarmour
1578578 Financial Period Bug - New 17/10/06 digitalarmour
1519492 Financial Report - AddRange calculation
can fail 09/07/06 bpsommerville
1328782 Error in Financial Reports with
Adjustment Period 18/10/05 kmpink
1255219 Cannot select summary nodes in Col Set 10/08/05 kmpink
1229355 Update Balance in Report Takes a Very
Long Time 29/06/05 txjdhicks
1166062 Fin Report Line Set: Copy Lines
Loses Calculations 19/03/05 gnickturner1
....lodged by us..
[ 1045910 ] Fin Report on Products - no data in column (2004-10-12)
[ 1306653 ] Financial Report - how to speed up.. (2005-09-28)
[ 1648381 ] Update Accounting Balances (2007-01-30)
lodged by Comdivision.....
[ 1017678 ] Financial Report Percentage of Column / Line combination (2004-08-28)
[ 759261 ] Element Value in Report Line Set / Line / Source sorted (2003-06-24)
lodged by J Pedersen....
[ 692585 ] Formatting of Financial Reports (2003-02-25)
lodged by us.....
[ 1045905 ] Fin Reports / Print Format - print separation lines (2004-10-12)
[ 1045897 ] Fin Reports - Period labels (2004-10-12)
[ 1045896 ] Fin Reports - scaling of numbers (2004-10-12)
[ 1008338 ] Financial Reports - YTD Columns (2004-08-12)
[ 1190690 ] Fin Report Line Set - operand display order (2005-04-26)
I realise that everyone has particular requirements that are important to them but hopefully every user would get benefit from attention to the above.
I miss in your summary altogether the meta layer, i.e. the one concerning the community, partner and licences, addressed pinpointedly by earlier contributions in this thread, as it is the umbrella under whose shadow we would make our business, the one which defines the relations towards people who like me have the intention of stepping in.
Not addressing this point is like buying a car without knowing how you will pay for it. This is actually a "sine quan non" condition.
It is actually irrelevant whether a port is connected or a bug solved if the underlying relations are not stated in a clear-cut way. They represent in the end the reason because I go or not to Compiere, Adempiere, Microsoft, SAP, Sage etc.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.