From Flames To Fork, Comes Freedom

This is in response to Chuck Boecking's State of the Union piece. Before this, a bit of the history of 'State Of The Union' addresses. It is a USA tradition where the head of the state, namely the President gives an annual address to the people in the country. It is like reporting to the electorate where the President puts out on how everything has been going on for the past one year. Thus Chuck does a good job there except for some places and this is where, I stop the buck to point out those places:

What is missing is business logic improvements.

That is simply not true. What is appearing are lots of new plugins that does new functionality and features in fully decoupled manner: http://wiki.idempiere.org/en/Category:Available_Plugins. The whole idea of iDempiere (ADempiere+OSGi) is to allow separation of business logic from core technical framework in a pure Object-oriented principle of Separation Of Concern, much like how the Eclipse IDE is designed as the forerunner huge app capitalising on the OSGi promise to extend in a modular and pluggable fashion. Now those further ever-changing, complex, radical and often localised or vertical needs can explode without disrupting and destabilising the core.

A stable and backward compatible versioning of the core is so vital that fueled countless wars in the past that today been so silent and peaceful has led many to take for granted it is that simple or even meaningless in an ERP.

Otherwise it would have cost more cross impact and maintenance in the long run. More importantly, such changes are growing independently, which is the ideal state of the software. Now quite everyone can live with iDempiere without bottlenecked by any gatekeepers or core maintainers. Becoming a silent humming architecture that relays an engine interface of Declared Services, most magic begin to happen outside and quickly.

And this is not the perfect state of the union. We have not remove all logic from the core yet. This is a work in progress requesting others to send us freedom fighters. Meanwhile we live with bomb threats.

Chuck then made a 2-bullet loaded statement,

This question became painfully obvious to me when a former SAP integrator can [sic] to me with an Invoice Price Variance improvement. The situation was clearly outlined. The documentation included how SAP performed the transaction. When we approached Carlos, he turned down the work. The response was there there was no time. At some level this makes sense – he is the steward of iDempiere. He has much to do, and he and his family are practically the only people who can directly commit to iDempiere.

He then continue by disparaging even the fact that Thomas Bayen done a big effort in bringing Carlos' son, Diego Ruiz over to work under him and get his own contributions out, which Chuck puts

it struck a sour chord with many of the attendees.

Well, Chuck has clearly misread the constitution and our best practice. I also see what else he did there.

