Slashdot Mirror
Broadcom Releases Source Code For Drivers
I'm Not There (1956) writes "Broadcom, the world's largest manufacturer of Wi-Fi transceivers, open sources its Linux device drivers. This is a big win for Linux users, as there are a lot of users that face Wi-Fi problems when they use Linux on their laptops. With these device drivers now open source, distributions can ship them out-of-the-box, and that means no Linux Wi-Fi problems for new devices and upcoming distributions at all."
Congratulations Broadcom, you have just made at least one geek very happy.
While you're at it, any chance of releasing the source for your video decoders? I promise that you will own the HTPC market if you do.
--- "When you're strange"
No one is saying that device drives will magically start working flawlessly because their source code is open, although it will make it easier to track down bugs (see Linus Torvalds' quote about the number of eyeballs).
The main point, however, is that now Linux distributions can ship these drives out of the box, so wireless devices will work straight away. Until now the biggest (and dare I say only?) problem I've had with installing Linux on a laptop is finding and installing the right drivers for wireless network cards.
Maybe I'm about a year behind on Broadcom on Linux, but last I looked you had to use NDISWrapper with the Windows driver to get it to work, and Broadcom had no actual driver (was using a 2007 era HP Laptop).
I'm starting to think GNU is the problem with "GNU/Linux" these days.
Tomato Firmware is still stuck on Linux 2.4 because Broadcom's driver blob hasn't been ported to 2.6, Don't know how much of a difference it'd make for my WRT54GL, really, but it'd still be nice to be more modern than ~2.4.17.
Hail Eris, full of mischief...
E pluribus sanguinem
I've never really understood: why don't more hardware companies open the source for their drivers? Is there super-secret special source in the drivers that they're trying to prevent their competitors from learning? Is it an issue of patents?
It seems to me that drivers are an instance where opening the source should be a no-brainer. It's not like an application, where you're trying to sell the software. People still need to buy your hardware to make use of the drivers, so it's not like your customers will be inclined to stop buying things from you. I would image you could drastically lower the cost of supporting the drivers by opening them, though. You'll probably increase quality at the same time.
I'm sure I'm missing something, though. Would someone enlighten me?
Speaking as one who routinely works on open and closed projects, believing the documentation would be tempting, but usually a mistake.
The driver reflects the reality. If well commented (particularly if it has developers venting frustration), it really reflects the reality of how that doc got implemented in reality.
Often documentation is first written, then parts fabricated/code developed. When the fabricated parts come in, often there are minor different and/or incorrect interpretations of the spec, major enough to make the doc unusable, often minor enough to work with a change to the driver. When this happens, the driver will get updated, but going back to the documentation... No, not so much.
Particularly when it comes to the 'what it could do' part, at best it's not already done because they decided not to fund it and it is simply untested and may or may not work. Frequently it's because that capability was so fubared in testing that the feature was thrown over the fence to make a schedule.
XML is like violence. If it doesn't solve the problem, use more.
You might find this hard to believe but the large OEM's (HP, Dell and all the others) are demanding Linux driver compliance in their OEM selection process. Linux is huge in the server market, particularly in visualization, is taking over the cell phone market and will one day be in the home. If you don't OSS your drivers you will lose OEM contracts and likely won't be told that you lost because you didn't have Linux drivers.
Linux will one day be the dominant OS in all the backend servers, the dominant players in the largest percentage of Embedded devices (including cell phones) and in the future will dominate the desktop.
1. I should spend a month or two of engineering time to write specifications for a block that isn't part of my core competency?
2. Don't take "liar" literally. Marketing is always guilty of Puffery, and in the US this is acceptable. Datasheets always have specifications which, if taken out of context or tested outside the conditions in the tiny print, can be proven wrong. In the market, to remain a viable business, you have to "puff" as much as your competitors do - look at beer, cigarette, car, computer advertising. A company that lets the Engineering department write the marketing materials doesn't survive long. Frankly, our materials are a whole lot closer to reality than our competitors - we've never published wholesale lies, to the best of my knowledge, which isn't always true of those I've competed against.
3. Yes, really.
4. Yes, I know that's bullshit. Tell that to my CEO and CFO.
5. OK, we'll lose your business - that's $3 worth of revenue that we won't receive, once. We hope that you'll see the value of our products in the future and be willing to consider us then.
And the worms ate into his brain.
1. Is usually not that easy, if it's licensed for use in the driver there might be bits of it many places. It'll take developer time and lawyer time to do, or you could risk a huge lawsuit.
2. Being the honest loser of an OEM contract doesn't put food on the table.
3. Common end users? No. But certainly some developers in the community will start asking hard questions and expect answers. If the driver isn't working well enough, the negative PR will hit the company, possibly worse than if they had no driver at all.
4. It doesn't matter if we "know" it's bullshit, as long as PHBs believe it
5. Invisible and unmeasurable sales. Nobody will know and can put in a business case that this is why you bought that router.
I see a lot of these answers, that just say "well it's not a technical problem, so it's not real". Legal liability, losing contracts, bad PR, security concerns and no proven business case are problems even if they're just perceived to be problems. Unless you'd like to buy out some of these companies and bet your fortune on these problems not being real. Yes, I'm being overly pessimistic when I answered here, but it's too easy to think all they needed was a grocery list from slashdot. That's what everyone is looking for in a business case, what's the weaknesses you didn't include and is your downsides soberly assessed? Business cases that only deal with the sunshine scenarios don't usually get through.
Live today, because you never know what tomorrow brings
If that was true then Atheros should have gone by now. They open sourced their drivers almost a decade ago, yet they are still around. In fact, due to the excellent Linux support, I've only been buying and recommending to others the Atheros chipset WiFi cards. Not to mention all the extra abilities it gained from the OS community (like the ability to simultaneously act as an AP and client, which brought about mesh networking and community wifi).
They probably gained a lot indirectly in the form of higher sales of hardware due to this, plus the reduction in costs because they didn't have to pay a dev team all this time.