Wednesday 19 June 2013

Evidence Supporting My Statement of Facts Around My Dispute with Tim Schofield

Evidence Supporting my Statement of Facts Around My Dispute with Tim Schofield

The Fixed Assets Module Correspondence

I have pasted below some of the correspondence around the fixed assets which caused the initial rift. 

The discussion was off list because I was trying to protect Tim's reputation... we are long past that.
 
 
From - Mon Oct 18 21:59:36 2010
X-Mozilla-Status: 0003
X-Mozilla-Status2: 00800000
X-Mozilla-Keys:                                                                                 
Message-ID: <4CBC1A88.8040804@logicworks.co.nz>
Date: Mon, 18 Oct 2010 21:59:36 +1200
From: Phil Daintree <phil@logicworks.co.nz>
Reply-To: phil@logicworks.co.nz
Organization: Logic Works Ltd
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1
MIME-Version: 1.0
To: Tim Schofield <tim@weberpafrica.com>
Subject: Fixed Assets
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Tim,

I have not really experimented before with the Fixed Asset code and just 
had a look at the FixedAssetItem.php script - it seems as though it is 
not doing anything with the asset tables it is trying to add to 
stockmaster - I am wondering if this is a rogue script that is not where 
it should be.

Does fixed assets work at all?

Phil

 
From - Sun Nov 14 18:32:50 2010
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00800000
X-Mozilla-Keys:                                                                                 
Message-ID: <4CDF828F.4050908@logicworks.co.nz>
Date: Sun, 14 Nov 2010 18:32:47 +1200
From: Phil Daintree <phil@logicworks.co.nz>
Reply-To: phil@logicworks.co.nz
Organization: Logic Works Ltd
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1
MIME-Version: 1.0
To: For the general discussion of webERP project <web-erp-users@lists.sourceforge.net>
Subject: Fixed Asset Module - Warning
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I recently released a new version 4.0RC1 - including a new fixed asset 
module. Unfortunately, I have to advise that the fixed asset module has 
some problems and I would warn those considering using it not to.

I am working on fixing the fixed assets module for a future release. 
Apologies to those who have been inconvenienced.

Phil

 
 
 
From - Sun Nov 14 20:23:42 2010
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00800000
X-Mozilla-Keys:                                                                                 
Message-ID: <4CDF9C8B.5010407@logicworks.co.nz>
Date: Sun, 14 Nov 2010 20:23:39 +1200
From: Phil Daintree <phil@logicworks.co.nz>
Reply-To: phil@logicworks.co.nz
Organization: Logic Works Ltd
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1
MIME-Version: 1.0
To: Tim Schofield <tim@weberpafrica.com>
Subject: Fixed Assets
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Tim,

I hope the resetting of the ankle is going to plan and the recuperation 
of being once again confined to a chair/crutches/cast not driving you 
too mad.

In relation to this Fixed Asset stuff I would like to have a chat when 
you are up to it Tim. I think I found your Skype address tim.schofield3 ???

Phil

 
 
 
From - Sun Nov 21 22:18:17 2010
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00800000
X-Mozilla-Keys:                                                                                 
Message-ID: <4CE8F1E7.2010000@logicworks.co.nz>
Date: Sun, 21 Nov 2010 22:18:15 +1200
From: Phil Daintree <phil@logicworks.co.nz>
Reply-To: phil@logicworks.co.nz
Organization: Logic Works Ltd
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1
MIME-Version: 1.0
To: Tim Schofield <tim@weberpafrica.com>
Subject: Re: [WebERP-developers] Hacks should not be in webERP trunk - theFixed
 Assets Module!
References: <4CDF54C3.4000104@logicworks.co.nz> <AANLkTinJYZNKii_RN6RyLua5vp9E7h8_=-+_JESjnCmz@mail.gmail.com> <4CE0EC06.50705@logicworks.co.nz> <AANLkTi=UKKeYOaRfSG-LNm7FCgxmz0XMF_V41RFvk2v0@mail.gmail.com> <1099472191-1289934288-cardhu_decombobulator_blackberry.rim.net-1825057942-@b12.c1.bise3.blackberry> <AANLkTikqUvOBrhCkBoxvDXTwdAkuue=cKXwZAYnaE54z@mail.gmail.com>
In-Reply-To: <AANLkTikqUvOBrhCkBoxvDXTwdAkuue=cKXwZAYnaE54z@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Tim,

Just reworking some of the scripts for style as I work through the fixed 
asset changes.

Is it right to have a $UOM property of the PurchOrder Class and a $uom 
property?? Forgive the silly questions, I've not really understood the 
code used in all the purchasing changes.

I notice quite a bit of lower case variable naming which is confusing 
for me as I have used CamelCase everywhere else for variable names.

What are the variables nw? and gw?

Sorry to re-litigate this fixed asset stuff but have been thinking about 
how you could be offended by the word "hack"?

I used this thinking it meant scripts that was cobbled together from 
existing scripts and the variable names not changed and still including 
large chunks of redundant code relevant to the original script but not 
relevant to the new functionality...

Not sure why you think that was an unfair description?

I am still some way away from completing the fixed asset stuff - 
although I have put quite a few hours in this weekend. No doubt it will 
be next weekend before I can give it another nudge.

