From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14245 invoked by alias); 15 May 2009 16:19:19 -0000 Received: (qmail 14235 invoked by uid 22791); 15 May 2009 16:19:17 -0000 X-SWARE-Spam-Status: No, hits=2.3 required=5.0 tests=BAYES_20,SPF_PASS,TBC X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 15 May 2009 16:19:10 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id C6BE63B4003D; Fri, 15 May 2009 17:19:06 +0100 (BST) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3l0gSbpWSjr; Fri, 15 May 2009 17:19:04 +0100 (BST) Received: from [192.168.1.100] (farm.ecoscentric.com [62.249.226.156]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: paulb@ecoscentric.com) by mail.ecoscentric.com (Postfix) with ESMTP id 37D2D3B40030; Fri, 15 May 2009 17:19:04 +0100 (BST) Message-ID: <4A0D95F6.6050305@ecoscentric.com> Date: Fri, 15 May 2009 16:19:00 -0000 From: Paul Beskeen User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Andrew Lunn CC: Rutger Hofman , Ross Younger , ecos-maintainers@ecos.sourceware.org, Simon Kallweit , Sergei Gavrikov , Melanie Rieback Subject: Re: NAND & YAFFS References: <4A0AD212.60208@ecoscentric.com> <4A0C6674.5030006@cs.vu.nl> <20090515095150.GH17679@ma.tech.ascom.ch> In-Reply-To: <20090515095150.GH17679@ma.tech.ascom.ch> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact ecos-maintainers-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-maintainers-owner@ecos.sourceware.org X-SW-Source: 2009-05/txt/msg00016.txt.bz2 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