Now the noble act of Thomas Bayen in supporting Diego Ruiz son of Carlos Ruiz is seen as a nepotistic act. The fact of the matter is Thomas contributions are also in plugins and not necessarily core. I know Carlos Ruiz very deeply, as a co-trustee and holder of the keys to the empire, he plays the role of guardian of the core even to the extent of severing his own blood line. He will not approve a piece of code that even has his own Latino wordings in it. I need not bring up all the previous holy wars and war crimes that occur in our history. (Just read how each line of code gets into our core here http://jira.idempiere.com.)

Many of Carlos actions (rather than words) are not taken into account and portrayed correctly. He accepts and rejects changes based on Linus' Circle of Trust which comprises not just Heng Sin but also Hiep LQ, both non Ruiz family members. And the failure to mention Hiep is very glaring as ironically Hiep's vast contribution includes much business logic fixing. Why didn't Chuck go to the Circle of Trust next of kin? Hiep is a newcomer outsider who rose very fast entirely based on merit, for not just the sheer amount of core fixes he brought to the table, but importantly his work ethics of been a good responsible maintainer unlike Trifon who will say, "pay the bad part of my code and i will fix it".

It is fitting to mention that Hiep rose even more dramatically after a visit from me to his North Vietnam abode in 2014. I merely kudoed him on his brilliant work and told him not to worry about his lack of English as i will assist in translation. But look here. Even I am not in the Circle of Trust. I know my limitations, my rightful place in the bazaar and my language. (You can read more of Linus way here: http://www.pcworld.com/article/149418/l ... oject.html)

This is to say also that Diego Ruiz is not in Carlos Ruiz's Circle of Trust. In the top ten names in the About Box when you launch iDempiere you won't see Diego Ruiz name there but Hiep LQ and even old enemies, Teo Sarca and what more Trifon Trifonov, respecting credit of past work done.

That is the first bullet. Now the second bullet. To say Carlos did not have the time is not the complete answer Carlos gave. Since he is not the Secretary of State dictated by a secret CIA mail server, here is the complete Carlos email on record. I have redacted out commercial parties who are not within our bazaar family:

Fecha: Mon, 29 Feb 2016 19:51:32 +0100
De: Carlos Antonio Ruiz Gomez <carg67@gmail.com>
A: Chuck Boecking <chuck@chuboe.com>

Hi Chuck,
Yes, I had a long chat with Deepak before answering the email.

The main reason is my lack of time, my availability is very little these days, I'm basically fully booked with projects in <sponsor redacted>.

Also, I thought that if the development is managed by <sponsor redacted> then it can be Heng Sin or me who does the work - Heng Sin has good knowledge about costing, and also about how SAP works that.

But, my main concern, and what took me long time to explain to Deepak is the mix of things on the request.

<name redacted> asked for some development work - and that's fine - he can hire anyone to do that work - Deepak can do it, Heng Sin can do it, I recommended <sponsor redacted> because there Heng Sin and I can review both.

But, this part
"you may also want to consider delegating them to any of your team members so long as we can get these changes into the core"
is what is not clear to me:
integrating into core is a different issue, I know that if somebody hires me or Heng Sin, is almost guaranteed that things will go to core, but I prefer to think that developing things and integrating into core are different things, and require different sponsorship.
I mean, hiring me for a development is just that, paid work for developer. Integrating into core must be done more like sponsoring my time to apply peer review, QA, and that must not be driven per ticket, or per sponsor, there is a queue (everyday longer because of my lack of time) which I must review based on some community criteria, and not driven by sponsor criteria.

Maybe I'm too picky about separating those two tasks, but you must remember that in that adempiere community there was one jerk that falsely accused me about charging $$ for allowing things to go into core. That was a big discussion that ended with that guy retracting and apologizing (falsely too).

Also, I have talked with Deepak and others several times about this, but I think the message has not been understood.

I said during the conference that community must think about sponsoring my peer review and QA work - because there is a bottleneck there - and community must find ways to solve it.
Well, seems like people understood that I was asking for money. And that's not what I was trying.
My message wanted to say more like:
I'm usually too busy (and glad that translates to make money successfully) - but that creates a bottleneck in iDempiere project.
IMHO that bottleneck can be solved in two ways - or community find a way to pay some of my time so I can have some committed hours (I would be glad to do it - but I can't afford too much for free as I'm doing now).
Or community finds another guy to replace me and do that work.

I think after the conference the situation has become worst - my movement to Germany, new projects, etc - have affected my dedication.

Anyways, I think I'm maybe overexplaining
But please understand me, I'm a bit disappointed because during the conference there were two committees created to find a solution to the problem - sponsorship initiative is receiving regularly almost $1.000 monthly (some money specifically saying that is for the bottleneck), but nothing comes out.

Regards,

Carlos Ruiz


El 29/02/16 a las 18:08, Chuck Boecking escribió:
> Hi Carlos,
>
> I am surprised that you turned this one down. I thought you would appreciate this one:
>
> Intelligent end user
> Good documentation (including SAP reference)
> Beginnings of an acceptance test
>
> <name redacted> will probably push iDempiere further on accounting than any other user. They are a large corporation with many divisions. I had recommended that <name redacted> go directly to you on this ticket.
>
> Do you mind sharing why you passed?
>
> Also, <name redacted>'s Jira account does not have the ability to assign a ticket to a user. Is that a recent policy change for new users?
>
> Thank you for your time and consideration!
>
> Regards,
>
>
> Chuck Boecking
>
> ---------- Forwarded message ----------
> From: Carlos Antonio Ruiz Gomez <carlos.ruiz@globalqss.com>
> Date: Sat, Feb 27, 2016 at 9:39 AM
> Subject: Re: Estimate Sponsoring of 2 changes in iDempiere
> To: <name redacted>
> Cc: Deepak Pansheriya <deepak@logilite.com>, Chuck Boecking <chuck@chuboe.com>
>
>
> Hi <name redacted>,
>
> There are two different issues about your request that I would like to treat separately:
>
>
> 1 - development of IDEMPIERE-3040 (seems like a new feature) and fixing IDEMPIERE-3014 (seems like a bug)
>
> This can be hired to any iDempiere developer, thanks for taking me into account, but in this case I would prefer you to hire the work with <name redacted> - and there we decide how and who does it.
>
> If you want this approach I can put you in contact with the person to do the proper exploration.
>
>
> 2 - integration into core - this work is constantly made by me with many tickets that are in queue for peer review.
> If you want to sponsor this kind of work I suggest you to do it monthly through the sponsors initiative raised by Chuck:
> http://www.idempiere.org/sponsors
>
>
> Regards,
>
> Carlos Ruiz
>
>
> El 27/02/16 a las 12:25, ,<name redacted> escribió:
>>
>> Hi Carlos,
>>
>> I’ve been discussing 2 issues with Chuck, Deepak and the ERP academy and as a larger organization we would require 2 bug fixes/changes fairly urgently, preferably in the core so as to maintain upgradability.
>>
>> I’ve been working with ERP SAP/ORACLE solutions for over 20 years and I consider the proposed changes, especially 1. IVP for Average PO, as common industry and accounting practices/standards.
>>
>> I logged 2 JIRA issues but I don’t have the necessary authorizations to select you as an Assignee.
>>
>> Here are the 2 JIRA tickets I opened:
>>
>> 1. Invoice Price Variations for Average PO costing method: https://idempiere.atlassian.net/browse/IDEMPIERE-3040
>>
>> 2. Landed Costs - Wrong GL posting involving multiple foreign currencies: https://idempiere.atlassian.net/browse/IDEMPIERE-3014
>>
>> I wanted to request you to scrutinize these 2 proposed bug fixes/change requests and provide an estimate for the required changes in the core, which our company might want to sponsor.
>>
>> If you agree with the changes you may also want to consider delegating them to any of your team members so long as we can get these changes into the core.
>>
>> I’m also copying Chuck and Deepak on this mail because the three of us had extensive discussions about these issues, in particular issue 1, IPV and Average PO costing.
>>
>> Deepak will also try to get in touch with you on Monday, 29th February 2016.
>>
>> Please let me know what you think,
>>
>> <name redacted>

In summary, what Carlos explained above is politically correct. Paid work has the choice of few others within the circle. Getting into core has to go through a peer review process which Carlos himself is also subjected to. I believe the community is glad to read this too. The question of a bigger Circle of Trust needs qualified volunteers. Otherwise Carlos free time is limited. Or pay him for getting the peer review done. He suggested via his sponsor company which has the other qualified peer to do the review. Only real experienced software people understand the importance of this eco-system and economics. Others bypass this or allow no options or freedom to decouple that end up poorer. That also explains why iDempiere beats the rest of the pack to the 2015 InfoWorld BOSSIE Award.

I maybe politically incorrect to put this out but the alternative of letting Carlos looking like bad Donald is unfair. Here I am just humbly doing my sometimes unpleasant job. I am not counter punching anyone who punches the dream team. Chuck is one of our big and famous name and contributor. I really admire the research and effort he puts into his State of the Union address. But perception and correct understanding is important to ensure the health of the project. And it cannot be corrected in short snips but in this rather long piece to give Carlos Ruiz, Thomas Bayen and Diego Ruiz the rightful benefit of the doubt.

Thanks red1 for bringing clarity to these new false statements.

In adempiere community I was attacked in so many ways, and that was my first deep involvement in an open source project, so I started to think that's the way how it is.

But now, on iDempiere I understand there was a big flaw on that abandoned project, and I like the way we fixed it on iDempiere.

So, some years without receiving false accusations, but here we go, people again raising false statements, accusing me this time of nepotism. Don't worry, we're used, red1 has been accused of nazi, I've been slandered in worst ways.
The difference is that in this project it doesn't do the same damage that in the old project, we have the tools to control poison and remove it when needed.

I find Chuck's blog very disrespectful, but instead of an apology he's surprised that it was taken as an attack.
So, seems like Chuck thinks nepotism is something to take lightly, so I just say thanks and smile.

Well, something I learned from all those mini-wars from adempiere is that they're not worthy. I'll simply stop any communication with Chuck until he apologizes (in the same media) and fix his false statements.
Up to him, if he doesn't want to, no big worries, this project is set up to be on top of those kind of attacks, we simply move ahead and forget about the poison (there are techniques to remove poison from the project - books written about that - but I still tend to think that Chuck is just being naive, so let's give him the benefit of doubt).

There can be valid concerns on Chuck's blog, most of them are simple to answer, we could re-explain, those concerns are not new, we set up this project since the beginning to attend those concerns.
But I'm sorry the potentially valid points that can deserve an answer are totally invalidated by the false accusations, so I pass, I'm not going to entertain a jerk post.
______

And I'm sorry to read that Deepak added some wood to the fire:

http://www.chuckboecking.com/idempiere- ... omment-179

This concerned raised in conference and Carlos has explained the circle of trust approach. And community ask to have not his son in his center of trust.
While this is true that Carlos’ son may have committed some mistake with his first code, I don’t think it will be continue as I know he is another geniuos champ we need in project. So he can be in circle of trust for carlos.

Probably Deepak was in another conference, in the conference that I attended nobody raised such concern about Diego.
I don't know what is Deepak talking about - main contribution from Diego is the kanban plugin, which has been widely embraced by community, if there are mistakes there - I'm sure Diego will appreciate to be pointed to, but until now the feedback has been highly positive.

And I think it was clear in the conference that I said that my circle of trust is a triangle, Heng Sin and Hiep.
Even Thomas has asked me why Diego is not in my circle of trust - I said "not yet, he's learning".
I don't have any problem about Diego being there when he deserves it, he's just another developer and I need to look at his code from the same technical perspective as anyone.
NOTE this is to say that community cannot imply - and I will not allow - that there are forbidden developers to be in my circle of trust just because they are my relatives. If they are good developers and contributors, it will be, period.

So, in the conference was clear my triangle of trust: Heng Sin and Hiep, and that I wanted to grow the edges of this polygon to be at least a pentagon.
Somebody asked me if Deepak was good, and I said to the attendants that Deepak was good developer, but my circle of trust keep being a triangle with Heng Sin and Hiep.
Later I was rudely questioned by Chuck why Deepak was not in my circle of trust, and I answered him two things:
1) wait Deepak to come back (he was in the restroom when Chuck raised the question)
2) when Deepak returned I said them that Deepak is sloppy about reviewing collaterals, he fixes a problem and usually open two new problems. There were others involved in such conversation that can confirm it.