I do hope you understand about the standards I am insisting upon. I had 
previously thought that you concurred with these and that is why I was 
surprised (and upset) by that this code was in the trunk.

Phil

On 18/11/10 19:14, Tim Schofield wrote:
> Hi Phil,
>
> Ok, I think the stockmaster table long ago started to have non stock
> items in it, so I figured it would not be a problem to include fixed
> assets. However as I have said before I am happy for you to have the
> final say on webERP policy.
>
> I was a bit upset at the comment in the change log which I am not sure
> is the correct forum for personal opinions on other peoples code. It
> sets an unfortunate precedent and I feel it would be best if the
> change log was just a description of the change. As Exsson said the
> only bug was the typo with extra " which I think came in when I was
> doing that mass change for the form id, and I corrected as soon as you
> informed me, the other problem I couldn't replicate. Also I felt the
> tone and content of the emails to the list was a bit insulting to the
> people who wrote the code, which worked, even though you consider it
> to be a "hack".
>
> Most worryingly for me though is that trunk which was working is now
> completely broken. For instance I am told (but can't verify at the
> moment) that the db upgrade script is now broken and wont even run.
> There is more apparently than just the bug that you reintroduced the
> other day and I emailed you about. Even without the bugs though trunk
> now doesn't work as your changes are not complete. My fear is that if
> you run into the same problems that we did with this approach, then
> backing out will be very hard. We kept the work in a separate branch
> until we were happy it worked, would not it have been better to keep
> your changes in a new branch until it worked?
>
> As you say this is the first time we have disagreed about webERP
> policy and code, and I would like to keep it as that, just as a
> discussion about policy and not personal which I felt it had become
> with your previous comments.
>
> Thanks
> Tim
>
>
> On 16 November 2010 22:05, Phil Daintree<phil@logicworks.co.nz>  wrote:
>> Hi Tim
>>
>> Thanks for explaining the rationale for using the stockmaster to store fixed assets.
>>
>> Following my initial comments privately and in the change log when I started to realise the problems with this code, I have studied the logic before starting with the major changes yesterday. I fully realise the large changes required to make the new structure work. I do also understand the rationale and some areas of common logic which made you choose to merge fixed assets with stock.
>>
>> However I feel the separation between fixed assets is both important and logical - the code will be simpler, be more readable and maintainable. But yes it is very largely a rewrite.
>>
>> I am proposing to have a function from stock adjustments that allows stock to be transferred to a fixed asset. This handles internally manufactured items neatly. Purchase ordered items will go through as nominal items and the supplier invoice will have a new script to capture fixed assets like grns shipment charges or contract charges. I put all this up on the wiki for comment. I should be able to remove any additional complexity from goods received and stock scripts.
>>
>> Unfortunately, after a few weeks consideration and after communicating my concerns, I still felt that the fixed assets merged with stock was ill-conceived.
>>
>> I too have concerns as Exson expressed so eloquently. I know it is very difficult, boring and time consuming testing adnauseum. But we must now dig in and knock over a few bugs. Probably not all that many but enough to frustrate and undermine our reputation for reliable code.
>>
>> It is time to take a breath as you say Tim.
>>
>> Perhaps with some  communication of development intentions prior we could have side stepped this difficult situation we are now in.
>>
>> I do hate to be on the other side of the fence from you Tim this is the first time it has happened and I really would prefer to be talking to you about this. Please rest assured I have not taken this action on a whim.
>>
>> Phil
>> Phil Daintree
>> Logic Works Ltd - 0275 567890
>>
>> -----Original Message-----
>> From: Tim Schofield<tim@weberpafrica.com>
>> Date: Tue, 16 Nov 2010 12:50:17
>> To:<phil@logicworks.co.nz>; webERP Developers<web-erp-developers@lists.sourceforge.net>
>> Subject: Re: [WebERP-developers] Hacks should not be in webERP trunk - the
>>   Fixed Assets Module!
>>
>> Hi Phil,
>>
>> I think you have been hasty to judge, and to change this module
>> because it didn't at first work for you.
>>
>> The decision to use the stockmaster and related tables was not taken
>> on a whim. By separating out the fixed asset items into a new table as
>> you have now done means many changes to many scripts, and changes to
>> other tables. For instance the goods received script now needs
>> considerable reworking to make it work with your changes, whereas
>> before it just worked fine. The purchase ordering scripts also now
>> need changing as the fixed asset items will no longer appear. The
>> whole serial items code (which in my opinion needs reworking) also
>> will have to be changed to fit in with this.
>>
>> I feel from the tone of your emails to the list, and from the tone of
>> your comments in the change log that you decided the code was bad and
>> jumped in to change it without properly understanding the decisions
>> that went behind the code. I appreciate this is my fault as I was
>> unable to reply to your email asking for clarification, but I do
>> wonder whether a pause for breath is not required here before the code
>> gets very messy.
>>
>> Thanks
>> Tim
>>
>>
>> On 15 November 2010 11:15, Phil Daintree<phil@logicworks.co.nz>  wrote:
>>> Yeah I guess I was a bit upset about seeing this code - the more I look
>>> the more grizzly I get! It will pass. Is this your work Tim?
>>>
>>> I hope you won't mind me reworking it some and knocking it into shape.
>>>
>>> I am keen to understand this more. Next time you are on Skype early
>>> morning would be nice to chat.
>>>
>>> Phil
>>>
>>> On 15/11/10 18:41, Tim Schofield wrote:
>>>> Hi Phil,
>>>>
>>>> I am a bit surprised at this email as we have several people using
>>>> this functionality.
>>>>
>>>> You wrote me an email a couple of weeks ago that I haven't had a
>>>> chance to respond to as things have been a bit difficult here. Some of
>>>> the queries that you brought up I did some alterations on, but others
>>>> I could not replicate, is your database correct?
>>>>
>>>> Yes we used some of the stock scripts, as  the functionality there was
>>>> very similar, and maybe they could do with more tidying up, but I am
>>>> very surprised you couldn't get it to work.
>>>>
>>>> "Hack" is an emotive and subjective word, and I do not agree with its use here.
>>>>
>>>> Tim
>>>>
>>>>
>>>> On 14 November 2010 03:17, Phil Dainrtree<phil@logicworks.co.nz>    wrote:
>>>>> Guys,
>>>>>
>>>>> Is anyone using the fixed asset code that was committed to SVN some time
>>>>> ago? I would be most surprised to hear any positive responses ....
>>>>>
>>>>> I fear on looking into it and doing a little testing myself that this
>>>>> code is absolutely woeful.
>>>>>
>>>>> It is a poor hack of the stock items scripts and quite badly broken in
>>>>> my view. Just a warning for anyone intending to use this - don't!
>>>>>
>>>>> I put a huge amount of work into webERP and it is very upsetting for me
>>>>> to see this sort of code getting into the trunk.
>>>>>
>>>>> I opened up development to others and I have made it plain that future
>>>>> webERP work must follow strict guidelines and hacks are absolutely to be
>>>>> avoided. Only carefully crafted scripts in a style that I took the
>>>>> trouble to describe at length. I trusted that those with SVN access
>>>>> would follow this formula. I simply don't have the time to review all
>>>>> the code these days as I have to earn a living and most of my webERP
>>>>> work is voluntary.
>>>>>
>>>>> I will be working this code over to try to get something functional - it
>>>>> will take some time.
>>>>>
>>>>> I am aware of one business who was depending on this functionality and
>>>>> has come away disappointed - this does very bad things for webERP's
>>>>> reputation.
>>>>>
>>>>> A reminder then that code that goes into the trunk must:
>>>>>
>>>>> a) Be tested - a couple of minor bugs ok ... but is should basically
>>>>> work. It may not work so well when first committed but it should be
>>>>> polished up before it is left.
>>>>> b) Be written according to the detailed style guide at
>>>>> http://www.weberp.org/ContributingtowebERP - please re-read this if you
>>>>> had any involvement in this code.
>>>>> c) Must not have large tracts of redundant code in it
>>>>>
>>>>> This may seem ungrateful as someone has clearly had a go at trying to
>>>>> put together a fixed assets module and it is an interesting concept to
>>>>> recycle the stock logic but the scripts in there present form have no
>>>>> place in the trunk let alone version 4.0RC1 - there has been very little
>>>>> communication on the list about this development and it needs a warning
>>>>> out there to folks who may see it advertised (as I have done) that it
>>>>> plain doesn't work.
>>>>>
>>>>> --
>>>>> Phil
>>>>>
>>>>>


