This is the mail archive of the ecos-maintainers@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: NAND & YAFFS


Hi Andrew,

You bring up some fair points (as do others in this thread) and I want
to respond to them separately from the necessary ongoing technical
discussion on the NAND layer front.

Andrew Lunn wrote:
> Hi Folks
> 
> As an eCos maintainer i've been taking a back seat recently, pursuing
> other interest etc. However i'm probably the most independent
> maintainer since i've never worked for eCosCentric. 
> 
> [...]
> 
>> I dutifully followed eCos' outlined procedures to avoid double work,
>> and did RFCs and notification of early release (including the
>> statement that it is complete on my BlackFin hardware, and that it
>> had survived some long YAFFS tests).  Sure, I picked up the comments
>> made by Andrew Lunn.
> 
> I fully agree with you here. You did all the right things. 
> 
> I wish i could of helped some more, but i have no real knowledge of
> NAND, don't have any hardware which uses it and no real personal need
> for it. I did consider writing a synth NAND emulator, as a way to get
> into the subject more, but there is no really itch i needed to
> scratch. 
> 
> Anyway, this is getting away from the point of the email...
> 
>> Allow me to confess that I am disappointed that the work I put into NAND  
>> flash for eCos has not been considered by eCosPro. 
> 
> [...]
>> Another reason that I think eCosPro has not chosen the wisest course  
>> here is the shadow it throws into the future. Isn't it an unattractive  
>> proposition for anyone who would want to contribute that they will only  
>> afterwards be informed that their work may be out-competed by eCosPro  
>> themselves?
> 
> This is also not the first time this has happened. A recent example
> would be the Cortex-M3 work. If i dug into the email archives i could
> find other examples. There is a possibility of it happening again soon
> as well. eCosCentric have a more modern lwIP port in there tree than
> the current in anoncvs. I understand they have optimized it for small
> platform and made it more stable. There is the current effort going on
> to update the anoncvs lwip code. When this reaches maturity, which
> looks like will happen soon, are eCosCentric going to pull out there
> trump card again and contribute there lwip port? 
> 
> In most of these cases there has been early communication from the
> community. eCosCentric don't take part in such communications, which
> is find disappointing. In fact the only module i can think of which
> had open discussion between an open community development and
> eCosCentric payed for by contract was the flash_v2 code.
> 
> They are a commercial organization, so do have some restrictions.
> Fixed delivery dates, NDAs with customers, the desire to sell
> something a couple of times to recoup their costs etc.  They also need
> to defend against the case that somebody says they are going to
> develop feature X, which eCosCentric already have, in a hope that
> eCosCentric will make there version available for free. It seems to me
> eCosCentric waits for the open version of feature X to reached beta
> quality, is clearly going to be useable, but is incompatible to there
> implementation. They then make there own available to easy there own
> integration problems. By this time, whoever has implemented the open
> version has spent a few man months and is not happy about there wasted
> effort and maybe then being forced to port there device drivers etc to
> eCosCentric infrastructure, so causing them more effort.
> 
> How can things be better? I would say eCosCentric needs to find a way
> to be more open about what they are doing. Was this level of secrecy
> needed for a NAND infrastructure? What has been gained by eCosCentrics
> customer by keeping it secret? Why could eCosCentric, when it got the
> contract, not jump into the discussion, suggest changes to the
> proposed API and get it frozen. Maybe offered to take over development
> of the core and ask Rutger to work on drivers for his specific devices
> using the frozen API? If this could not be done out in the open would
> it not of been possible to setup an NDA with Rutger and do it behind
> closed doors until it was ready for release?
> 
> eCosCentric is also not benefiting from the community. They have lost
> 3 man months of effort from Rutger which could of been used for nearly
> free to fulfil there customer contract! Once they released there
> Cortex-M3 port a few bugs where quickly found which with a more open
> development process would of been found earlier. There own products
> could be made better from more interaction with the community.

I completely agree that it would have been better if eCosCentric could
have discussed development with Rutger earlier, and for that on behalf
of eCosCentric I offer an unreserved apology to Rutger. I wish we could
have handled this differently.

As you note above, sometimes commercial confidentiality issues do come
in to play and that unfortunately was the reason for the delayed
discussion of this work. Specifically there were two main elements at
play a) negotiations with Aleph One, and b) negotiations with customers.
As a golden rule we do not discuss our commercial plans and those of our
customers or partners in public. eCosCentric's standard commercial
contracting mode is not a time and material basis; but fixed price, fix
delivery date contracts. We have an built a reputation for delivering
complex but reliable software on time. A necessary side-effect of this
is that you want to have control over all of the parameters that may
effect this. This can make development in an open mode very difficult.
At the time the decision was made the Rutger's code had only just been
made available. The default was that we would base our work on it, but
after technical review we determined that (from our standpoint) it was
not ready for commercial use, and most importantly its layering and
organization was not the most appropriate design.

I hope this serves as a more detailed explanation of how this panned
out. As regards how we can better manage and communicate these kind of
aspects in future - we are very open to discussion with the maintainers
as to how this can be improved.

Although eCosCentric employed maintainers are the driving force behind
all our engineering and are well aware of the commercial aspects of the
business, they are fiercely independent as regards their maintainer
roles. We shouldn't and don't expect them to represent the companies
interests in this role. Although they, and we as a company, cannot share
commercially sensitive information with the community as a whole,
perhaps there are ways that we can be more open with the maintainer
group. I'm not sure that NDA's are viable in this context, but it would
be good to find appropriate ways to communicate and share some
commercially sensitive info and ongoing development plans.

Regarding contributions in general - it can be difficult for us to
determine when and if we should make a contribution to the community.
When we invest time and money into development of a specific feature we
need to see some level of ROI, otherwise that development would not have
existed in the first place. There is always ongoing debate within
eCosCentric as to how we should manage this - viable open source
business models are complex to get right! At the heart of this though we
want the best and most appropriate technical solutions for the eCos
project. Competition and choice can be a healthy thing in this regard.

Apart from contributions we do also play a major role in the more
thankless heavy lifting - as evidenced for example by our major
commitment of time and resources to getting eCos 3.0 out. You all know
our heritage and passion to improve eCos - and doing this in beneficial
and constructive way with the wider community *is* important to us, and
I'm sure we can find ways to improve our interaction to everyone's
benefit. We understand that a fundamental level, what benefits eCos also
benefits eCosCentric.

> How do we go forward with the NAND work? First impressions is that the
> two implementations are roughly equal. So we need an open review of
> both. Since eCosCentric are offering to contribute theres, please post
> it to ecos-patches along side Rutgers, so all interested parties can
> take part in the review.

Ross will post the documentation followed by a code drop shortly.

Paul.
--

Paul Beskeen
Chairman
eCosCentric
http://www.ecoscentric.com/
phone: +44 1223 245571


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]