Having said that, what I keep repeating to the community is that there is a bottleneck (what a discovery!)
And I'm sorry to be busy.
I work in my free time on this peer review and development tasks, this is about HOBBY time, for me is FUNNY.
What do you do with a hobby when it's not funny? Simply, you abandon the hobby.
Reviewing code from Heng Sin and Hiep is funny and motivating for me, I like to do it, sometimes is a technical challenge, many times I learn from them.
But I'm going to follow Linus advice blatantly, say the technical stuff clearly: reviewing code from Deepak for example, is not funny, it takes out all the fun when you find sloppy code, or sloppy bugs and you iterate and iterate and iterate and they are not solved.

This ticket is a good example: https://idempiere.atlassian.net/browse/IDEMPIERE-3078
Hey, this is open source, everybody is looking your code, not just me, there are many eyeballs, introducing code that references a column that doesn't exists is a BIG NO NO - even if it doesn't break anything. It is sloppy code, and I would expect the developer causing that to say "sorry, I'll fix it ASAP" - but not an answer like "show me where is failing". That's what put a developer out of my circle of trust.
______

OK, at the end of his answer Deepak makes a proposal, I appreciate it, at least he's doing more than the rest of community that just see the bottleneck silently and complain about my lack of commitment.

Sorry to say, that proposal doesn't work for me, I require independence on the project management and I cannot accept the project to be driven by sponsors, that's my condition.
Accepting that proposal means that people with more money could skip the queue, try to force pushing things that are potentially bad for the core, or breaking the architecture, etc.