Although I did try I was unable to have a skype conversation about this with Tim - I even thought he may have been actively avoiding me - although I had requested a discussion at least twice.

Date Permissions Modified Changing Tim From web-erp Admin to Developer

Screen shot of sourceforge web-erp project admin log

Tim's permissions were updated from webERP Admin to developer on 13th November 2010. This log also shows the dates when Tim was removed completely due to him over-writing my work Dec 27 2010 - and then reinstated  Jan 21st 2011 - he has been removed again finally in April 2013.

Links to Code Over-writing my Commits


I committed the start of my purchasing code review on 14 Dec 2010

https://sourceforge.net/p/web-erp/code/4183/

The commits to svn over-writing my purchase ordering work were on 22 December 2010

https://sourceforge.net/p/web-erp/code/4438/


and a couple of minor changes too around this time.

There was a heap of review work subsequent starting on

https://sourceforge.net/p/web-erp/code/4458/

There was also a dispute around the upgrade methodology. Tim could not accept my decision to go with a single SQL file for each version upgrade rather than the pseudo SQL language he developed. Which he proceeded with anyway so I was left with little alternative but to remove him temporarily while I got on with the job.


Final Removal from the Project

Tim's commit:

http://sourceforge.net/p/web-erp/code/5834
 
contained references to his Kwamoja fork and also used css classes we don't use in webERP.
I asked him to review and fix it... he refused.
Access now removed as a result.
 
Date: Sat, 6 Apr 2013 02:05:56 +0100
Subject: Re: [Web-erp-svn] SF.net SVN: web-erp:[5834] trunk
From: Tim Schofield <tim@weberpafrica.com>
To: phil@logicworks.co.nz
Content-Type: text/plain; charset=ISO-8859-1

Give me a clue?

