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