That doesn't mean that you cannot find another person that accepts such condition, open a fork and try another set up of the project. That's how open source works. Is simply that this proposal doesn't work for me.

I repeat (please re-read the email that I sent to Chuck)
I'M NOT SAYING THAT I'M IN URGENT NEED OF MONEY.
I'm asking community to realize there is a bottleneck on my peer review queue and if there is interest on community to solve it, then please find ways to solve it.
I have said there can be two ways, but you can be creative and find more:
Option 1 - pay for that work time, so I can devote more than hobby time, and I can devote time to review those tickets that are not funny to review
. I'll be happy to step aside for some hours from my paid projects time, and dedicate to peer review work here.
Option 2 - find somebody else to do the job

For me is simple, of course there is the inactivity option, that's also on the table, and that's what community have chosen until now, just inertia:
Option 3 - just let the project flow at the speed of Carlos's hobby time

But please understand, if community wants to keep working on this third option, then I'll keep choosing which tickets to review according to my taste, probably I'll review those that are interesting for me, or those that will give me some fun/challenge/learning.

Decision is on community.

Regards,

Carlos Ruiz

I didn't know that i be on Carlos's circle. but i so pride on it.
personal i can well live with current situation of idempiere, but i get more interest when it go faster.
i want to be a part of solution than problem, so I bellow is my idea.