On 06/04/2013, Phil Daintree <phil@logicworks.co.nz> wrote:
> If you can't see the issues with this then you must be incompetent.
>
> Phil
>
> Phil Daintree
> Logic Works Ltd - +64 (0)275 567890
> http://www.logicworks.co.nz
> skype:daintree
>
>
> On 06/04/13 13:16, Tim Schofield wrote:
>> Reviewed
>>
>> On 05/04/2013, Phil Daintree<phil@logicworks.co.nz>  wrote:
>>> Please could you review this diff.
>>>
>>> Thanks
>>> Phil 

My advice to Tim:

Date: Sun, 07 Apr 2013 13:00:13 +1200
From: Phil Daintree <phil@logicworks.co.nz>
To: Tim Schofield <tim@weberpafrica.com>
Subject: We're done

Tim,

I spent a little time trying to re-moderate your postings advertising 
your hate blog but in the end I thought "stuff it" and deleted the lot 
using the prune option.

You are now banned from the forums and your alter-egos.

You are still only moderated on the mailing lists. Of course silly posts 
will not come through to the list. No doubt you will continue to infect 
people as they write to the list.

You write access to svn has also been removed - since I just can't trust 
you and your latest commit is full of css errors.

For a long time I though you were a good guy genuinely trying to help me 
with webERP... increasingly I have found I am wasting so much good time 
on you it is hampering webERP rather than helping. It is unhealthy for 
you to be harbouring such a grudge and I have no time for you any more 
sorry TIm. Let us move on now please.

It would be much better for you to focus on something positive in your 
life.



Purchase Orders Conversion Units:



From - Sun Nov 28 08:41:30 2010
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00800000
X-Mozilla-Keys:                                                                                 
Message-ID: <4CF16CF8.1030509@logicworks.co.nz>
Date: Sun, 28 Nov 2010 08:41:28 +1200
From: Phil Daintree <phil@logicworks.co.nz>
Reply-To: phil@logicworks.co.nz
Organization: Logic Works Ltd
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1
MIME-Version: 1.0
To: Tim Schofield <tim@weberpafrica.com>
Subject: Re: [WebERP-developers] State of trunk
References: <AANLkTi=usYYbWE723Xa7C=SmoK-=iXYpynmuOQOJudzS@mail.gmail.com> <4CEF8601.6000302@logicworks.co.nz> <AANLkTimunC-kVmMAA1aSvEFKQqvZ-SdMgqj-zjs8NST6@mail.gmail.com> <4CF01E75.9010906@logicworks.co.nz> <AANLkTikpe=hwmMDwb6+ZwXJo00sC46pEEpCF40oSM59g@mail.gmail.com>
In-Reply-To: <AANLkTikpe=hwmMDwb6+ZwXJo00sC46pEEpCF40oSM59g@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Tim,

Sorry 'bout that. I understand your frustration - although it surprises 
me also that you would be using the trunk to demonstrate - given that I 
have advertised what I am doing.

ALTER TABLE purchorderdetails ADD COLUMN assetid int NOT NULL DEFAULT 0;

