Thanks Greg, A few points for your consideration a) Marketing the LDP project:- You are missing the numbers, from the LDP propaganda, numbers/statistics etc. (even MicroSoft quotes things like TCO ;-) in their propaganda) Someone may try coming up with numbers from git commit logs, but how do we know, how many of them came from LDP efforts ? b) You need to segregate the LDP targets into 2 categories Enterprise endusers & Non-Enterprise endusers. Enterprise endusers are the ones telling you, their h/w is well/somewhat supported, Non-Enterprise endusers are the ones telling you, their h/w is _NOT_ supported, "Enterprise" segment is attractive to developers, there's money to be made.... "Non-Enterprise" segment is _NOT_ attractive to developers, there's _no_ money to be made.... "Non-Enterprise" segments usually end-up with only volunteering efforts and thus suffer. So I have to ask, what is the goal of LDP, target only "Enterprise" segment ? c) Taking Driver support on a war footing Please work to centralize the H/W compatibility list, every distro is rolling their own...its all a mess Start a major effort to Whitelist/Blacklist Manufacturer & Devices, the Idea is as below - Centralize h/w compatibility support list - This list will have regularly updated list of _actual_ Brand Names & model numbers - Users will use this before buying h/w (you wish !!) - Users will report incompatibility too. - Start rating Manufacturer based on its support for FSF/openness - Users must reward the more open Manufacturer based on this list by spending their money.(wishlist) - this is based on the carrot & stick approach, your strategy only uses the carrot approach, (MicroSoft uses both carrot & stick, by funding you or your competitors.) Here also note that the "enduser" is involved, whereas, you are only considering vendors & developers, in your strategy. d) is LDP for the benefit of all endusers, or just the enterprise ones ? (just making sure this is discussed/answered) e) reverse-engineering is _THE_ opensource way, (going back to the time of PDP ?) do you agree to the above statement, as a spokesmen for Linux as a OS? f) putting 2+2 together, - If you care about doing something to help all end users (not just enterprise ones) - reverse-engineering is _the_ opensource way wouldn't it make more sense to mobilize your efforts to solve this pressing problem, with / without documentation being made available ? g) there's a reason manufacturers don't bother with documentation, they make a IC in a batch, and if they only have order for 1 batch run, why bother with documentation, just fab it and forget about it, is their attitude. e) wireless is a mess because of FCC regulations, they want manufacturers to limit the operating capabilities of the device(frequencies), manufacturers figure that its cheaper to do this in s/w rather than h/w, by making a closed source firmware. I don't see how we can improve this situation unless you can help EU legislate it away (assuming US is a lost cause) I hope you will take the above into account, and improve your strategy for LDP. -JoJo On Tue, Apr 8, 2008 at 3:18 AM, Greg KH <greg at kroah.com> wrote: > Hi all, > > It's been about a year since the linux driver project was started, so I > figured that it was about time for a status report of how things are > going, and how things are going to be changing a bit for the future. > > Thanks again for everyone that has participated so far, I, and all of > the Linux users out there, really appreciate it. > > greg k-h > > ------------