1. for each ticket (or group relative ticket), people (reporter, developer, tester...) have to explain clear about it.
when you get a issue, don't just report it. try to isolate condition to get it, try to figure out test case to get it.
it help developer can redo to get where to fix, test his patch.
when you develop (fix, improve, new feature) explain your step (not need so detail just outline with main step), tell about what you already test, test case you can figure out, area your code can effect, so other can easy join to review, test, share work load.
when you test it, document about test case you do, so it case re-use for later.

2. people who interest at ticket, can request build server with this ticket for test (i can take this task to temp merger ticket to build)

two step will help refine patch before Carlos review to merger to core, so save his time. it also help you show your responsibility, and get more people can join to resolver issue.

3. before think about merger to core, you can run in your environment to make sure your solution work without issue. of course this stuff don't avoid you immediately summit patch and discuss about it.

for long time ago i follow step 1, for now i a bit follow step 1 and strict follow step 3

Deepak skyped me for a long 1 and the half hours explaining his statement and convinced me he worded his reply wrongly as quoted above. I requested him to make that apology direct to Carlos Ruiz, be ready to be smacked on the head, then move on.
I also like to explain when during the skype session, Deepak showed me commits done by Diego Ruiz as to mean Diego has commit rights and therefore due to special treatment. I told him abit about our history but i like to now give a fuller rendering and on the record.

1. Commit rights does not mean it is a right or privilege. This was discussed heavily throughout our history since September 2006 when we forked. It was even discussed in Berlin in 2009 under a dedicated presentation by Carlos Ruiz explaining the damage done by wrongful commits from Libero project costing three years of instability to the trunk.

2. We then collectively (with Libero team included) agreed to a two tier review system. I was in the 2nd tier, but the commits still do not go to a clear veto control of a lead maintainer. I.e. if the lead maintainer was to revert, another lesser member can question him and this caused the same flame again.

3. In the end Carlos withdrew from acting as Technical Leader and lead maintainer but this created a crisis in which Kai Schaeffer then proposed a new approach where Carlos is to be elected formally, paid for his maintainer role. Though Carlos is not about the money, he finally agreed.

4. You guessed it, the flames continue. And this time Carlos allowed his tenure to lapse without seeking reelection. I also withdrew after consulting with Heng Sin privately.

5. Heng Sin gave me some personal advice on how FOSS projects are run elsewhere. 'As a direct commiter, if you break once, you are warned, and you should not break it again. If you break it one more time, expect to be removed by the leader. And the leader must be firm.' It is a benevolent dictatorship. We never do that. I mean i as the overall leader did not enforce that to the peers. I kept the democratic card and even try to put Carlos in the court under trial as we also instituted a 5 member petition to question the lead maintainer.

6. But Heng Sin in such instances withdrew from the project and i always regard that as severe crisis and desist to institute further democratic reform as it is meaningless if either these two vanguard of our code withdrew.

7. Kai Schaeffer met me in Kuala Lumpur on his own during one of the crisis and remarked that ADeV will take over, putting out a fund and advertising for developer while remarking Hengsin is just a developer.

8. When the ADeV team took over, reviews were bad, and even credit copyright statements were not checked resulting in cases where Carlos name was removed from his own code. Another flaming war ensued as the other side refused to revert and even wrote to FSF and ZK projects seeking for judgement that they are right.