I really don't think a new branch is necessary for this - again we 
disagree. Only a few more scripts to go - with fixed assets. I got 
side-tracked, have had quite a go at the purchasing scripts - 
CamelCasing variable names etc I noticed that there are look ups for 
ConversionFactor all over. This needs to be thought through a bit and a 
proper solution developed. I have removed these in the short term. I 
think it best to have only our (the business's) units stored in the 
database, the only time I think we need conversions are :

- when the purchase order is placed and printed for the supplier
- when the purchase order is received.

It will need more rework... next job after fixed assets.

Phil


Note the dates - long before Tim's commit



Email

Tim states that I am peppering him with abusive email!!

In fact I have asked repeatedly to be spared the continual barrage of hate email from TIm on several occassions.

See my Thunderbird Tim Schofield spam inbox - his own folder - showing emails just for April - after I have asked to be removed from his emails.


and the email I have sent to Tim since December 2012


Tim is NOT an English Chartered Accountant

Finally, knowing the code of ethics to which I signed up to when I became a member of the ICAEW (Insititute of Chartered Accountants of England and Wales) and the strict ethical rules that apply to members I reported Tim to the Institute so they could investigate our dispute and discipline one or both of us as they saw fit. Of course, the truth is a great ally in such investigations. Only members of this institute are allowed to call themselves Chartered Accountants in the UK.

However, it transpires that this is yet another of Tim's deceptions. He is NOT actually a member of the ICAEW! I had believed this since 2007 and webERP had been promoted as being led by two English Chartered Accountants for a number of years prior to 2010. I am sorry to have been a party to this deception and I have been as misled as everyone else.


Monday 22 April 2013

Dispute with @Tim Schofield and the birth of webERP forks @KawaMoja and launchpad.net/weberp sourceforge/p/weberp etc

Declaration
This is the narrative of Phil Daintree - no anonymity. I will testify to any of the below in a court of law.  I have email and screenshots to support all of this. As well as evidence showing postings from gmail email addresses - all coming from the same ip address purporting to be different people. The ip address belonging to virgin media cable in Wakefield UK. Although this is where Tim lives - I have not checked it is actually him.

This narrative is presented to add some factual background and to discredit the lies that have been propagated about me (and the management of webERP) as a deliberate and calculated smear campaign as published in the webERP mailing lists, the KwaMoja web-site/blog and Tim's Blog. It was first published to provide perspective to some of the unsavoury exchanges on the webERP mailing lists.

The KwaMoja fork is Tim Schofield's fork of webERP and whilst I have had some differing views in design which led to our parting ways, Tim is a capable developer and I expect this work will initially be of a high quality. I wish the fork well, but I wish to dispute the reasons given for it's birth.

I donated the code of webERP to the GPL v 2 in 2003 having worked on it for the year or so prior. I have been active in it’s development for over 11 years as at the time of writing.

Background
Tim Schofield was a co-sourceforge admin for the webERP project for 3 years from 5th November 2007 to 13th November 2010 and has added considerable development effort to webERP over that time.
I had absolutely no reservations about making this appointment at the time nor at any time up to October 2010. The webERP goals of low footprint, fast and readable code with adherence to the programming style and conventions that I had used appeared to be goals shared also by Tim as demonstrated by the ample contributions of code he submitted. I was so pleased to have found a "kindred spirit" that felt the same way about these things as I did. I also recognised that Tim also has a better technical grasp on many things than I do and is in this way at least more qualified to lead the project than I am.
I had not been as heavily involved in webERP for quite some time prior to these events, with Tim taking the primary lead in development and I was happy knowing the project was in what I thought were good hands. I was doing occasional jobs adding functionality on request for businesses adopting webERP.
In October 2010 a customer (who can also corroborate these facts) asked me some questions about the fixed asset module and it quickly became apparent to me that this module did not work and was built upon the existing stock functionality, with fixed assets actually stored in the stock master table! Further, the stock logic had been modified (and complicated) with alternative logic to handle fixed assets. All the fixed asset specific scripts were in fact slightly modified stock scripts to accommodate the fixed asset logic but none of the variable names had been changed to reflect their new meanings in relation to fixed assets. As the fixed asset module didn't work, I set about debugging it. Debugging code where the variable names do not correlate to the actual meaning of the variable I found frustrating and absolutely counter to the way the whole of webERP is built and the underlying ethos of the system. Indeed it remains a fundamental goal of webERP that the system should be readable to business people and the coding guidelines are very clear about variable naming with names that reflect the values they hold. I have always been hot on adherence to the conventions and style in which webERP is written and this is well known. Tim well knew about this fundamental requirement.
I politely raised concerns privately to Tim, who I could see from the SVN repository had committed this code but he was unresponsive apparently away travelling in Africa. Initially, I thought that perhaps he had committed work that he had not done and perhaps he had been a little hasty in his review. I could certainly understand that and refused to admit to myself that Tim would have knowingly committed such code. However, it became apparent that this architecture was in fact his idea and he defended the work in this module - I am still not sure if he actually coded it - I still cannot believe it.
In my view it is one thing to make a mistake but quite another to refuse to admit it and rectify it.
I Removed Tim as and Admin of the webERP Project
I was disappointed and quite angry that he could have corrupted the code base of webERP so badly and also to realise that I had been so taken in (deceived into) believing that Tim was as committed to the goals and principles of webERP as I was. However, it was now abundantly clear that Tim was not after all aligned with the goals and standards that I held as so important for webERP.
It stands to reason that the leader of webERP must believe in and champion it's goals. I therefore felt I had no choice but to remove him as an admin of webERP on sourceforge on 13th November 2010 (as evidenced by the sourceforge project audit log). I was fully prepared (indeed I expected) for Tim to fork webERP into some other project without the same principle/goals of webERP. It was not without thinking that I did this. I want the code of webERP to be approachable for business people (as I am first and foremost a businessman) and that the power of such a system in the hands of a businessperson is so much more than any system not capable of being understood by a businessperson. Tim was prepared to sacrifice this goal - I am not.
I understood that removing Tim as admin of webERP was a drastic course of action and hurtful to him personally. He had certainly put heart and soul into furthering and developing webERP. However, in the final analysis I must conclude that he doesn't share the same goals as I do for webERP.
The second reason why I felt I must remove him, which has subsequently manifested itself much more clearly, was that he had shown that he is consistently unwilling to confront his errors nor to admit his mistakes. We are all human and mistakes are forgivable. However, it is unforgivable to blindly fail to admit to or rectify mistakes - especially in a leadership role.
Since that time, Tim has been unable to get past this event and much of the bitterness I believe stems from the action I took in 2010 - prior to this time our relationship was amicable - even good. However harsh it may appear, I remain convinced it was the correct decision. My regret is ever having appointed Tim as co-admin in the first place.

Rewrite of the Fixed Assets Module
Having myself advertised the availability of a fixed asset module in a released version of webERP containing Tim's fixed asset module, I then set about creating a fixed asset module (with the support of a customer) in keeping with the rest of webERP with fixed assets now having their own tables and removing the complexity from the stock scripts, properly naming variables etc. A complete re-write.
Purchasing and Unit Conversions
I also set about reviewing other areas of the system developed by Tim and during the course of my review work major flaws in the logic around unit conversions also became apparent. This caused massive duplication of code and increased complexity in many other scripts. Tim had been holding purchase order demand in the units of the supplier in the new purchase order code, then in all the scripts that needed the purchase order quantity on order he was multiplying out the supplier conversion factor by the reported purchase order quantity. I disagreed with the logic here preferring to record the quantity on order in the business's underlying unit and recording the conversion factor in the purchorderdetails table removing the complexity out of all the scripts that needed this data.
Again, Tim refused to accept my decision, rather than gracefully accepting it was a simple mistake and it was much more elegant to hold the units in the businesses unit of measure. A tirade of angry emails to the list ensued much more than a simple technical disagreement.
Temporary Removal of Tim's SVN write privileges
So I then set about reworking the purchase order functionality also.
During this time Tim started to over-write and reverse my work in SVN so I disabled his SVN access so I could get on with the job without having to rework my rework!. Happily, after a discussion over Skype we were able to move on from this and I reinstated his write access to SVN following this discussion.
Much of the purchase order code did in fact work, but had not been written in the same way as the rest of the system. I believe I have simplified this code considerably, which lays bugs much more open to quick resolution.
Automated Database Upgrades
As I became more involved in webERP again a number of other technical differences in approach became increasingly apparent, including the automatic upgrade methodology. Tim, for good reasons I do understand, wanted a pseudo SQL code in a separate small file for every database update.This allowed for updates and changes to existing data during the upgrade process. However, I favour a single upgrade file containing all the database upgrades in standard SQL for each version upgrade - so these are visible and readable in one place to upgraders. My approach has the disadvantage that data changes may be applied multiple times and cannot therefore be applied reliably using my method. Another tirade of angry emails to the list ensued.
I was prepared to flex on this if it helped ease his concerns and bring him back on board proper. However, he has never come back on board proper. In any event, I do prefer the simpler more readable solution we have. I would not now wish to go to Tim’s granular upgrade method.
Number Formatting Design
Tim was violently opposed to the design we have for the number formatting including commas and points to separate thousands/millions etc.
He wanted us to adopt a solution that relied on the locale of the language suggesting that this solution is actually that of the "PHP community" - there is absolutely no evidence presented for this (and none that I could find with google) and in fact there is no accepted PHP solution for multi-language number formatting except perhaps the PHP money_format function - which unfortunately is limited only to unix/linux (it also requires the user's locale is installed on the server too) and hence why an alternative was required.
Irrespective of Tim’s protestations, I am well pleased with the efficient design of the number formatting solution we have, as this now has no dependency on having the user's locale installed and a nice fall back to the php-gettext translation class in the event of gettext not being present. Tim had plenty of input into the solution we have and I kept everyone well informed of what I was doing. His protestations were far more than technical disagreement, he appeared to be aiming to undermine my credibility with deception and repeated mis-statements.
In the end it is about the solution though and logic prevailed to provide a good and now well tested solution.
The Copyright Issue
In March 2012 Tim unilaterally removed the copyright statement altogether because of an action he was taking against a 3rd party. His reasoning was that as it stood the copyright statement was invalid and his logic was that no copyright statement is better than an incorrect one... The copyright statement said:
Copyright 2004-2012 weberp.org
On examination of the GPL version 2 which webERP is licensed under, we are required to have a copyright statement. I reinstated it exactly as it was, but to clarify I made weberp.org link to the list of contributors of webERP in the manual - so there could be no confusion that the copyright is owned by the people who developed webERP.
Tim took great exception to "weberp.org" being attributed as copyright owner when this is actually a domain owned by me. Of course the domain was purchased and organised by me with assistance from Senokian and subsequently Ed Culp and for the last several years paid for out of the advertising that the domain had accrued. The copyright statement was changed in 2007 from:
Copyright 2004-2007 Logic Works Ltd
by Tim to weberp.org (Logic Works Ltd is my company).
revision 783 by tim_schofield, Thu Mar 20 23:23:56 2008
as you can see prior to that it was attributed to my company "Logic Works Ltd."
At that time we - Tim and I - wanted to attribute the copyright to all developers of webERP and "weberp.org" was the vehicle/name that we chose to represent the developers. The email from October 2007 where I set out my feelings on the matter is repeated below - it also corroborates other elements of this narrative:
From: Phil Daintree
Date: 6 October 2007 22:26
Subject: Re: webERP Administration
To: Tim Schofield
Tim,
Yes I monitor the list but not contributing directly to the discussion
... if someone is not getting appropriate responses I will support my
code. In the final analysis if edgeERP is more successful at acheiving
the goals of webERP then I am happy to get in behind them.
I've been reflecting on my actions a little and think I have done some
things poorly. While most of the work in webERP is mine I have donated
all my work to the GPL a long time ago and don't intend to have any
rights over the code personally or through Logic Works Ltd.
Furthermore - and more importantly I don't wish others to be put off
from contributing by all contributed code having a purported copyright
owner of Logic Works Ltd. I don't wish to create legal costs by
forming a trust in favour of the webERP user community but wondering
what entity should own the copyright - what about "weberp.org" - or
could we just exclude the copyright altogether. You seem pretty clued
up on this stuff and I am happy to accept any suggestion you may have.
As regards the text of licenses in each file, the reasons I would like
to avoid that are relatively minor:
1. One has to scroll down to find the meat of the script
2. The archive will grow significantly
3. I don't want to spend the time to edit the large number of scripts
we have to add this stuff to.
There is however, one good reason that I have overlooked for having
the legal stuff right - the confidence of other contributors, more
specifically you. I hope it is completely clear that I or Logic Works
Ltd does not intend to do anything other than hold the copyright in
trust for the benefit of the webERP community. I certainly don't
intend to run off with the code! If there is away to make that
intention more transparent then we should do it.
Since advertising the fact that I am wishing to make money from webERP
development I have been more active than for some-time in developing
new features for webERP! webERP has now has reached a good level of
functionality and many businesses are thinking well if this system
could only do X or Y it would get over the line (a topical rugby
anology!) for their business. Having a commercial option for giving
webERP X and Y features means that companies can now consider webERP
as an option and it is benefiting webERP. Originally I had hoped that
company business developers would get behing webERP and give their
code back - that was too ambitious. However, it was increasingly
apparent that a small group of webERP support consultants were
developing solutions for busiesses ... great, but they were not giving
back to the hand that provided the bread. I found this quite
upsetting. I figured if I made myself available for the work it would
find its way back in and be of benefit to all and also give my wife a
reason to not mind me spending time on it. I am only after pocket money and looking
only for projects that improve webERP and for the joy of the
development. Also, as you know I am CFO for a $30m company with
significant demands on my time already.
All of the above remains true as at the time of writing.
Tim removed the copyright statement that we had agreed on in 2007 unilaterally with no discussion in March 2012:
revision 5108 by tim_schofield, Mon Mar 19 07:10:58 2012
The GPL v 2 requires a copyright notice and I decided that the copyright statement that had served us for the 4 years prior was perfectly ok and I changed it back.
revision 5617 by daintree, Sat Sep 1 02:14:10 2012
My ownership of the weberp.org domain has been only as the webERP project administrator and no personal benefit or ownership has ever existed - I have maintained separate accounts in a loan account to Logic Works Ltd for the income and expenses relating to weberp.org - as published on the developers mailing list.
To even suggest that a domain name could actually own anything is foolishness in any event - clearly the domain name is just that a name. “weberp.org” as we named the project/developers is the partnership of developers/project entity that built the software - we simply named the partnership/project, naturally enough, the name of the domain indicating that we were a loose organisation developing webERP.
Tim has consistently linked the fact that I own the domain weberp.org as evidence that I have assumed ownership of all developers copyright in the work of webERP! The fact that I have owned the domain only as trustee for the project - the developers of webERP (weberp.org) has not stopped Tim from taking great exception and sending extensive misleading emails to the list. I have actually changed the domain registrant to webERP Developers now indicating that the domain is owned by the Partnership of Developers that form the webERP project. Each developer always has retained all rights and copyright to their code - the project name “weberp.org” is simply used as a shortcut to mean the Developers of webERP.
Initially Tim was satisfied with this, indeed it was actually him that made the change to the copyright statement to weberp.org himself! This issue has caused a long and boring tirade of angry emails to the list and to list members off list subsequently apparently and culminated with his access to the list being moderated. Again, the repeated allegations irrespective of the obvious truth continue to flow.
Tim's Forks of webERP
I have not kept up with his activities since late 2012, Tim did maintain a fork (which he insisted was a branch?) which he confusingly also called webERP at http://sourceforge.net/projects/weberp note the slight difference in the URL. He also maintained forks at launchpad.net presumably containing all his client’s code. More recently I understand Tim was the major contributor to a fork under a different name - KawaMoja. Also, another myserious major contributor Fahid Hatib also appeared with a gmail address. These forks were taking the development from webERP and rebadging it with a different name.

(Note that http://sourceforge.net/projects/web-erp is the original webERP that I maintain having named it in late 2002.)
I have no difficulty with Tim forking the code base - this makes sense if he is unable to work with me and has different aspirations and goals for the project. However, it is deceptive to call a fork “webERP” - holding his fork out as the same project is clearly misleading and inappropriate. Hopefully he will put his efforts into KwaMoja and let the forks holding themselves out as webERP lapse.
Tim's forked code is now widely different to the current system although he adopts many of the advancements published in the trunk here.
I would genuinely prefer Tim to be actively applying his considerable skills developing for webERP rather than focusing on his forks and continually attempting to discredit me. However, his demonstrated inability to accept my decisions makes this an unlikely prospect.
Current Situation
Tim's Write Access to the SVN code Repository
Tim retained write access to the webERP svn repository up to April 2013. However, due to my inability to trust his work - he was updating the webERP repository with code that referred to non-existant css classes and referring to kwamoja fork. After fair warning and asking him to reveiw and fix his work - which he would not - I finally had to accept that Tim is unlikely ever to be able to move past all this and be useful as a developer of webERP. To retain his work was taking more of my time than doing it myself.
Tim's Mailing List Access
I really did not want to restrict Tim's mailing list activities while there was still some positive value to what he contributes, preferring instead to take the good with the bad. However, in September 2012 when I felt that the bad was outweighing the positive I finally had to accept that I have to moderate Tim's postings to the lists. His postings had deteriorated into consistent personal attacks on me and often contained deceptive and misleading statements. I then had to spend increasing amounts of time defending myself and having to expose his deceptions. Even when I had pointed out the inconsistencies in his emails, he persisted his deceptions.
The straw that “broke the camel's back” was the copyright issue.
Since I have changed Tim's subscription to the mailing lists to "moderated", he maintains that he is no longer able to help people or send mail to the list. This is not true. I changed his email addresses to moderated in October 2012 - and yet the posting:
clearly demonstrates that he can send mail to the list subsequent to his postings being moderated. I have also written a couple of test emails from each of the three email accounts Tim has registered on the mailing lists - by spoofing the from address of the emails. All three went through.
However, his email has to be moderated by me before it will be distributed. Due to the time differences there could be a delay before I am able to approve it. Of course any content that is not true or abusive will not be permitted and I have advised him of this. I am aware he is emailing subscribers off list to posters complaining that he "cannot send to the list". Again this is not true. He cannot send abusive email containing deceptive comments to the list. In practise this has amounted to him being banned as he has been incapable of producing cordial factual email.
There was a brief period where one of his three subscriptions to webERP mailing list was disabled, but this was due to his mail to weberpafirca.com being broken and all the mail bouncing. It was reinstated as soon as I was confident in the domain email being fixed.
(As an amusing aside you may note from the list posting above that Tim now believes I impersonate someone else masquerading as Anthony Whitehouse. Anthony has tried to advertise that he is in fact he really is someone else with the only link to me being that he is based in New Zealand!!)
Although Tim's emails are clearly tainted with bitterness, I do appreciate his review of my design decisions, he has been able to prevent me from making mistakes and in some cases I have reworked things that I have done incorrectly due to his review. Happily we can be assured that the same situation will prevail going forward as I have been receiving extensive mail from Tim off list which will no doubt continue should I make any mistakes.
Open debate is an important part of open-source development and the ability to debate in good humour certainly helps in the enjoyment of the exercise.Having debated we must then decide for the benefit of the project and move on. It is no use being bitter and angry about past decisions. If you can’t accept them you can always fork the code of an open-source project

Tim's Contribution to webERP
The extent of Tim's significant contribution to webERP but he put the figure at two thirds of the code! I beleve this a gross exaggeration (at best).

He points to the number of commits he has made as evidenced by the Ohloh link.
He is in the habit of committing one line - often single character or spacing modifications to the code - which tends to flatter his contribution in terms of the number of commits as other contributors commit multiple files in a single commit - although contrary to accepted good practice.
Also, the ohloh analysis of the number of commits that he has linked to includes commits to Tim's fork of webERP as well as the real webERP trunk proper. This in my view is a further deception, counting his commits to his own fork as well as webERP - so double dipping! See  http://www.ohloh.net/p/weberp/enlistments It looks almost as though he is attempting to inflate his contribution artificially.
I consider a more appropriate measure to be the total lines contributed to (and still used by) the project: This has it’s problems too as small changes to the code spacing/formatting/SQL quoting etc give the credit to the last committer - where in fact the initial committer of the script has of course done 99% of the work. In addition both Tim and I have committed quite a bit of work done by others - where blame gives the credit to us as the committers.
The output of the following command - which counts the lines of code committed - on the current web-erp svn is available for anyone to see for themselves. I actually believe this measure also flatter's Tim's contribution because he has committed a lot of very minor changes to a lot of lines. Each of these will give the credit of that line to the last committer. This command looks at the code in the top level directory, the includes directory, the install directory, the api directory and the javascripts directory and the manual:
# svn ls . includes doc doc/Manual javascripts install api |egrep -v -e "V$" |xargs svn blame | awk '{print $2}' |sort |uniq -c
As at 26 November 2012:

%
Lines
Developer
0%
1
apmuthu
65%
80,338
daintree
0%
255
dataforceza
0%
2
DebiCates
1%
1,513
emdeex
0%
85
exsonqu
1%
857
ExsonQu
0%
21
foxdeluxe
0%
8
hindraj
0%
357
icedlava
0%
45
javier7
0%
127
jessep
0%
13
lindsayh
1%
1,485
myea4cj
0%
7
nicholaslee
0%
76
samudaya
1%
1,433
tehonu
24%
29,246
tim_schofield
0%
1
turbopt
0%
50
TurboPT
0%
7
uldisn
6%
8,038
vvs2012
0%
57
waynemcdougall




124,022
Total Lines
Tim's proportion = 24% - a huge contribution there can be no doubt. But a very different picture from the ohloh analysis of the number of commits to svn (including his fork). This analysis excludes the SQL report writer written by Dave Premo and any of the translations.
Also, when these lines are analysed, what new functionality has he added?
The only modules that are not written by me are:
  1. The Petty Cash module - Ricard's work that Tim committed.
  2. The tenders/offers work - Tim did this but it doesn't actually work in the current code base. I may have broken it.
  3. The purchase order work was originally written by someone else (Rob Virgin) and committed to the svn repository by Tim. I reworked quite a lot of this later on.
  4. The report writer - work done by Dave Premo
  5. The API - this is Tim's biggest contribution
Tim has made great contributions in beefing up security across the board - following the Secunia report. SQL quoting using double quotes and single quoting all parameters sent to SQL, also sanitising $_POST and $_GET variables. He has also tweaked some html formatting. i.e. lots of small changes to many lines/scripts.
Factor companies was Tim's work as was the smatterings of javascript we have in the nice compact little javascript file.
Substantial contributions but clearly by no means two thirds of the code as he has claimed!
Of course my contribution is also flattered by the fact that I have committed lots of work done by others too - in particular the intial commit of Mark Yeager’s MRP work - which was a significant addition. It is very hard to come to definitive conclusions - but it is clear I think that Tim has NOT been responsible for 2/3rds of webERP’s code base.