Here we start a topic on whether there is a need to create a separate project on Compiere due to various issues.
This discussion has been ongoing among some circles and we now have to make it more public and progressive (who started it is not the issue here), but i been asked to host the discussion here so that it can be trimmed, hilighted and managed easily as compared to SourceForge's which we can't.
Comments are therefore allowed openly as to whether there is a need or otherwise for the above suggested topic. Those who wished to be anonymous can register under different pseudonyms. Whats important is not WHO says it but WHAT is said.
My opinion here:
1) Compiere is a very valuable and quality Open Source ERP/CRM project but many does not see it as community friendly as expected of such a potential-filled Open Source project. Now so with the recent funding, one would consider that Compiere Inc has the highest motivation to make avalaible resources, as well as the political advantage to do so. We can see an example in Eclipse where IBM its initiator spare nothing to support it, making it the ecosystem of IT Applications.
2) Compiere's direction seemed to be housed within its Partners Club which is only via paid membership. There is no open, continous and contributive exchange between the initiators of Compiere and the more robust outside world.
3) There has been numerous notable contributions by third party developers such as Marco Lombardo, Victor Perez, Trifon, Bob Klein, Peter Shen, and possibly me, etc but its not clear how our work is absorbed by the parent Open Source project. The worry is that as more contributions are made with more developers coming along the same path there may soon be a disparate concoction of sorts rather than a coherent project and identity.
4) All this nowithstanding, outside sincere contributions must continue to be made and housed in their respective locations, until such time a viable resolution of the above issues present itself. Taking the cue from Apache's name reason - "all the patches", we are possibly, slowly but surely forming the main project.
Debate - Has Compiere Become Closed? Do We Fork? How?
115 posts
• Page 1 of 5 • 1, 2, 3, 4, 5
Debate - Has Compiere Become Closed? Do We Fork? How?
by red1 » Fri Sep 01, 2006 9:48 pm
Last edited by red1 on Sun Sep 03, 2006 11:58 am, edited 3 times in total.
- red1
- Site Admin
- Posts: 2762
- Joined: Tue Jul 06, 2004 3:01 pm
- Location: Kuala Lumpur, Malaysia
Compiere, A Bazaar or a cathedral?
by rvergara » Sat Sep 02, 2006 8:30 pm
Red,
Thanks to red for hosting this discussion.
First a short introduction. I am an electrical engineer with 25 years of experience, 10 years in the process industry, 15 years selling and implementing ERP solutions in Latin America. I currently own a small consulting house (8 people) who implement and support Compiere in Chile.
I selected Compiere after realizing that the propietary ERPs were not fulfilling their promises of delivering enough value for justifying the cost and pain of deploying for the customer organizations.
Compiere, in my view back in 2002, was set to address these issues by:
1. Providing a solid back bone (at that time) solution, which could be extended given the open access to the source
2. An enthusiastic community that were injecting energy and ideas to the project
3. A mature, skilled project manager (JJ) that had all the necessary experience to lead the project
4. A project direction to continue promoting the openess and collaboration around the solution (e.g. database independance, etc)
Although the above are good bases for initiating a successful open source project, they are not enough for maintaining development and success of the project in the long run. For this you need:
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
Having being a Compiere partner for a while and a community member since 2002, I have seen how the community has been gradually neglected and, now, completely abandoned. An open source project without a community is dead and to recreate enthusiasm back is nearly impossible.
My believe is that the Compiere Open Source Project is dead.
Compiere as a proprietary product may have further live (I doubt it) but the open source project which was a strong driving force for the popularity of Compiere is dead.
Those that believe the add value proposition of the open source solutions (partners or not partners) have been forced into a decision, either take the remains of the open source project and evolve it into a new solution where all the mentioned community forces are well managed or go for the search of a different open source solution.
We either contribute for this new project to happen or we will have to let go.
If you agree, my suggestion is that we start discussing the organization of the new project immediately without further discussion on the old (Compiere) project. The old project is a dead end and the sooner we agree on that, the faster we will be able to do productive work on the future project.
Sorry for the long post.
Regards
Ramiro
Thanks to red for hosting this discussion.
First a short introduction. I am an electrical engineer with 25 years of experience, 10 years in the process industry, 15 years selling and implementing ERP solutions in Latin America. I currently own a small consulting house (8 people) who implement and support Compiere in Chile.
I selected Compiere after realizing that the propietary ERPs were not fulfilling their promises of delivering enough value for justifying the cost and pain of deploying for the customer organizations.
Compiere, in my view back in 2002, was set to address these issues by:
1. Providing a solid back bone (at that time) solution, which could be extended given the open access to the source
2. An enthusiastic community that were injecting energy and ideas to the project
3. A mature, skilled project manager (JJ) that had all the necessary experience to lead the project
4. A project direction to continue promoting the openess and collaboration around the solution (e.g. database independance, etc)
Although the above are good bases for initiating a successful open source project, they are not enough for maintaining development and success of the project in the long run. For this you need:
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
Having being a Compiere partner for a while and a community member since 2002, I have seen how the community has been gradually neglected and, now, completely abandoned. An open source project without a community is dead and to recreate enthusiasm back is nearly impossible.
My believe is that the Compiere Open Source Project is dead.
Compiere as a proprietary product may have further live (I doubt it) but the open source project which was a strong driving force for the popularity of Compiere is dead.
Those that believe the add value proposition of the open source solutions (partners or not partners) have been forced into a decision, either take the remains of the open source project and evolve it into a new solution where all the mentioned community forces are well managed or go for the search of a different open source solution.
We either contribute for this new project to happen or we will have to let go.
If you agree, my suggestion is that we start discussing the organization of the new project immediately without further discussion on the old (Compiere) project. The old project is a dead end and the sooner we agree on that, the faster we will be able to do productive work on the future project.
Sorry for the long post.
Regards
Ramiro
- rvergara
- Posts: 47
- Joined: Sat Sep 02, 2006 7:47 pm
- Location: Santiago, Chile
RFCs on Compiere's Alternative
by croo » Sat Sep 02, 2006 9:40 pm
Hello red & all
I too think Compiere is an excellent package. It's extremely flexible, and easily customised & extended. It is in my eyes, currently the most flexible & functional ERP/CRM in the Open Source. After saying that it's not without it's flaws and I do think it's a little bit of a “lamb in wolf's clothing!”. That is to say it sells itself as a J2EE application, with a web interface, POS and offers a complete SCM solution... all great when making the sale! But not so great when it comes to implementing and we find the j2ee provides client-server functionality, the web & POS are beta (and yet never seem change from version to version?) and the SCM can't handle something as basic as a “goods return”. It seems to me like Inc could do with a helping hand!?
I do not have any issue with Inc raising venture capital, charging for a support licenses or licensing partners. It takes money to support & promote and if they want to move up the “food chain” then a strong partnership network is something the bigger players will look for. In my view, for a business, price is ultimately only one factor and probably not the most important. To me quality is most important. It doesn't matter if a product costs zero, if you can't rely on it to run your business then no one is interested. On a package as comprehensive as Compiere wants to be, to get this quality you need a whole lot of testing. For sure, partners can certainly play their part, but I am totally confused as to why Inc refuses patches from anyone else? They could review them and if the quality is not good recreate them as they see fit, so long as the next version doesn't contain that bug I'm sure everyone would be happy.
Now I have seen the posts from people in the SF forums complaining about CVS access. I had assumed the problem was one of timing, i.e. the CVS head was not being updated regular enough. But when Trifon pointed out that there hasn't been any commits made since early April (5 months ago), well, I was totally taken aback. How many bug reports (via Support Requests) have been made since then and how many have downloaded Compiere since then only to waste their time trying to work around those very same bugs. All those eyes that could have been testing the “latest and greatest” version to improve quality have been wasting their time! If this is the approach Inc have decide on then I doubt the quality of Compiere will ever improve. And as I said previously, in my book, quality is what it's all about. An application like this, that by it's very nature, touches every aspect of a business - if it cannot be relied upon by the people who use it ... well it simply won't work. Now I realise that all application have quality issues. Being Open Source I think Compiere needs to be better than average in quality terms. Although it's slowly changing, many business people (i.e. potential customers) still feel “if it's free there must be something wrong with it!”.
So for me, this is what it comes down too – without a vibrant community Inc do not have the resources to build a package of the quality required. The partners will be a great help to them but not enough, and I think the 253a release was a perfect example of that. It was originally an Aug '05 release that was delayed until Nov '05 (I think?) while it was tested by the partners... and it's still full of bugs! There are currently over 350 confirmed & open bugs for Compiere on SF; on the plus side there are less than 50 Open & Pending Support Requests ... some of these will undoubtedly become bugs.
As for creating a fork, well there are currently 42 projects on SF which make reference to Compiere. It strikes me that there is already too much duplication of effort! I don't know about others but I came to Compiere in search of product that I could implement for others and earn some money. But managing a fork is a completely different undertaking and while we are managing it we cannot be out earning a living! This is why the Compiere pitch .... we'll look after the software and you look after the implementation... is so tempting. The problem is we are finding “issues” during the implementations, spending a lot of time & effort doing Inc's job to fix/enhance and then want to roll them back into the software (to improve it and save us the trouble of doing it all again next time), but to do this Inc wants a fee. So they want a fee from us before we earn anything, as opposed to paying some of what we earn! So at the end of the day while their proposal initially looks like a partnership, in actuality WE are the target customers of Inc... and not our business customers! Now after saying that I would point out that we are all (I think?) still working on the “standard” Inc version and not one of the many clones ... I think that says something!
I, personally, am at this point unsure which way to turn. Whether intended or not, with no public releases in 5 months while at the same time nightly releases to their paying customers (i.e. their “partners”), Compiere no longer looks Open; and even worse the roadmap/strategy of Inc is completely unclear. They have had lots of opportunity to answer worries and questions from contributors raised in the SF forums and have to date not availed... which is leading me to conclude that they may have an agenda that they do not wish to express!?
colin
ps. apologies for submitting a "novel"
I too think Compiere is an excellent package. It's extremely flexible, and easily customised & extended. It is in my eyes, currently the most flexible & functional ERP/CRM in the Open Source. After saying that it's not without it's flaws and I do think it's a little bit of a “lamb in wolf's clothing!”. That is to say it sells itself as a J2EE application, with a web interface, POS and offers a complete SCM solution... all great when making the sale! But not so great when it comes to implementing and we find the j2ee provides client-server functionality, the web & POS are beta (and yet never seem change from version to version?) and the SCM can't handle something as basic as a “goods return”. It seems to me like Inc could do with a helping hand!?
I do not have any issue with Inc raising venture capital, charging for a support licenses or licensing partners. It takes money to support & promote and if they want to move up the “food chain” then a strong partnership network is something the bigger players will look for. In my view, for a business, price is ultimately only one factor and probably not the most important. To me quality is most important. It doesn't matter if a product costs zero, if you can't rely on it to run your business then no one is interested. On a package as comprehensive as Compiere wants to be, to get this quality you need a whole lot of testing. For sure, partners can certainly play their part, but I am totally confused as to why Inc refuses patches from anyone else? They could review them and if the quality is not good recreate them as they see fit, so long as the next version doesn't contain that bug I'm sure everyone would be happy.
Now I have seen the posts from people in the SF forums complaining about CVS access. I had assumed the problem was one of timing, i.e. the CVS head was not being updated regular enough. But when Trifon pointed out that there hasn't been any commits made since early April (5 months ago), well, I was totally taken aback. How many bug reports (via Support Requests) have been made since then and how many have downloaded Compiere since then only to waste their time trying to work around those very same bugs. All those eyes that could have been testing the “latest and greatest” version to improve quality have been wasting their time! If this is the approach Inc have decide on then I doubt the quality of Compiere will ever improve. And as I said previously, in my book, quality is what it's all about. An application like this, that by it's very nature, touches every aspect of a business - if it cannot be relied upon by the people who use it ... well it simply won't work. Now I realise that all application have quality issues. Being Open Source I think Compiere needs to be better than average in quality terms. Although it's slowly changing, many business people (i.e. potential customers) still feel “if it's free there must be something wrong with it!”.
So for me, this is what it comes down too – without a vibrant community Inc do not have the resources to build a package of the quality required. The partners will be a great help to them but not enough, and I think the 253a release was a perfect example of that. It was originally an Aug '05 release that was delayed until Nov '05 (I think?) while it was tested by the partners... and it's still full of bugs! There are currently over 350 confirmed & open bugs for Compiere on SF; on the plus side there are less than 50 Open & Pending Support Requests ... some of these will undoubtedly become bugs.
As for creating a fork, well there are currently 42 projects on SF which make reference to Compiere. It strikes me that there is already too much duplication of effort! I don't know about others but I came to Compiere in search of product that I could implement for others and earn some money. But managing a fork is a completely different undertaking and while we are managing it we cannot be out earning a living! This is why the Compiere pitch .... we'll look after the software and you look after the implementation... is so tempting. The problem is we are finding “issues” during the implementations, spending a lot of time & effort doing Inc's job to fix/enhance and then want to roll them back into the software (to improve it and save us the trouble of doing it all again next time), but to do this Inc wants a fee. So they want a fee from us before we earn anything, as opposed to paying some of what we earn! So at the end of the day while their proposal initially looks like a partnership, in actuality WE are the target customers of Inc... and not our business customers! Now after saying that I would point out that we are all (I think?) still working on the “standard” Inc version and not one of the many clones ... I think that says something!
I, personally, am at this point unsure which way to turn. Whether intended or not, with no public releases in 5 months while at the same time nightly releases to their paying customers (i.e. their “partners”), Compiere no longer looks Open; and even worse the roadmap/strategy of Inc is completely unclear. They have had lots of opportunity to answer worries and questions from contributors raised in the SF forums and have to date not availed... which is leading me to conclude that they may have an agenda that they do not wish to express!?
colin
ps. apologies for submitting a "novel"
- croo
- Regular
- Posts: 89
- Joined: Sat Sep 02, 2006 6:53 pm
- Location: Ireland
by afalcone » Sun Sep 03, 2006 12:54 am
Hi all,
I believe that all who we find us in this forum, share the opinion that Compiere is a great product and all we will give credit to the excellent work developed by Jorg Janke. (I believe that this is matter out of discussion).
I think that all we are here in this forum, mainly by the politics that applies Compiere Inc. I believe that they establish those according to their business and needs. The problem is like those politics affect to us (the community). All we know the problems to the ones that we face us: absence of official’s helps in the forums, absence of releases, lack of attention to the developers and contributors, roadmap/strategy completely unclear, nightly releases to their paying customers, etc. These are some realities that we're confronting each day.
In my opinion, Compiere Inc. is taking a road without return behind. I believe that in the best of the cases, for us the community, they will go to a system with 2 versions: a) greater functionality for the partners and b) more limited versions for the users remainder (us). That is what is commented "off the record".
I believe then, that the question that we should do is: Can we, the community, modify these conditions?
In my opinion, not. The 6M in funds that Compiere has obtained, as said Trifon some days ago, should be returned. Nobody invests happily money if isn't assured that the same will be returned.
I agree with Colin, about the projects around Compiere. Some them with success? None of them has any type of support, neither reference even, from Inc.!. Many of them, are excellent initiatives and very good works (as said Red1), like developed by Victor Perez, Peter Shen, Rob Klein and many other. But none of them was supported by Inc. I believe that we should not have many hopes to obtain answers on the part of Inc. At this moment I’m a little pessimist....
About a fork? I believe that is a possibility that should not be ruled out without before study it and to debate it. All we know the effort that it implies. Are we in conditions to carry it ahead? Are there resources to do it? I believe that something in which all we should agree, if we opt for that way, we should do a really Open Source project, with a participatory and open community.
About to join us to another project, like OpenBravo or another? I don’t know these others projects. Maybe someone can let know us about these.
I am not sure that I want to abandon Compiere, but each day is harder to work with them, by the politics closed that they have.
These are, quickly, some of my opinions. I’m interested to listen many others.
You must forgive me because my english is more or less.
Best regards
Alejandro
I believe that all who we find us in this forum, share the opinion that Compiere is a great product and all we will give credit to the excellent work developed by Jorg Janke. (I believe that this is matter out of discussion).
I think that all we are here in this forum, mainly by the politics that applies Compiere Inc. I believe that they establish those according to their business and needs. The problem is like those politics affect to us (the community). All we know the problems to the ones that we face us: absence of official’s helps in the forums, absence of releases, lack of attention to the developers and contributors, roadmap/strategy completely unclear, nightly releases to their paying customers, etc. These are some realities that we're confronting each day.
In my opinion, Compiere Inc. is taking a road without return behind. I believe that in the best of the cases, for us the community, they will go to a system with 2 versions: a) greater functionality for the partners and b) more limited versions for the users remainder (us). That is what is commented "off the record".
I believe then, that the question that we should do is: Can we, the community, modify these conditions?
In my opinion, not. The 6M in funds that Compiere has obtained, as said Trifon some days ago, should be returned. Nobody invests happily money if isn't assured that the same will be returned.
I agree with Colin, about the projects around Compiere. Some them with success? None of them has any type of support, neither reference even, from Inc.!. Many of them, are excellent initiatives and very good works (as said Red1), like developed by Victor Perez, Peter Shen, Rob Klein and many other. But none of them was supported by Inc. I believe that we should not have many hopes to obtain answers on the part of Inc. At this moment I’m a little pessimist....
About a fork? I believe that is a possibility that should not be ruled out without before study it and to debate it. All we know the effort that it implies. Are we in conditions to carry it ahead? Are there resources to do it? I believe that something in which all we should agree, if we opt for that way, we should do a really Open Source project, with a participatory and open community.
About to join us to another project, like OpenBravo or another? I don’t know these others projects. Maybe someone can let know us about these.
I am not sure that I want to abandon Compiere, but each day is harder to work with them, by the politics closed that they have.
These are, quickly, some of my opinions. I’m interested to listen many others.
You must forgive me because my english is more or less.
Best regards
Alejandro
- afalcone
- Regular
- Posts: 120
- Joined: Fri Jun 24, 2005 4:09 am
- Location: Argentina
by paviles » Sun Sep 03, 2006 10:05 pm
Well, some of the comments here are very good. Just a point on Openbravo. I like the idea of a web interface better than Compiere's client, after all, more and more browser based apps are in on the horizon with ajax and related technologies. Having said that, I have sent a few emails to the OB folks both in english and spanish without a response.....pretty sad for a company that is trying to make a "new" products as OB is...will see what happens with them....
As for Inc, we decided not to pay the partner fees as their speech was like a car salesperson, a lot of hipppppppeeee and no substance and we are glad we did not pay the close to 10K last year. There were a lot of questions like roadmap, future to the project, web clients, just regular stuff that they did not have answers or did not want to share... pretty bad for your "new partner" to be...
I think that there is a tremendous opportunity in maintaining the Compiere Open Source soul alive. We have done it with the old Sun Cobalt units with BlueQuartz and we contribute to the community with source and patches that do get incorporated into the main code and cvs. Yes, it is difficult to find time to do it, but it can only get better if the right people are in place, and the proper documentation and processes are followed.
I think there is enough interest and knowledge out there not to do it. If anyone is interest in doing so, then lets talk...
Paul Aviles
Weston, FL
Don Ramiro Vergara, me podrias contactar con tu datos personales?
Saludos,
Paul
As for Inc, we decided not to pay the partner fees as their speech was like a car salesperson, a lot of hipppppppeeee and no substance and we are glad we did not pay the close to 10K last year. There were a lot of questions like roadmap, future to the project, web clients, just regular stuff that they did not have answers or did not want to share... pretty bad for your "new partner" to be...
I think that there is a tremendous opportunity in maintaining the Compiere Open Source soul alive. We have done it with the old Sun Cobalt units with BlueQuartz and we contribute to the community with source and patches that do get incorporated into the main code and cvs. Yes, it is difficult to find time to do it, but it can only get better if the right people are in place, and the proper documentation and processes are followed.
I think there is enough interest and knowledge out there not to do it. If anyone is interest in doing so, then lets talk...
Paul Aviles
Weston, FL
Don Ramiro Vergara, me podrias contactar con tu datos personales?
Saludos,
Paul
- paviles
- Posts: 1
- Joined: Sun Sep 03, 2006 9:53 pm
by rvergara » Sun Sep 03, 2006 11:00 pm
paviles wrote:
Don Ramiro Vergara, me podrias contactar con tu datos personales?
Saludos,
Paul
Paul, te mandé un mensaje privado a través de éste foro con mis datos personales. En todo caso mi email es ramiro.vergara@ofbconsulting.com
Saludos
Ramiro
- rvergara
- Posts: 47
- Joined: Sat Sep 02, 2006 7:47 pm
- Location: Santiago, Chile
by chitech » Mon Sep 04, 2006 1:39 am
It's a sad sad day...
More of a systems integrator and relying on open source software for small businesses, we ask the business owners to at least, at minimum donate a percentage of the total cost of install to whatever software they used.
They are told this, even though it is open source there are costs involved to the developers. And if they want to use open source then they themselves are obligated to contribute to the project in some fashion.
I personally have been watching compare for one and a half years. It saddens me to see that they have closed off the open development, bug fixes and all within source forge. With that said, I am surprised source forge is allowing them to maintain their open source status. I guess there is something to say about that too, however that is not the subject here.
I would be obliged to setup cvs for continued open source contributions and bug fixes. Just let me know... I'll keep watching here.
If my understanding of what is going on, please by all means correct me.
More of a systems integrator and relying on open source software for small businesses, we ask the business owners to at least, at minimum donate a percentage of the total cost of install to whatever software they used.
They are told this, even though it is open source there are costs involved to the developers. And if they want to use open source then they themselves are obligated to contribute to the project in some fashion.
I personally have been watching compare for one and a half years. It saddens me to see that they have closed off the open development, bug fixes and all within source forge. With that said, I am surprised source forge is allowing them to maintain their open source status. I guess there is something to say about that too, however that is not the subject here.
I would be obliged to setup cvs for continued open source contributions and bug fixes. Just let me know... I'll keep watching here.
If my understanding of what is going on, please by all means correct me.
- chitech
- Posts: 1
- Joined: Mon Sep 04, 2006 1:24 am
- Location: Chicago, IL
by red1 » Mon Sep 04, 2006 11:33 am
After thinking more about this, perhaps we can maintain the status quo but with a friendly forking strategy:
1) We merely freezes a version of Compiere say 253a for bug repair and extending work.
2) We housed that in our respective locations and synch with each other and act as mirrors to the whole community.
In that respect i have a clean version of 253a (taken from Frans Thamura's Indonesian book) in http://sf.net/projects/university under the module name C-253a. Anyone who has bug fixes in the course of their work can post there and make a remark in them and announce in the Tasks section.
3) We communicate among ourselves as a virtual community without politics nor patronage from any particular party, to decide in the best interest of the OS nature of the project. We basically decide on standards and the way forward and get out of everyone's way in using them.
4) We can develop certain addons without forking from the architecture in Compiere so that future releases of Compiere can be studied and its gaps closed to the FriendlyForks.
4.1) Add-ons has to follow the best practice as suggested by NeilG where we develop them as separate packages so as to allow easy upgrading and selective use of them similar to plugins or Eclipse like fashion.
4.2) I have done Jakarta velocity UI on Compiere (see Telephony posts in Compiere Workshop Forum) and shall publish a write up on it. The velocity plugin is CVS to http://sf.net/projects/university look for the CITY module and NTSB Module.
The NTSB module which is the telephony project uses CITY for Velocity layer and Compiere jars for model reuse. U can view and try the sample codes to see how it fit into the CRM portion of Compiere. The licensing is not fixed but most likely Apache 2. (Note: NTSB has another portion which is the linkage to Asterisk IP PBX which is blackboxed and not posted nor needed for this CRM Dashboard to run).
1) We merely freezes a version of Compiere say 253a for bug repair and extending work.
2) We housed that in our respective locations and synch with each other and act as mirrors to the whole community.
In that respect i have a clean version of 253a (taken from Frans Thamura's Indonesian book) in http://sf.net/projects/university under the module name C-253a. Anyone who has bug fixes in the course of their work can post there and make a remark in them and announce in the Tasks section.
3) We communicate among ourselves as a virtual community without politics nor patronage from any particular party, to decide in the best interest of the OS nature of the project. We basically decide on standards and the way forward and get out of everyone's way in using them.
4) We can develop certain addons without forking from the architecture in Compiere so that future releases of Compiere can be studied and its gaps closed to the FriendlyForks.
4.1) Add-ons has to follow the best practice as suggested by NeilG where we develop them as separate packages so as to allow easy upgrading and selective use of them similar to plugins or Eclipse like fashion.
4.2) I have done Jakarta velocity UI on Compiere (see Telephony posts in Compiere Workshop Forum) and shall publish a write up on it. The velocity plugin is CVS to http://sf.net/projects/university look for the CITY module and NTSB Module.
The NTSB module which is the telephony project uses CITY for Velocity layer and Compiere jars for model reuse. U can view and try the sample codes to see how it fit into the CRM portion of Compiere. The licensing is not fixed but most likely Apache 2. (Note: NTSB has another portion which is the linkage to Asterisk IP PBX which is blackboxed and not posted nor needed for this CRM Dashboard to run).
- red1
- Site Admin
- Posts: 2762
- Joined: Tue Jul 06, 2004 3:01 pm
- Location: Kuala Lumpur, Malaysia
by wellx » Mon Sep 04, 2006 10:30 pm
my 2 cents: i think we must define any roadmap for features. I see as
1. Move to 3 tier on JBoss directly
2. DB independence
3. AJAX UI + SOAP or web-services
And, we should coordinate with other Compiere sites? may be create OpenCompiere Fund and let worldwide support for OpenCompiere through this sites. Sorry for my english...
1. Move to 3 tier on JBoss directly
2. DB independence
3. AJAX UI + SOAP or web-services
And, we should coordinate with other Compiere sites? may be create OpenCompiere Fund and let worldwide support for OpenCompiere through this sites. Sorry for my english...
- wellx
- Posts: 4
- Joined: Thu Aug 26, 2004 5:18 pm
Debate - Has Compiere Become Closed? Do We Fork? How?
by croo » Tue Sep 05, 2006 3:57 am
While most people have chosen to watch from the side lines rather than speak their heart, I see most of those who did comment seem to be advocating an immediate fork!
Before we go down that route I would suggest we ask ourselves what is it we really wish to achieve?
Is it to gain control of the project so we can manage it ourselves or is it to have a Compiere that is open source? An open source project were all can contribute to the improvement of the application in what ever way they can. Were the considerable enhancements and extensions provided by other projects can be rolled in to provide choice & less duplication of effort, while at the same time reduce the overheads of maintenance for these projects and everyone using them.
If we fork then we are accepting the loss of a considerable driving force behind Compiere, both in Inc (with their $6m to enhance & promote) and their partners. We are also creating confusion for potential customers. And, whether it's “really” open source or not Compiere has an good image as a successful open source business application and is starting to get some positive media coverage; by forking we are losing that too! And I would suggest that much of this good publicity is because of the promotion I'm sure all of us are indirectly involved in every time we use our own name & reputation to give it the “thumbs up”; be it internally in our own company, to business friends and colleges or potential customers.
Looking at the two options; from my perspective what I think we need and want is the “open source project scenario”, rather than the fork scenario per se. Now I'm relatively new to the Compiere scene, and I when I browse through the old forum postings I see similar discussions from years back so perhaps people will say “we tried that but things are still the same!”. But I would point out that looking at the number of SF projects referencing Compiere I think perhaps the fork route has also been tried!?
So with that in mind, perhaps there is some way we can get the “open source project scenario” by “encouraging” Compiere Inc to be more open? Maybe there are things we can do to show Inc the value of their open “community”?
For example, even with no new software released for 5 months the Source Forge activity rating for the Compiere project is VERY high. I would suggest that some (perhaps a lot?) of this is down to many of us here providing free support to those considering & evaluating Compiere. A vibrant community is certainly something anyone considering an Open Source package would look for. And the last thing they would like to see is a disgruntled community ... Now I'm not suggesting that we do not help people, just that we also help them to understand the true open source nature of the Compiere project. And when we do provide support we do NOT provide it directly on the projects SourceForge forums but via some agreed site ... perhaps even his site! This I'm sure would reduce the projects activity rating on SF!
We could, as red1 suggested, provide an alternative download to the official SF/Compiere site were we can share fixes & enhancements to the standard release. This way we get to share while at the same time continue to make use of the considerable knowledge of Inc & its partners (by baseing it on the latest standard release).
Now I know a lot of work has already been done by people on the XML2AD & AD2XML tools, as well as the 2Pack tool, but I might also suggest that we work to create user friendly tools to enable “migration” to newer versions WITHOUT a Compiere Inc support license, perhaps even base the alternative download on the ComXE project thereby removing the need for many small firms to require an Oracle license and so reduce further their reliance on having a Inc support contract.
As I said at the start, the idea is to help Compiere Inc see the value of it's community (by taking it away!), and hopefully encourage it to be more community orientated! And I'm sure there are many other ideas out there ... perhaps some that don't come across as being so “nasty” (sorry for that!) and devious. And I am I'm not suggesting we “damage” Compiere, after all as I started with it is something I think we all believe in. But if Inc is totally focused on the commercial aspects perhaps such actions would help it find some new perspective of its own!?
I realise this is somewhat of a negative posting, but I'm just trying to take a look at the situation from a different perspective. Many would consider these suggestions a little underhanded, and I would agree and to be perfectly honest I was very reluctant to even make the suggestions. But actions such as these might help Inc to see the value of their community! I know if I had just invested $6 million these are some things I would NOT like to see happen! Another perspective is that actions such as these would force Inc to not release source at all, but at least we could draw a line and say it's definitely not an open source project ... once way or another we would have forced the issue, and Inc to chose - removing, what to me at least, has become a very grey area!
Finally I would say to those watching this thread but not commenting “say your bit ... even if it's just “fork” or “no fork”! what is the consensus?
colin
Before we go down that route I would suggest we ask ourselves what is it we really wish to achieve?
Is it to gain control of the project so we can manage it ourselves or is it to have a Compiere that is open source? An open source project were all can contribute to the improvement of the application in what ever way they can. Were the considerable enhancements and extensions provided by other projects can be rolled in to provide choice & less duplication of effort, while at the same time reduce the overheads of maintenance for these projects and everyone using them.
If we fork then we are accepting the loss of a considerable driving force behind Compiere, both in Inc (with their $6m to enhance & promote) and their partners. We are also creating confusion for potential customers. And, whether it's “really” open source or not Compiere has an good image as a successful open source business application and is starting to get some positive media coverage; by forking we are losing that too! And I would suggest that much of this good publicity is because of the promotion I'm sure all of us are indirectly involved in every time we use our own name & reputation to give it the “thumbs up”; be it internally in our own company, to business friends and colleges or potential customers.
Looking at the two options; from my perspective what I think we need and want is the “open source project scenario”, rather than the fork scenario per se. Now I'm relatively new to the Compiere scene, and I when I browse through the old forum postings I see similar discussions from years back so perhaps people will say “we tried that but things are still the same!”. But I would point out that looking at the number of SF projects referencing Compiere I think perhaps the fork route has also been tried!?
So with that in mind, perhaps there is some way we can get the “open source project scenario” by “encouraging” Compiere Inc to be more open? Maybe there are things we can do to show Inc the value of their open “community”?
For example, even with no new software released for 5 months the Source Forge activity rating for the Compiere project is VERY high. I would suggest that some (perhaps a lot?) of this is down to many of us here providing free support to those considering & evaluating Compiere. A vibrant community is certainly something anyone considering an Open Source package would look for. And the last thing they would like to see is a disgruntled community ... Now I'm not suggesting that we do not help people, just that we also help them to understand the true open source nature of the Compiere project. And when we do provide support we do NOT provide it directly on the projects SourceForge forums but via some agreed site ... perhaps even his site! This I'm sure would reduce the projects activity rating on SF!
We could, as red1 suggested, provide an alternative download to the official SF/Compiere site were we can share fixes & enhancements to the standard release. This way we get to share while at the same time continue to make use of the considerable knowledge of Inc & its partners (by baseing it on the latest standard release).
Now I know a lot of work has already been done by people on the XML2AD & AD2XML tools, as well as the 2Pack tool, but I might also suggest that we work to create user friendly tools to enable “migration” to newer versions WITHOUT a Compiere Inc support license, perhaps even base the alternative download on the ComXE project thereby removing the need for many small firms to require an Oracle license and so reduce further their reliance on having a Inc support contract.
As I said at the start, the idea is to help Compiere Inc see the value of it's community (by taking it away!), and hopefully encourage it to be more community orientated! And I'm sure there are many other ideas out there ... perhaps some that don't come across as being so “nasty” (sorry for that!) and devious. And I am I'm not suggesting we “damage” Compiere, after all as I started with it is something I think we all believe in. But if Inc is totally focused on the commercial aspects perhaps such actions would help it find some new perspective of its own!?
I realise this is somewhat of a negative posting, but I'm just trying to take a look at the situation from a different perspective. Many would consider these suggestions a little underhanded, and I would agree and to be perfectly honest I was very reluctant to even make the suggestions. But actions such as these might help Inc to see the value of their community! I know if I had just invested $6 million these are some things I would NOT like to see happen! Another perspective is that actions such as these would force Inc to not release source at all, but at least we could draw a line and say it's definitely not an open source project ... once way or another we would have forced the issue, and Inc to chose - removing, what to me at least, has become a very grey area!
Finally I would say to those watching this thread but not commenting “say your bit ... even if it's just “fork” or “no fork”! what is the consensus?
colin
- croo
- Regular
- Posts: 89
- Joined: Sat Sep 02, 2006 6:53 pm
- Location: Ireland
by pseudonimo » Tue Sep 05, 2006 9:05 am
Hi Guys,
I am sorry to use a pseudonimo name , but at this moment i feel more comfortable using it.
In my experience, I have been working with Compiere for 5 years. I have gotten many satisfactions, and I have taken advantage of the great job made by Jorg Janke with Compiere.
I think that the fact that the community is wondering that if it is necessary a fork, it is a sign that something is happening
I think that the best way to know if a fork is really necessary is to wondering how would be the ideal Compiere to the community and the end user customers?, if ComPiere Inc considers this as priority , more than their commercial strategy, then we dont need a fork.
Some of my questions are :
Does Compiere achieve all these points?
- Really stable , high performance, flexibility, easy to use, facility of maintenance and scalability product. (Why dont release stable versions?)
- Expand functionality footprint to be on par to world class ERP solutions. (Why try to reinvent things if we can use JPA, Reporting tools, Rules engines, etc?)
-The change of technology from a client-server to a more modern: three layers application
-User Interface focused in an easy use, intuitive, attractive and well Organized (Entry massive data in a table)
-The necessity of a real community where it is possible to integrate the others job and to collaborate in the development in a scheduled way. (Why dont use the community help in fixing bugs?)
- Open source tools to upgrade, migrate and apply bug corrections and improvements (Why just dont just an apply patch and ready tool?)
-To improve the product, based on the community necessities. (Why dont hear what the community needs?)
-A 100% open source (Why do we have oracle, pdf tools, migration tools?)
-A project with vision and better direction (Why dont have a road map clearly defined ? Does anybody knows what is comming soon, from compiere?)
-A fast evolution of the product
-A useful application for the final customer
-A product with key functionality in synch with industry business process best practices (CRM and Manufacturing)
Having experience implementing Compiere, the end user request and recurrent complaints , have make me think into solve the above issues., but also origin another two questions. How Compiere will improve the Product without having the final user feedback? (Maybe a way to know all these requeriments is via Compiere's forum), Do these requeriments has been consedered until now?
Another point that i consider very important are:
Architecture
Data Persistence and Database independance (Why just Oracle?)
Migration Tools API Plugging and Wizard (Why dont make easier others job integration?)
Business Rules Engine (Why dont set Business Rules without compiling?)
Report Generator (Why dont use an easier tool to make Reports i.e. Pentaho, Birt or Jasper?)
New Light Client (Why dont have a client faster, web based (AJAX,SOAP), with nice GUI ?)
Important Add ons
Manufacturing
Development of Plant and Equipment maintenance
Human Resources and Payroll
Fixed Assets
Cash Flow
Reports in Multiple Currencies
Improvements in the Financial module
With this i want to make a constructive comment , an i finish with the next question. Do we have to wait until compiere realize or solve all these issues or the answer its in the community?
Regards
I am sorry to use a pseudonimo name , but at this moment i feel more comfortable using it.
In my experience, I have been working with Compiere for 5 years. I have gotten many satisfactions, and I have taken advantage of the great job made by Jorg Janke with Compiere.
I think that the fact that the community is wondering that if it is necessary a fork, it is a sign that something is happening
I think that the best way to know if a fork is really necessary is to wondering how would be the ideal Compiere to the community and the end user customers?, if ComPiere Inc considers this as priority , more than their commercial strategy, then we dont need a fork.
Some of my questions are :
Does Compiere achieve all these points?
- Really stable , high performance, flexibility, easy to use, facility of maintenance and scalability product. (Why dont release stable versions?)
- Expand functionality footprint to be on par to world class ERP solutions. (Why try to reinvent things if we can use JPA, Reporting tools, Rules engines, etc?)
-The change of technology from a client-server to a more modern: three layers application
-User Interface focused in an easy use, intuitive, attractive and well Organized (Entry massive data in a table)
-The necessity of a real community where it is possible to integrate the others job and to collaborate in the development in a scheduled way. (Why dont use the community help in fixing bugs?)
- Open source tools to upgrade, migrate and apply bug corrections and improvements (Why just dont just an apply patch and ready tool?)
-To improve the product, based on the community necessities. (Why dont hear what the community needs?)
-A 100% open source (Why do we have oracle, pdf tools, migration tools?)
-A project with vision and better direction (Why dont have a road map clearly defined ? Does anybody knows what is comming soon, from compiere?)
-A fast evolution of the product
-A useful application for the final customer
-A product with key functionality in synch with industry business process best practices (CRM and Manufacturing)
Having experience implementing Compiere, the end user request and recurrent complaints , have make me think into solve the above issues., but also origin another two questions. How Compiere will improve the Product without having the final user feedback? (Maybe a way to know all these requeriments is via Compiere's forum), Do these requeriments has been consedered until now?
Another point that i consider very important are:
Architecture
Data Persistence and Database independance (Why just Oracle?)
Migration Tools API Plugging and Wizard (Why dont make easier others job integration?)
Business Rules Engine (Why dont set Business Rules without compiling?)
Report Generator (Why dont use an easier tool to make Reports i.e. Pentaho, Birt or Jasper?)
New Light Client (Why dont have a client faster, web based (AJAX,SOAP), with nice GUI ?)
Important Add ons
Manufacturing
Development of Plant and Equipment maintenance
Human Resources and Payroll
Fixed Assets
Cash Flow
Reports in Multiple Currencies
Improvements in the Financial module
With this i want to make a constructive comment , an i finish with the next question. Do we have to wait until compiere realize or solve all these issues or the answer its in the community?
Regards
- pseudonimo
- Posts: 2
- Joined: Tue Sep 05, 2006 7:42 am
Re: RFCs on Compiere's Alternative
by globalqss » Tue Sep 05, 2006 10:30 am
Hello, I want to publish my 0,01 cent - I owe you the other 0,01 cent for later
I agree that best solution will be Compiere staying open source and becoming more "community driven". But - honestly - what is the probability of that?
____________
ABOUT LICENSE:
I believe Compiere is going to a license type like JIRA. It's open source but can't be installed without payment. They have a trial license of 30 days.
It's not proprietary, it's open source, and an excellent project, but with little diffusion - I think because of their license.
If Compiere had begun with a license like JIRA, surely they would not have the community that today they have, and surely had not been unloaded and tested so many times.
Sight of this way, Compiere has used MPL license to acquire name and fame, and now that supposedly have them they will change its license (I have seen this history in other occasions).
Probably for this reason they don't want to create links with the community.
____________
ABOUT FORKING
Forking is a reality when a project of this type becomes proprietary, i.e. Interbase -> Firebird. It's a difficult decision, but I think is correct ethically (what is very important for me).
I have spent maybe 2 years studying Compiere, promoting Compiere, helping other people with Compiere, making tools for improving Compiere, developing around Compiere, fixing errors in Compiere, etc.
And I read the same from a lot of people here, and I think that "forking if proprietary" is a defensive movement to save my investment (time and knowledge in my case, because I haven't paid yet to become partner).
And what do you think about "forking if open source but not community driven"?
I believe the fork route hasn't been tried as we are doing now, convoking community.
What I have seen are sporadic intents to make contributions public (as Kompiere or CFA), they aren't forks, they are contributions not accepted at Inc.
Real forks are:
- OpenBravo - and I share some thoughts expressed recently by Red1 in SF forums
- JazzERP - what looks more like vaporware
- And there are a lot of "forks" from partners, almost every partner has a version - precisely because the lack of adopting of Compiere Inc.
____________
ABOUT RED1 PROPOSAL
(LOOSELY COUPLED COMMUNITY?)
> 1) We merely freezes a version of Compiere say 253a for bug repair and
> extending work.
> 3) We communicate among ourselves as a virtual community without politics nor
> patronage...
I don't like this proposal, I think to evolve an ERP system we need specs and roadmap, like JCP (what about a Compiere Community Process?)
> We can develop certain addons without forking from the architecture in Compiere ...
What I realize is that every installation of a serious Compiere requires touching the core.
There are a lot of things to improve Compiere that require some forking from the architecture. I.e.: there aren't pre-form, pre-record logic.
> so that future releases of Compiere can be studied and its gaps
> closed to the FriendlyForks
Not so easy if Compiere goes proprietary or protected code (Intellectual Property problems).
____________
ABOUT ROADMAP:
> i think we must define any roadmap for features. I see as
> 1. Move to 3 tier on JBoss directly
> 2. DB independence
> 3. AJAX UI + SOAP or web-services
I believe that technical roadmap is important but it is more important:
1 - Firstly define this project !!! What we are trying to do here
2 - To unite the community and try to get real compromises
The roadmap can be defined at a later stage, but my opinion is that there are architectural problems in Compiere that must be addressed first:
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
____________
ABOUT CROO PROPOSAL:
It seems attainable, but only like a mechanism of pressure for Compiere Inc. It does not solve the problem and the probability that Compiere changes is very low (I believe).
Croo, I don't see that as a nasty proposal, you and me spent a lot of time helping in forums without any revenue for that. We have total right to try to move support to another site (Red1 site is a good site for this but I miss the lack of e-mail tracking).
____________
MY GUESS:
Allow me to repeat:
I agree that best solution will be Compiere staying open source and becoming more "community driven".
But, given the circumstances, I'm closer at this moment with the fork proposal, as I said this movement is a way to protect my investment (time and knowledge).
I see this project will need a community thankful with Compiere like its origins, but completely capable of try another route from this moment.
This project will need a strong leader (the Linus for Compiere), and a lot of contributors of every sort:
- Developers
- Documenters
- Testers
- Business Analysts
I see these people daily in forums. I'll be happy if at the end of this forum the community is united and organized.
And is very probable that some partners contribute with this project also.
____________
As always, this is what I think at this moment, one single word from Compiere Inc. can change completely this discussion, but I lost the faith of this is going to happen.
I'm completely thankful with Compiere Inc. and will try to honour them in the form that conditions allow it.
Cordially,
Carlos Ruiz - globalqss
http://globalqss.com
I agree that best solution will be Compiere staying open source and becoming more "community driven". But - honestly - what is the probability of that?
____________
ABOUT LICENSE:
I believe Compiere is going to a license type like JIRA. It's open source but can't be installed without payment. They have a trial license of 30 days.
It's not proprietary, it's open source, and an excellent project, but with little diffusion - I think because of their license.
If Compiere had begun with a license like JIRA, surely they would not have the community that today they have, and surely had not been unloaded and tested so many times.
Sight of this way, Compiere has used MPL license to acquire name and fame, and now that supposedly have them they will change its license (I have seen this history in other occasions).
Probably for this reason they don't want to create links with the community.
____________
ABOUT FORKING
Forking is a reality when a project of this type becomes proprietary, i.e. Interbase -> Firebird. It's a difficult decision, but I think is correct ethically (what is very important for me).
I have spent maybe 2 years studying Compiere, promoting Compiere, helping other people with Compiere, making tools for improving Compiere, developing around Compiere, fixing errors in Compiere, etc.
And I read the same from a lot of people here, and I think that "forking if proprietary" is a defensive movement to save my investment (time and knowledge in my case, because I haven't paid yet to become partner).
And what do you think about "forking if open source but not community driven"?
I believe the fork route hasn't been tried as we are doing now, convoking community.
What I have seen are sporadic intents to make contributions public (as Kompiere or CFA), they aren't forks, they are contributions not accepted at Inc.
Real forks are:
- OpenBravo - and I share some thoughts expressed recently by Red1 in SF forums
- JazzERP - what looks more like vaporware
- And there are a lot of "forks" from partners, almost every partner has a version - precisely because the lack of adopting of Compiere Inc.
____________
ABOUT RED1 PROPOSAL
(LOOSELY COUPLED COMMUNITY?)
> 1) We merely freezes a version of Compiere say 253a for bug repair and
> extending work.
> 3) We communicate among ourselves as a virtual community without politics nor
> patronage...
I don't like this proposal, I think to evolve an ERP system we need specs and roadmap, like JCP (what about a Compiere Community Process?)
> We can develop certain addons without forking from the architecture in Compiere ...
What I realize is that every installation of a serious Compiere requires touching the core.
There are a lot of things to improve Compiere that require some forking from the architecture. I.e.: there aren't pre-form, pre-record logic.
> so that future releases of Compiere can be studied and its gaps
> closed to the FriendlyForks
Not so easy if Compiere goes proprietary or protected code (Intellectual Property problems).
____________
ABOUT ROADMAP:
> i think we must define any roadmap for features. I see as
> 1. Move to 3 tier on JBoss directly
> 2. DB independence
> 3. AJAX UI + SOAP or web-services
I believe that technical roadmap is important but it is more important:
1 - Firstly define this project !!! What we are trying to do here
2 - To unite the community and try to get real compromises
The roadmap can be defined at a later stage, but my opinion is that there are architectural problems in Compiere that must be addressed first:
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
____________
ABOUT CROO PROPOSAL:
It seems attainable, but only like a mechanism of pressure for Compiere Inc. It does not solve the problem and the probability that Compiere changes is very low (I believe).
Croo, I don't see that as a nasty proposal, you and me spent a lot of time helping in forums without any revenue for that. We have total right to try to move support to another site (Red1 site is a good site for this but I miss the lack of e-mail tracking).
____________
MY GUESS:
Allow me to repeat:
I agree that best solution will be Compiere staying open source and becoming more "community driven".
But, given the circumstances, I'm closer at this moment with the fork proposal, as I said this movement is a way to protect my investment (time and knowledge).
I see this project will need a community thankful with Compiere like its origins, but completely capable of try another route from this moment.
This project will need a strong leader (the Linus for Compiere), and a lot of contributors of every sort:
- Developers
- Documenters
- Testers
- Business Analysts
I see these people daily in forums. I'll be happy if at the end of this forum the community is united and organized.
And is very probable that some partners contribute with this project also.
____________
As always, this is what I think at this moment, one single word from Compiere Inc. can change completely this discussion, but I lost the faith of this is going to happen.
I'm completely thankful with Compiere Inc. and will try to honour them in the form that conditions allow it.
Cordially,
Carlos Ruiz - globalqss
http://globalqss.com
- globalqss
- Senior
- Posts: 599
- Joined: Thu Dec 29, 2005 4:15 am
- Location: Bogotá, Colombia
by red1 » Tue Sep 05, 2006 12:02 pm
Very powerful views out there. I must have stayed in the cave too long. Carlos, u can get email notifications to track replies via your profile here (find the box in your Profile).
I prompted Neil to tag along and he gave me this email
I prompted Neil to tag along and he gave me this email
... another good soul gone into the wildernessRed1,
I have been employed in a PHP development house. I have to be honest
with you I consider Java and Compiere to have been quite a bad dream.
The purpose of technology should be to simplify things, not make them
as
complex as compiere did. Sure it had some good features. However, I
don't think anything good can come out of the foundation which is
compiere simply because I think it is a poorly laid foundation.
Glad to be free of Compiere and back in the world of real automation
and
productivity. Open source forever! Linux rules!
Please feel free to post this message on your board if you desire.
I'm finished with Compiere unless someone pays me good money to be
involved with it. I've seen the light!!! And PHP rocks.
Cheers Neil
- red1
- Site Admin
- Posts: 2762
- Joined: Tue Jul 06, 2004 3:01 pm
- Location: Kuala Lumpur, Malaysia
My impression
by mhafod » Wed Sep 06, 2006 11:08 pm
Hello,
I first tried Compiere back in 2003 but did not implement it live for the lack of any real clients.
Last June, I got a contract for setting up an ERP for a client which has 8 sites. After going through the compiere website and being hounded for a project estimate, I selected Compiere over ERP5 and TinyERP mainly because the client required access through a web client.
I have spent the last 2 months going through the documentation and setting up a test case.
Coming from an Oracle Forms and Reports background, the learning curve was not as steep as I thought. I understand there are a lot of things I still did not come across but my main problem at this moment is the lack of a true web client. The one included in the package is a joke and can't be used in a real world application.
I have done my homework and searched eveything there is to know about Compiere but I must say that there is very limited info. Except for Red1 and some of his documents, there is nothing.
At any rate, what is frightening to me at this point in time is the lack of involvement from the Compiere team. The sourceforge section states more than 50 developers but the actual number is TWO.
With the new financing they have and the new members of the board, it is evident that a new business model is going to be put in place. This is understandable and will need to be in place so as to recoup the investment. However, for those of us who are expecting some improvements on the base package, dark days lie ahead.
Forking is going to be required, sooner or later. The only question is how and by whom. As suggested in a previous, posts, some people tried but I believe they are using the same strategy as Compiere Inc.
I like the idea of Openbravo but it looks more like a commercial setup rather than an open source model with clear and open involvement from a dedicated community.
I suggest that a core team of members makes an official request to the compiere mgmt team in order to get a clarification on the status of the compiere package. Once a reply is received (or after waiting a set numbe rof days), a decision should be made on the FORK project.
Hafed
I first tried Compiere back in 2003 but did not implement it live for the lack of any real clients.
Last June, I got a contract for setting up an ERP for a client which has 8 sites. After going through the compiere website and being hounded for a project estimate, I selected Compiere over ERP5 and TinyERP mainly because the client required access through a web client.
I have spent the last 2 months going through the documentation and setting up a test case.
Coming from an Oracle Forms and Reports background, the learning curve was not as steep as I thought. I understand there are a lot of things I still did not come across but my main problem at this moment is the lack of a true web client. The one included in the package is a joke and can't be used in a real world application.
I have done my homework and searched eveything there is to know about Compiere but I must say that there is very limited info. Except for Red1 and some of his documents, there is nothing.
At any rate, what is frightening to me at this point in time is the lack of involvement from the Compiere team. The sourceforge section states more than 50 developers but the actual number is TWO.
With the new financing they have and the new members of the board, it is evident that a new business model is going to be put in place. This is understandable and will need to be in place so as to recoup the investment. However, for those of us who are expecting some improvements on the base package, dark days lie ahead.
Forking is going to be required, sooner or later. The only question is how and by whom. As suggested in a previous, posts, some people tried but I believe they are using the same strategy as Compiere Inc.
I like the idea of Openbravo but it looks more like a commercial setup rather than an open source model with clear and open involvement from a dedicated community.
I suggest that a core team of members makes an official request to the compiere mgmt team in order to get a clarification on the status of the compiere package. Once a reply is received (or after waiting a set numbe rof days), a decision should be made on the FORK project.
Hafed
- mhafod
- Posts: 11
- Joined: Sat Jul 29, 2006 12:39 pm
by globalqss » Thu Sep 07, 2006 12:37 am
About Neil comments:
PHP vs Java vs .NET vs perl vs Python ... is an endless discussion
But my opinion is that Compiere is not addding complexity, ERP systems are complex by nature.
Probably Neil is comparing Compiere with non-ERP systems.
If I compare Compiere with other ERP systems I have worked, Compiere is the best.
But my point of view can be slanted because I give the maximum importance to be free of vendors - and this only can be achieved having sources.
(Database Independence, EJB, Ajax, 3-tier, etc.)
But I believe also that this problem can be easily solved, if not, the forking discussion would be futile.
Regards,
Carlos Ruiz - globalqss
http://globalqss.com
_____________________________________
Out of topic:
OK, I'll try to consider this as a good advice from Neil, but maybe is out of topicneilg wrote:I have been employed in a PHP development house. I have to be honest
with you I consider Java and Compiere to have been quite a bad dream.
... I've seen the light!!! And PHP rocks.
PHP vs Java vs .NET vs perl vs Python ... is an endless discussion
NOTE: Maybe I have stayed in the cave too long as Red saidneilg wrote:The purpose of technology should be to simplify things, not make them as
complex as compiere did. Sure it had some good features. However, I
don't think anything good can come out of the foundation which is
compiere simply because I think it is a poorly laid foundation.
But my opinion is that Compiere is not addding complexity, ERP systems are complex by nature.
Probably Neil is comparing Compiere with non-ERP systems.
If I compare Compiere with other ERP systems I have worked, Compiere is the best.
But my point of view can be slanted because I give the maximum importance to be free of vendors - and this only can be achieved having sources.
I think this is another error of Compiere Inc, technology is evolving and they are slow to catch-up.neilg wrote:Sure it had some good features. However, I
don't think anything good can come out of the foundation which is
compiere simply because I think it is a poorly laid foundation.
(Database Independence, EJB, Ajax, 3-tier, etc.)
But I believe also that this problem can be easily solved, if not, the forking discussion would be futile.
Regards,
Carlos Ruiz - globalqss
http://globalqss.com
_____________________________________
Out of topic:
Yes, but it only works for forums where I posted. I prefer the sourceforge notification because it notifies me every post even when I haven't answered there.red1 wrote:Carlos, u can get email notifications to track replies via your profile here (find the box in your Profile).
- globalqss
- Senior
- Posts: 599
- Joined: Thu Dec 29, 2005 4:15 am
- Location: Bogotá, Colombia
by rvergara » Thu Sep 07, 2006 5:16 am
I believe it is time to summarize some commonalities, feel free to correct me if I am wrong:
1. We all appreciate Jorg Janke contribution to the community
2. Communication and interaction with the community has deteriorated and it is doubtful that could be recovered
3. Forking is a distint possibility but has to be different to the current forkings. It needs to fulfill the Open Source Bazaar paradigm
4. If forking is done we need a project charter, rules of engagement, technology direction and roadmap prior to join and commit resources to the endeavour
On the subject of approaching Jorg Janke with a formal request for clarification on Compiere Inc plans regarding open source and the community. I have to admit this was my initial reaction, however I was convinced (by getting privileged information) that this would not get any attention and in fact it may create more hurdles into the regrouping of a post compiere community. This will only delay our objectives and time is of essence here.
As far as I understand we need to have the discussed project formed and some key milestones done by the time Compiere informs the community that all new development will be done in the closed source product. Undisclosed sources say that this will happen on or near January 1st, 2007.
Regards
Ramiro
1. We all appreciate Jorg Janke contribution to the community
2. Communication and interaction with the community has deteriorated and it is doubtful that could be recovered
3. Forking is a distint possibility but has to be different to the current forkings. It needs to fulfill the Open Source Bazaar paradigm
4. If forking is done we need a project charter, rules of engagement, technology direction and roadmap prior to join and commit resources to the endeavour
On the subject of approaching Jorg Janke with a formal request for clarification on Compiere Inc plans regarding open source and the community. I have to admit this was my initial reaction, however I was convinced (by getting privileged information) that this would not get any attention and in fact it may create more hurdles into the regrouping of a post compiere community. This will only delay our objectives and time is of essence here.
As far as I understand we need to have the discussed project formed and some key milestones done by the time Compiere informs the community that all new development will be done in the closed source product. Undisclosed sources say that this will happen on or near January 1st, 2007.
Regards
Ramiro
- rvergara
- Posts: 47
- Joined: Sat Sep 02, 2006 7:47 pm
- Location: Santiago, Chile
by trifon » Thu Sep 07, 2006 5:33 am
Hi,
I read very interesting disucssion here and i can say that i agree with most of opinions expressed here.
Unfortunately Compiere Inc. is not honourable enought to publicly expres their plans. I'm afraid that with this politic Compiere Inc. can continue as log as they want and all we will be in deadlock waiting for changes/news from Compiere Inc. Most terrifying for me is that next months Compiere Inc. will release new sources which will have GPL license and private sources with some other license. So in future Compiere Inc. will not change even a bit. WHY you will ask. Because they will conitnue saying that they are open source, but bugs are fixed in commercialy licensed bracnh. So all we will supposed to be happy having open source Compiere, but all we will be in the same bad situation like now. No support or clear view for the future of product, no chance to see critical bugs fixed in main CVS tree.
I must confess that Compiere Inc. are very good tactic players, not sure if they will win at the end but till now they achived their aim and have good money in pockets. I do not care about money they got, i need stable Compiere. That's why i was giving free support in Compiere forums i need Compiere Inc. to conitinue developing Compiere. I was trying to help Compiere as much as i can, and i see that money people do the same like me. This is good cooperation. Compiere Inc. gives sources, community helps in forums, tests, bug fixes, e.t.c. The only problem is that Compiere Inc. stoped accepting patches and listening to community. So now all we aks each other what to do? I do not see easy answer.
One future FORK need to be close to Compiere and easy to migrate to new versions, but far from Compiere as it must be stable and easy extendable. All we have customers who use Compiere, so for all us will be hard to support new project which is very different from Compiere and supporting our customers who use old Compiere. I think that small steps must be done in the begginig. Like:
If you are java developers you can try existing open source migration tools. Like 2Pack, XML2AD or AD Customization Keeper from ComXe project. Find gaps and try to improve them. All we need good migration tool, i belive that we can develop it if we join our efforts. Step by step. By this way we will have time to see how Compiere Inc. will react.
If you are good in documentation write one and share it with community. This will give you good advertisement and good trafic to your site if you host it.
If you have idea how to improve give functionality, describe your idea in public forums and see if users find it interesting. i'm sure that someone will find money for it and support development. Or even you can see it developed for free.
I belive that with small steps we can go much furhter then starting with big plans. The most important thing for me is too see community, i think that i see it now and i hope that all we will be able to help ourselvs and achieve our aims.
Kind regards,
Trifon
I read very interesting disucssion here and i can say that i agree with most of opinions expressed here.
Unfortunately Compiere Inc. is not honourable enought to publicly expres their plans. I'm afraid that with this politic Compiere Inc. can continue as log as they want and all we will be in deadlock waiting for changes/news from Compiere Inc. Most terrifying for me is that next months Compiere Inc. will release new sources which will have GPL license and private sources with some other license. So in future Compiere Inc. will not change even a bit. WHY you will ask. Because they will conitnue saying that they are open source, but bugs are fixed in commercialy licensed bracnh. So all we will supposed to be happy having open source Compiere, but all we will be in the same bad situation like now. No support or clear view for the future of product, no chance to see critical bugs fixed in main CVS tree.
I must confess that Compiere Inc. are very good tactic players, not sure if they will win at the end but till now they achived their aim and have good money in pockets. I do not care about money they got, i need stable Compiere. That's why i was giving free support in Compiere forums i need Compiere Inc. to conitinue developing Compiere. I was trying to help Compiere as much as i can, and i see that money people do the same like me. This is good cooperation. Compiere Inc. gives sources, community helps in forums, tests, bug fixes, e.t.c. The only problem is that Compiere Inc. stoped accepting patches and listening to community. So now all we aks each other what to do? I do not see easy answer.
One future FORK need to be close to Compiere and easy to migrate to new versions, but far from Compiere as it must be stable and easy extendable. All we have customers who use Compiere, so for all us will be hard to support new project which is very different from Compiere and supporting our customers who use old Compiere. I think that small steps must be done in the begginig. Like:
If you are java developers you can try existing open source migration tools. Like 2Pack, XML2AD or AD Customization Keeper from ComXe project. Find gaps and try to improve them. All we need good migration tool, i belive that we can develop it if we join our efforts. Step by step. By this way we will have time to see how Compiere Inc. will react.
If you are good in documentation write one and share it with community. This will give you good advertisement and good trafic to your site if you host it.
If you have idea how to improve give functionality, describe your idea in public forums and see if users find it interesting. i'm sure that someone will find money for it and support development. Or even you can see it developed for free.
I belive that with small steps we can go much furhter then starting with big plans. The most important thing for me is too see community, i think that i see it now and i hope that all we will be able to help ourselvs and achieve our aims.
Kind regards,
Trifon
Trifon Trifonov
- trifon
- Senior
- Posts: 324
- Joined: Thu Dec 23, 2004 11:20 pm
- Location: Bulgaria, Sofia
by red1 » Thu Sep 07, 2006 1:55 pm
On my part, i will try to upgrade this forum to a better phpBB, and eventually have it self hosted so it can do more. I m too honoured for having done what little thru this 5 USD per month portal here.
About the fork that will Never become closed again, yes i agree fully with Ramiro to work towards that. Is it in the licensing? Or is it in the community? This is to resolve the present question of forking "by whom?" as put forward by Mhafod.
Now that this shocking news of a ripoff is looming, there could be many RedHats out there presently in the shadows trying to make the best (or worst?) fork for good gain of the scraps. Thus what Ramiro points to is of importance that a Community Fork will hopefully weather the chaos that ensues. The fall of a Feudal Lord usually begets thousands more. And they only weaken the Kingdom.
The community fork is best protected by the community in general and lead by its present advocates that has proven themselves in the SF forums. These voluntary non-paying club effort must be protected and defended. If we have jobs, we pass to them in preference. They dont need donations. They can earn their keep. No need to mention names. A mere browse thru the replies can show a good measure of those who tirelessly answer calls for help.
Sustain them and they will continue to sustain thru the forums.
(I m fortunate to have comea across some rare friends who are sustaining me and believe in the OS story - that we make money purely out of services and never the same codes we produce).
I agree with Trifon that the most crucial contribution will be the Migration Tool. That can be the key to anchor the fork, as the key will always be the CarreFour for all to pass thru and make the Bazaar stay.
About the fork that will Never become closed again, yes i agree fully with Ramiro to work towards that. Is it in the licensing? Or is it in the community? This is to resolve the present question of forking "by whom?" as put forward by Mhafod.
Now that this shocking news of a ripoff is looming, there could be many RedHats out there presently in the shadows trying to make the best (or worst?) fork for good gain of the scraps. Thus what Ramiro points to is of importance that a Community Fork will hopefully weather the chaos that ensues. The fall of a Feudal Lord usually begets thousands more. And they only weaken the Kingdom.
The community fork is best protected by the community in general and lead by its present advocates that has proven themselves in the SF forums. These voluntary non-paying club effort must be protected and defended. If we have jobs, we pass to them in preference. They dont need donations. They can earn their keep. No need to mention names. A mere browse thru the replies can show a good measure of those who tirelessly answer calls for help.
Sustain them and they will continue to sustain thru the forums.
(I m fortunate to have comea across some rare friends who are sustaining me and believe in the OS story - that we make money purely out of services and never the same codes we produce).
I agree with Trifon that the most crucial contribution will be the Migration Tool. That can be the key to anchor the fork, as the key will always be the CarreFour for all to pass thru and make the Bazaar stay.
- red1
- Site Admin
- Posts: 2762
- Joined: Tue Jul 06, 2004 3:01 pm
- Location: Kuala Lumpur, Malaysia
by croo » Thu Sep 07, 2006 7:04 pm
So, with every post it looks more and more like a fork is the only option.
Like many, I suspect, I was reluctant to lose the link with Inc and partners. The organisation provides a professional “image” (not necessarily the reality!) when it comes to trying to convince a customer to go with a open source package over a commercial package. And while many of the 60+ partners were (as far as I could see anyway) never involved with the community, some were very much so and extremely helpful... I'm thinking of the likes of Adaxa when I say that but I'm sure there must be more?
I had considered mhafod's (Hafed) suggestion to “approach Inc to get clarification once and for all” a good one. This is a big step and I would hate for a split to occur because of some kind of misunderstanding. But I take the points of rvergara (Ramiro) and trifon; that Inc will not respond and will at best continue to play a delaying tactic while they make plans to restructure and protect their investment. The recent and unanswered posting in the SF Open Discussion forum from klteo (Teo) has not escape my attention. In the post Teo asks Compiere directly for confirmation on their plans, as as I mentioned it has sat there unanswered (since sept 3rd).
So it looks like we are forking!? So what next?
Well I agree with Trifon small steps are better than big plans, but I do think we need to know in what direction to take those steps, so I do think Ramiro's suggestions of defining the project “charter, rules of engagement, technology direction and roadmap” are important. But as globalqss (Carlos) pointed out, the Technical roadmap is important but at this point we need to; Firstly define the project and secondly unite the community.
So we need to define some form of project charter and rules, and unite the community?
Unite the Community: In an earlier post I had suggested (to put pressure on Inc) temporarily moving the support we provide on SF to this site, and I think we all appreciate Red's generous offer to upgrade this forum for the purpose. But I think if we are planning a fork, then in addition to forums we require the functionality to manage bugs and patches and all that stuff that SF provides! Now I don't know if others have SF projects that might be equally as useful, but I know Trifon has his ComXE project which is based on the last Compiere release 253b with the sqlj functions converted back to PL/SQL.. is that right Trifon? Wouldn't this be a good place to (temporarily at least) regroup & consolidate? To my (limited) knowledge the sqlj's only purpose was to enable DB independence, an excellent ideal but not necessarily the right way to go about it... so losing that and reverting to the PL/SQL has no disadvantages only the advantage that it runs quicker right?
So might this be a good place to initially starting building our new community? Of course I have no experience of setting up a SF project it might just as easy to start afresh? I've made the proposal; I'll leave those who have the actual experience to decide the best option!
As for the Project Aims; again I would concur with Trifon that, the immediate aim of the project should be simply to get a stable application, with the only additional functionality being the ability to migrate current Compiere users to it. Once we reach that point we can add some flesh to the technical & functional roadmaps (Although, I do think we can draw up these roadmaps in broad brush strokes to begin with).
Finally I think that wellx's proposal to “contact the other compiere SF projects to suggest integration” is also a very good idea, worthy of consideration - once we have completed the project initial aims.
colin
Like many, I suspect, I was reluctant to lose the link with Inc and partners. The organisation provides a professional “image” (not necessarily the reality!) when it comes to trying to convince a customer to go with a open source package over a commercial package. And while many of the 60+ partners were (as far as I could see anyway) never involved with the community, some were very much so and extremely helpful... I'm thinking of the likes of Adaxa when I say that but I'm sure there must be more?
I had considered mhafod's (Hafed) suggestion to “approach Inc to get clarification once and for all” a good one. This is a big step and I would hate for a split to occur because of some kind of misunderstanding. But I take the points of rvergara (Ramiro) and trifon; that Inc will not respond and will at best continue to play a delaying tactic while they make plans to restructure and protect their investment. The recent and unanswered posting in the SF Open Discussion forum from klteo (Teo) has not escape my attention. In the post Teo asks Compiere directly for confirmation on their plans, as as I mentioned it has sat there unanswered (since sept 3rd).
So it looks like we are forking!? So what next?
Well I agree with Trifon small steps are better than big plans, but I do think we need to know in what direction to take those steps, so I do think Ramiro's suggestions of defining the project “charter, rules of engagement, technology direction and roadmap” are important. But as globalqss (Carlos) pointed out, the Technical roadmap is important but at this point we need to; Firstly define the project and secondly unite the community.
So we need to define some form of project charter and rules, and unite the community?
Unite the Community: In an earlier post I had suggested (to put pressure on Inc) temporarily moving the support we provide on SF to this site, and I think we all appreciate Red's generous offer to upgrade this forum for the purpose. But I think if we are planning a fork, then in addition to forums we require the functionality to manage bugs and patches and all that stuff that SF provides! Now I don't know if others have SF projects that might be equally as useful, but I know Trifon has his ComXE project which is based on the last Compiere release 253b with the sqlj functions converted back to PL/SQL.. is that right Trifon? Wouldn't this be a good place to (temporarily at least) regroup & consolidate? To my (limited) knowledge the sqlj's only purpose was to enable DB independence, an excellent ideal but not necessarily the right way to go about it... so losing that and reverting to the PL/SQL has no disadvantages only the advantage that it runs quicker right?
So might this be a good place to initially starting building our new community? Of course I have no experience of setting up a SF project it might just as easy to start afresh? I've made the proposal; I'll leave those who have the actual experience to decide the best option!
As for the Project Aims; again I would concur with Trifon that, the immediate aim of the project should be simply to get a stable application, with the only additional functionality being the ability to migrate current Compiere users to it. Once we reach that point we can add some flesh to the technical & functional roadmaps (Although, I do think we can draw up these roadmaps in broad brush strokes to begin with).
Finally I think that wellx's proposal to “contact the other compiere SF projects to suggest integration” is also a very good idea, worthy of consideration - once we have completed the project initial aims.
colin
- croo
- Regular
- Posts: 89
- Joined: Sat Sep 02, 2006 6:53 pm
- Location: Ireland
by trifon » Fri Sep 08, 2006 12:56 am
Hi,
Today connection is very slow. So
>ComXE project which is based on the last Compiere release 253b with the sqlj functions converted back to PL/SQL.. is that right Trifon?
Yes, but actualy Compiere Inc. provide PL/SQL statements in every version. So i even do not create them. I just make small modification which stops installation from importing SQLJ functions. And other modification which allow compiere to connect to oracle XE
>Wouldn't this be a good place to (temporarily at least) regroup & consolidate?
For me it is OK.
>To my (limited) knowledge the sqlj's only purpose was to enable DB independence, an excellent ideal but not necessarily the right way to go about it... so losing that and reverting to the PL/SQL has no disadvantages only the advantage that it runs quicker right?
Yes.
>So might this be a good place to initially starting building our new community? Of course I have no experience of setting up a SF project it might just as easy to start afresh?
The only mandatory thing for me is one future project to have mailing list in which all CVs commites to be posted. I have setuped such mailing list in ComXe project. So anyone who subscribe to email list will receive emails with differences of commited files.
Regards,
Trifon
Today connection is very slow. So
>ComXE project which is based on the last Compiere release 253b with the sqlj functions converted back to PL/SQL.. is that right Trifon?
Yes, but actualy Compiere Inc. provide PL/SQL statements in every version. So i even do not create them. I just make small modification which stops installation from importing SQLJ functions. And other modification which allow compiere to connect to oracle XE
>Wouldn't this be a good place to (temporarily at least) regroup & consolidate?
For me it is OK.
>To my (limited) knowledge the sqlj's only purpose was to enable DB independence, an excellent ideal but not necessarily the right way to go about it... so losing that and reverting to the PL/SQL has no disadvantages only the advantage that it runs quicker right?
Yes.
>So might this be a good place to initially starting building our new community? Of course I have no experience of setting up a SF project it might just as easy to start afresh?
The only mandatory thing for me is one future project to have mailing list in which all CVs commites to be posted. I have setuped such mailing list in ComXe project. So anyone who subscribe to email list will receive emails with differences of commited files.
Regards,
Trifon
Trifon Trifonov
- trifon
- Senior
- Posts: 324
- Joined: Thu Dec 23, 2004 11:20 pm
- Location: Bulgaria, Sofia
by pseudonimo » Fri Sep 08, 2006 1:23 am
Taking the last posts, it seems ,because of their new staff, that compiere might go by same line like SugarCRM having all the disvantages that they already have.
http://www.compiere.org/about/board.html
Knowing this , what is the success model of a community, that we can take?
To be able to do a fork, the 253b Compiere license let us make a fork legally?
http://www.compiere.org/license.html
If the license let us do it , we can go for the next step, Are we sure of this?
Regards
http://www.compiere.org/about/board.html
Knowing this , what is the success model of a community, that we can take?
To be able to do a fork, the 253b Compiere license let us make a fork legally?
http://www.compiere.org/license.html
If the license let us do it , we can go for the next step, Are we sure of this?
Regards
- pseudonimo
- Posts: 2
- Joined: Tue Sep 05, 2006 7:42 am
by vpj-cd » Fri Sep 08, 2006 2:11 am
Hi everybody
In this discusiion i can see one thing in common , Everybody requieres a stable version, and a place where the community can work.
I am about to release my version 253b of Kompiere Manufacturing , this version has a lot of patches, that i have fixed, also i have some other new functionallity, that can be usefull to the community(MRP, CRP, Manufacturing Order, Shop floor control, subcontrating, cash flow, PostgreSQL, etc),
We can integrate everybody job in this project (http://sourceforge.net/projects/cmpcs), the patches of trifon (253b) and red1 (253a), and if somebody else has jobs of their own, we can integrate them too. And at the end have a Compiere that collects the community job, as a result we will achieve the main goal of having a stable compiere with extra functionality.
Actually i am a partner , and i am just like you , i really dont know certanlly what will be the road of compiere, We will have a partner meeting in october to know what is the new compiere's business model.
I think that Jorg has the right to change his strategy ,He owns Compiere Inc. but I like a partner can agree or disagree with the new policies, i have the right too.
My main issue to solve , is to offer to my customers a high quality product as collin says, and i think this is what everybody wants.
I dont know what will happen with compiere in the future , i am worried just like you , for the road that compiere takes in the future. But if everybody achieve this , we wll have a version (253b) good enough to work with.
I think that in this moment we need to be prudents and wait to compiere says which will be his strategy. In the Other hand , mean while we can work in the communty union, collect everybodies job (as a community), and prepare a tool that allow us to integrate new jobs , and a migration tool.
The possibles scenarios of Compiere's strategy can be:
1.- The Open source strategy continue, will be necessary eliminate the disavantages in his model, how ?, i dont know.
2.- If the Strategy goes to not be open source, then the community could take their own road.
What do you think about this proposal?
regards
Victor Perez
CEO
www.e-evolution.com
In this discusiion i can see one thing in common , Everybody requieres a stable version, and a place where the community can work.
I am about to release my version 253b of Kompiere Manufacturing , this version has a lot of patches, that i have fixed, also i have some other new functionallity, that can be usefull to the community(MRP, CRP, Manufacturing Order, Shop floor control, subcontrating, cash flow, PostgreSQL, etc),
We can integrate everybody job in this project (http://sourceforge.net/projects/cmpcs), the patches of trifon (253b) and red1 (253a), and if somebody else has jobs of their own, we can integrate them too. And at the end have a Compiere that collects the community job, as a result we will achieve the main goal of having a stable compiere with extra functionality.
Actually i am a partner , and i am just like you , i really dont know certanlly what will be the road of compiere, We will have a partner meeting in october to know what is the new compiere's business model.
I think that Jorg has the right to change his strategy ,He owns Compiere Inc. but I like a partner can agree or disagree with the new policies, i have the right too.
My main issue to solve , is to offer to my customers a high quality product as collin says, and i think this is what everybody wants.
I dont know what will happen with compiere in the future , i am worried just like you , for the road that compiere takes in the future. But if everybody achieve this , we wll have a version (253b) good enough to work with.
I think that in this moment we need to be prudents and wait to compiere says which will be his strategy. In the Other hand , mean while we can work in the communty union, collect everybodies job (as a community), and prepare a tool that allow us to integrate new jobs , and a migration tool.
The possibles scenarios of Compiere's strategy can be:
1.- The Open source strategy continue, will be necessary eliminate the disavantages in his model, how ?, i dont know.
2.- If the Strategy goes to not be open source, then the community could take their own road.
What do you think about this proposal?
regards
Victor Perez
CEO
www.e-evolution.com
- vpj-cd
- Posts: 24
- Joined: Fri Jan 21, 2005 12:21 am
- Location: Mexico
by rvergara » Fri Sep 08, 2006 3:52 am
In the best tradition of a bazaar we have been finding common ground here.
I agree on using either ComXe or CMPCPS projects in SF to support our effort.
Totally agree on focus in the very short time in getting 2.5.3 stable and develop a working migration tool.
From my part, my company (www.ofbconsulting.com) has performed a lot of testing and fixing of 2.5.3b and the debugged version is running in production in several sites in Chile. I am sure it will be relatively easy to integrate those fixes into the new project if they are considered relevant.
I have also integrated some of the FA project development from Rob in this version and added some usability improvement, although FA is not in the proposed short term scope I would gladly integrate this work if and when the new project leadership agrees.
Can I suggest that we assign a temporary project leader role to Red1 so he can take the first baby steps in order to get the ball rolling? we can decide on project structure on a further stage.
If in agreement, Red can initiate on deciding what SF project to use or create a new one. He will also may help us on creating a few new forums streams or wikis (better I believe) to start working on the project charter, short term scope, rules of engagement and technology direction.
Very happy to be back in a Bazaar....
Regards
Ramiro
I agree on using either ComXe or CMPCPS projects in SF to support our effort.
Totally agree on focus in the very short time in getting 2.5.3 stable and develop a working migration tool.
From my part, my company (www.ofbconsulting.com) has performed a lot of testing and fixing of 2.5.3b and the debugged version is running in production in several sites in Chile. I am sure it will be relatively easy to integrate those fixes into the new project if they are considered relevant.
I have also integrated some of the FA project development from Rob in this version and added some usability improvement, although FA is not in the proposed short term scope I would gladly integrate this work if and when the new project leadership agrees.
Can I suggest that we assign a temporary project leader role to Red1 so he can take the first baby steps in order to get the ball rolling? we can decide on project structure on a further stage.
If in agreement, Red can initiate on deciding what SF project to use or create a new one. He will also may help us on creating a few new forums streams or wikis (better I believe) to start working on the project charter, short term scope, rules of engagement and technology direction.
Very happy to be back in a Bazaar....
Regards
Ramiro
- rvergara
- Posts: 47
- Joined: Sat Sep 02, 2006 7:47 pm
- Location: Santiago, Chile
by croo » Fri Sep 08, 2006 4:50 am
Following pseudonimo's question on whether the Compiere Public License will allow a fork I've been browsing it...
After a quick look at the license in my 253a version I noticed at the top is a clause which states
“III. Compiere and logo.
This License does not grant any rights to use the trademarks "Compiere'', the "Compiere'' logo even if such marks are included in the Original Code or Modifications. You cannot remove the Logo and replace it with your own unless explicitly granted.”
Which seems to mean we cannot use the logo or name without permission, but at the same time we cannot remove the logo ... which on the face of it seems to be a bit of an impasse. If we can't remove it we need permission, but would Inc give permission to fork??
Also, there are a couple of places in the code itself (as comments) that state “removing the Compiere logo is a violation of the license”; Compiere.java, WebEnv.java, Alogin.java (& in somewhere in the printlayout code which I can't find right now) are some examples ...
What's also VERY interesting is that the license on http://www.compiere.org/license.html does NOT specify this restriction, and also the license in the 253b versions I have here seems NOT to have this restriction either!? It does look like something Compiere would NOT want to remove? And the code still has the comments stating it's a violation of the license!
Actually the 253b license looks like (at first glance anyway) a standard Mozilla License; whereas the 253a has a whole raft of Amendments before the Mozilla License!?
Both a titled the Compiere Public License 1.1
Have I mistakenly looked at the wrong thing??? I'm looking at the install/Compiere2/license.html
Anyone have any ideas?
I guess since we are talking about forking from 253b, we are ok as it's license does not have the restrictions. But was it purposely relaxed and does it matter if it was or wasn't?
re: ComXE or CMPCPS
In theory at least, if it was stable I would prefer a postgreSQL version to an Oracle version But I imagine it would be a big problem for any currently installed systems? I assume there are currently no tools to convert from Oracle to postgreSQL? Or does cmpcps run on postgresql AND oracle? I guess all that kind of information is available at the project link you sent ... I'll have a read!
re: Red1 as project leader
I'm happy with that
colin
After a quick look at the license in my 253a version I noticed at the top is a clause which states
“III. Compiere and logo.
This License does not grant any rights to use the trademarks "Compiere'', the "Compiere'' logo even if such marks are included in the Original Code or Modifications. You cannot remove the Logo and replace it with your own unless explicitly granted.”
Which seems to mean we cannot use the logo or name without permission, but at the same time we cannot remove the logo ... which on the face of it seems to be a bit of an impasse. If we can't remove it we need permission, but would Inc give permission to fork??
Also, there are a couple of places in the code itself (as comments) that state “removing the Compiere logo is a violation of the license”; Compiere.java, WebEnv.java, Alogin.java (& in somewhere in the printlayout code which I can't find right now) are some examples ...
What's also VERY interesting is that the license on http://www.compiere.org/license.html does NOT specify this restriction, and also the license in the 253b versions I have here seems NOT to have this restriction either!? It does look like something Compiere would NOT want to remove? And the code still has the comments stating it's a violation of the license!
Actually the 253b license looks like (at first glance anyway) a standard Mozilla License; whereas the 253a has a whole raft of Amendments before the Mozilla License!?
Both a titled the Compiere Public License 1.1
Have I mistakenly looked at the wrong thing??? I'm looking at the install/Compiere2/license.html
Anyone have any ideas?
I guess since we are talking about forking from 253b, we are ok as it's license does not have the restrictions. But was it purposely relaxed and does it matter if it was or wasn't?
re: ComXE or CMPCPS
In theory at least, if it was stable I would prefer a postgreSQL version to an Oracle version
But I imagine it would be a big problem for any currently installed systems? I assume there are currently no tools to convert from Oracle to postgreSQL? Or does cmpcps run on postgresql AND oracle? I guess all that kind of information is available at the project link you sent ... I'll have a read!
re: Red1 as project leader
I'm happy with that
colin
Last edited by croo on Fri Sep 08, 2006 3:13 pm, edited 1 time in total.
- croo
- Regular
- Posts: 89
- Joined: Sat Sep 02, 2006 6:53 pm
- Location: Ireland
by vpj-cd » Fri Sep 08, 2006 6:35 am
Hi Colin,
About your question if Kompiere (CMPCS) works with oracle and PostgreSQL , the answer is yes, you can read a little more about it in http://www.e-evolution.com.mx/kompiere/
The Oracle version is stable and in postgre SQL is about 95% stable , we are preparing the last details to release the 253b.
Regards
About your question if Kompiere (CMPCS) works with oracle and PostgreSQL , the answer is yes, you can read a little more about it in http://www.e-evolution.com.mx/kompiere/
The Oracle version is stable and in postgre SQL is about 95% stable , we are preparing the last details to release the 253b.
Regards
- vpj-cd
- Posts: 24
- Joined: Fri Jan 21, 2005 12:21 am
- Location: Mexico
115 posts
• Page 1 of 5 • 1, 2, 3, 4, 5
Who is online
Users browsing this forum: No registered users and 1 guest