9. While I was in Austria end of 2011, Carlos, thru Skype, gave me his most severe stand on the whole matter. He will closed up completely to avoid further abuse of his work as peers are not defending him. I posted a no-confident vote against ADeV admin in SF forum and won but felt this is a repeat of 2009 all over again. I then requested Thomas Bayen to pay for my trip to Bogota to sit down with Carlos for a final solution.

10. This resulted in the permanent split and iDempiere was born this time in absolute benevolent dictatorship under Carlos and Heng Sin. This was the perfect solution that led us to fantastic heights, scored awards and still counting, while the rest began to wane and decay.

11. Krefeld, home of Thomas Bayen then became our new base with 2 successful iDempiere conferences.

12. Chuck and Deepak both attended last year's conference, raised this issue, fully explained by Carlos, agreed with committee, but you guessed it, no one else done anything.

13. Then came Chuck's so called State of the Union address.

In summing up, there is a paramount leader in the project and we all know who he is. He is a benevolent dictator with his circle of trust which whoever commits can rest assured he has the blessing from a review process as proven in the mud of history. The leader himself always seek out peers to review his own work.

Linus Torvalds knew this issue too well, and gave a long talk explaining why he created GIT. We knew this is it, and became just a GIT (Mercurial) clone with a community gravitating around it. Others are free to fork and invited to do so. All commercial dreams have to be in the form of distros from any fork.

I have to reiterate here that many do not understand how FOSS projects are actually done and which are marbles and which are gems. I suggest they go read the manuals and books on it before they approach this subject further. Least of all do not come back trying to give us some advice when you had no idea in the previous one.

Fortunately, we have instituted fully Linus' GIT and Circle Of Trust convention where we mutually agreed to disallow any more flame or poison to disrupt this most successful run of the Compiere forks from beginning 2012 till now. Among our convention is not to answer inflammable posts outside this rant forum. Any encroachment of such into our google group will be immediately banned by us. As Linus advised, it is better to be blunt than be sorry later for a big mess.

Redhuan, unfortunately I have not seen the public apology that Deepak promised to deliver.
As I told you I think Deepak was maliciously trying to mislead you about that. Let me explain why:

What Deepak showed to you is something like this, but in eclipse:
https://bitbucket.org/idempiere/idempiere/commits/all?search=author(druiz)

And I think he was trying to intentionally mislead you, because Deepak knows very well how that developer name ends there, if that's the case then Deepak's also would have commit rights, as his name search shows:
https://bitbucket.org/idempiere/idempiere/commits/all?search=author(dpansheriya)+or+author(deepak)+or+author(logilite)

And Deepak is very clear about how his name ends in the repository even when he doesn't have commit permissions, one example here:
Ticket https://idempiere.atlassian.net/browse/IDEMPIERE-2675
Deepak adds into the ticket this patch: https://idempiere.atlassian.net/secure/ ... 75_1.patch

If you see the patch it comes with the developer assigned:
# User dpansheriya

And as I'm a big fan of credit attribution, then I integrate the commit as sent by the developer (or assigning developer name with his permission) whenever possible:
https://bitbucket.org/idempiere/idempie ... 8911dd3c3d

That's how it works and mostly all developers know about that and send the patches with their name on it.

Regards,

Carlos Ruiz

Yes, this is what people do not get about us as opposed to the other project. There people can hide code and credit or even steal them but are defiant maintaining they are right and we are wrong. Here, we are practicing the opposite and then people think all sorts of things without asking for clarification. The onus or burden of argument should be on the one making those allegations, not us who are making something work really well. If someone says your project or management has an issue, they should prove it with fair analysis and comparisons with alternatives they have. Otherwise they been unfair to others.

What if i make allegations against his 'pay for training club that hides code unless you pay for the membership first''? Or course he will not see my point of view. Thus i do not make such allegations directly and openly but in principle citing proper references. Anyway i do not see his code as important. Your team or my team can make better if we want but we were playing fair and letting everyone into the game or be part of the family.

If they wish to say 'his family are practically the only people who can directly commit to iDempiere', then give the proof instead of slandering publicly. And they do not want to apologize for it, but expect us to apologize for defending ourselves. This breaks down communal spirit and respect. Like Linus Torvalds once said to take on a flame starter, 'Bring em on'.