Slashdot Mirror
Leveraging Linux when Hardware is a Commodity?
AKInnovation asks: "My company produces peripheral hardware used in commercial applications, such as retail POS. In our market, amongst other such hardware manufacturers, we are the only ones to offer Linux software solutions (drivers). This distinction has recently won us several large accounts. When the hardware becomes a commodity, and you must compete on the software side to keep the money coming in, how can releasing your code as Open Source be rationalized to management?"
It is my opinion that the future of Open Source is "General-purpose codebase re-applied to Custom Computing Scenario".
how can releasing your code as Open Source be rationalized to management?
1. Release your code.
2. Manage your contributing developer community. (Sourceforge)
3. Grow the codebase by doing #2 well.
4. Establish good working relationships with customers, customize the codebase for them. (Customers == people who want customized work.)
5. Add a services department that does #4, and only #4, when you've got #2 under control.
OSS is the grand unifier which sets the standards - pretty high - for everyone. The way you differentiate is by really identifying the needs of your customers and then using the OSS machine to deliver on those needs
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
Software is fast becoming a commodity too - if you're in the US, you're competing with code churned out in India, and pretty soon those guys are going to be undercut by code factories in places like the Philippines, and so on, and so on...
Very few organisations can rely on software for their *only* competitive advantage... Microsoft are making game consoles, Red Hat are branding themselves as a solutions provider and SCO decided to pursue racketeering as a business model.
So compete on service; offer value-adds like training and consulting, facilities management, hosting, colocation, monitoring etc.
... at first not get that "POS" stands for "Point Of Sale" .. ? ;p
If you are the only ones in your market to "offer Linux software solutions" then you are shooting yourself in the foot by open sourcing the drivers. In other words the only thing that seperates you from your competitors right now is your linux drivers and by giving them away you are levelling the palying field and removing your main advantage.
This is why you may struggle to convince the management that open sourcing your drivers is a good thing(TM). I think your best chance of convining the management is if you present to them a number of case studies of companies open sourcing drivers. For example, Intel releasing modified open source drivers for Centrino chispets. I also think that you will need to present an effective system for managing the open source project.
4. Establish good working relationships with customers, customize the codebase for them. (Customers == people who want customized work.)
How does GPL treat for-pay customized code in terms of what must be released in the open to the public vs. can be kept closed and confidential? If a customer pays to add highly proprietary features added to a GPL codebase, does GPL force the release of that code? Can a company that is using GPL code contract with its contirbuting development community to make closed-source customizations of GPL code under an NDA? If the customer with the customized GPL-derived code then sells that software to their customers or franchisees, does that force the release of the code?
I'm just wondering how the open/GPL world of free software interfaces with the closed world of proprietary business innovations.
Two wrongs don't make a right, but three lefts do.
Just tell you boss what he is getting:
Thousands of potential developers, all working for free.
Have an in-house team of programmers review the code before it is made the production release of course, but otherwise, let the code go free.
I think a lot of people would be willing to help improve the code in general in exchange for the chance to customise it to fit their own needs.
As I understand it, yes. The GPL requires release of the code only to the customer who pays you for it. You must transfer to the customer full rights to the GPL original code and to your updates to that code. The customer then has the right to release that code under the GPL - or not, which is probably what they will choose. The GPL does not say that you must release back to the developer community, only that you must release full GPL sources to anyone to whom you sell the code. If your customer then sells your code on, they are equally bound by the GPL to give the code, with full GPL rights, to their customers.
I.e. A business can add their business idea to GPL code (including implemented by you) for their own, essentially in-house, purposes. However, they cannot take a lot of GPL code, sprinkle a few neat ideas onto it, and market the result as a closed source package.
Consciousness is an illusion caused by an excess of self consciousness.
Why would the company bother releasing gamepad drivers for Linux when they know there is such a minute market share? 90% of Linux hardware drivers are made by hackers who own the hardware and need to get them working to satisfy "that urge."
If you look at the Business relationship you have with customers, then Open Source can be a very strong marketing tool.
Many larger contracts for systems require that either the (embeded) source either be provided or placed in escrow in case the company goes under, drops the product, etc. Such a requirement is simply being smart in a business relationship.
And, there is no assurance that just because your company is large, it is going to survive.
So, if you provide open source, your sales types can start hyping that very fact as a HUGE feature, that you want to step up to the plate and work with your business partners to protect THEIR business decisions, yada, yada, yada.
Make your money doing customization of the code. (Your customers won't want to, that's why they came to you in the first place rather than developing their own solution.)
Forget the "thousands of eyes" arguments, it means nothing to your customers from a business perspective. It may help convince a geek, but it wont fly with the guy who signs the PO.
----- Lotus Super 7 - A real car.
...to this;
Sell it directly, sell it as part of a hardware device, give it to a friend, give it to the world...the GPL does not discriminate.
Microsoft is not selling at $50-300 a seat because of functionality. It's selling at that rate because of branding and, to some extent, API control. Branding matters, even in commodity markets. Three companies that spring to mind that also use both these factors (branding, access to something unique under their control) to sell into markets that are considered "commodity" are Apple, IBM, and Sun, all of which do very well selling hardware at prices (and profits) much higher than the Wintel norm.
Oracle isn't selling their database product, though for ease of understanding, that's what they claim to be doing (kind of like mobile phone companies "sell" mobile phones - well, they don't, they sell the service, but they market everything around the phone itself because that's easier for consumers to understand.) What they're selling is the consultancy and support required to set up a tremendously complex database on the technical level. This model hasn't worked that well in some areas, such as selling GNU/Linux distributions, but that's because... erm... well... GNU/Linux isn't - contrary to popular belief - something that's hard to set up.
Right now there are relatively few companies that are selling mass market boxed software as software. Most are selling support contracts disguised as boxed software. There are exceptions, games for instance, but only because every game is very specific. Anyone can write an "Excel compatable spreadsheet" but Unreal Tournament is always going to be the only Unreal Tournament in existance. And it's noticable that prices of games plummet after a few months on the shelves, $50 dropping to $9.99 (pretty much the cost of the materials, box, printing, distribution, and retailer's cut) isn't uncommon.
Would you start a company to sell operating systems? Do you have an idea for an office suite that you'd like to sell? Unless you have a major gimmick in your business plan, you're unlikely to even enter the market.
So how does supporting Linux help you if what you sell is a commodity? Well, all it does really is add value, but, as your boss can probably testify, it doesn't add enough value that increasing the price of your product wouldn't destroy your sales. However, there strikes me as being several solutions to this:
The first is you don't need to support "Linux", you just need to support users. Not all your users run Linux, indeed, not all of them run the operating systems you want to support. Linux, BSD, etc programmers have proven time and time again that they'll support anything with a clock if you can plug it in and if the documentation exists. You already have that documentation - you needed it to write the Windows driver. You can publish that documentation at minimal cost to yourselves, and increase your marketshare without needing to raise costs. The Linux "community" will do the programming for you.
In a reasonable world, that's what you should be doing anyway. Back in the 1980s, most computers I bought - from anyone from Sinclair to Commodore - came with so much documentation you could attack them with a soldering iron and know what you were doing. Even the Amiga 500+, released in 1991, came with circuit diagrams in the manual, and that's one of the most complex non-standard machines I've ever bought. We've suddenly evolved a rather bizarre level of secrecy which ultimately hurts users and also harms innovation.
The second is you can encourage the use of open standards internally and externally. Open standards help level costs, and even when they don't, people will choose a $50 widget over a $40 widget if they don't need any special drivers for the $50 unit. One of the problems here is that manufacturers rarely reali
You are not alone. This is not normal. None of this is normal.
A key dffierence between a BSD style licence and a GPL one is forking and merging.
BSD Allows unlimtied forks, but you cant merge forks back in (unless they remained BSD)
GPL Allows limit forks, but you can always merge forks back in.
What this means is if a competitor takes your GPL code, you can merge back any advances they made in their copy back into yours.
Thus in this respect the palying field is kept level.
Your advantages are that you were first, you know and undertand to code/product better, you reputation and such. Also if your code sparks interest you may end up with volunteers contributing.
In the end a competitor may be able to catch up with you if you open source, but they could not over take in this area.
Or how to sell it to management? The reasons it is a good idea are listed by other comments, but unfortunately selling it to your bosses may have nothing to do with why it is a good idea. If you have forward thinking, long term strategy bosses you have a much better chance. If they are convinced that having software for Linux is their competitive advantage, they're probably not going to let that go. Right now they may even be right. Sharing the code before the competition has started developing their own solutions may kill a market advantage. If they open the code at the right time, say just before the competition rolls out their beta software that they spent months developing;), then your company can leverage the advantages of open code (i.e. outside input, bug checking, increased customer input) as the NEW advantage.
Insert pithy comment here.
If your only edge is the POS software, then don't release it as open-source. That would ruin your company, and I thought that was pretty obvious. The only time it would make sense to make software for a POS thing open-source is if the SOFTWARE is a commodity (Linux is an example of this, except with operating systems). Otherwise, it would simply give your competitors a boost.
Of course, if your customers want access to the source, then you can give it to them under a restrictive license (so they still have to buy your hardware). But you don't want to lose your competitive edge.
If you sell common hardware, the only two ways you can really make money are on support and software sales. Opening your code source will only serve to generate competition when other vendors take your source code and start offering their services for a lower price. Then you're back to square one: the software becomes a commodity and you can only make money on support. Which, by the way, the OSS community also strives to make freely available on the internet.
Don't listen to these wieners. Keep your code closed and keep your company in the black.
For instance, you can do anything you like with Linux in the comfort of your own home, so long as you don't distribute the result. But distribution can become a thorny issue if you're careless, and as a result the GPL offers relatively weak protection of your company's super-secret algorithms. After all, anyone who *legally* acquires part of the code, now has full GPL rights to the whole thing, tasty bits included.
Of course, this is only very slightly less protection than, say, trade secret law offers. In either case, the rule of thumb is to keep your secrets secret.
Companies do occasionally get stung by this when they fail to realize that they are actually "distributing" code. Witness Linksys, which was forced to give away its changes to the Linux kernel, probably because it simply never occurred to the developers that selling a device constituted "distribution" of the image in the firmware. The poster's company (or its customers) could conceivably run into the same problem down the line by selling POS units with the customized GPLed drivers installed.
Compare to TiVo, which had the sense to put the interesting code in separate executables that don't derive from anything GPLed.
Quantum mechanics: the dreams that stuff is made of.
no text.
Sure ... your code is open source, and any capable and willing Tom, Dick, or Jane can hack it and support themselves. You wrote it, so you (in theory, anyway) know how it works, how it fits together, and besides, selling and renewing support contracts is a much smarter way to make money than selling software. Work the support angle and try to get some marketing wonk to give you some marketing-speak to back it up.
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. (Einstein)
How does GPL treat for-pay customized code in terms of what must be released in the open to the public vs. can be kept closed and confidential?
You don't have to release it to the public (if there is an NDA in place, for example), but you do have to release it to the customer.
If a customer pays to add highly proprietary features added to a GPL codebase, does GPL force the release of that code?
Only to the customer.
Can a company that is using GPL code contract with its contirbuting development community to make closed-source customizations of GPL code under an NDA?
Yes.
If the customer with the customized GPL-derived code then sells that software to their customers or franchisees, does that force the release of the code?
Yes.
Your questions are covered by the GPL FAQ
If you're one of the developers in this hypothetical scenario, you'd be wise to convince the customer that keeping the changes under NDA will harm them in the long run.
By keeping the changes to themselves, they're essentially making their own fork. Now in general, forks of GPL'ed software is OK, because each set of developers has access to each others' work, and eventually the forks will merge.
In the case of one of the forks being closed (under NDA), you're essentially closing yourself off from the rest of the development, because if you want to keep the software up to date, you have to work harder and harder as the code bases diverge more and more.
This was almost answered correctly.
1. Unless they have the copyright for contributions assigned back to them, EVEN the maintainer does NOT have the right to relicense the contributions under a different license. So that means licensing the software to the customer under the GPL. Or requiring developers assign copyrights back to the maintainer. If they do that, there is no reason you can't use the codebase on which you hold the copyright to make derivatives and license under ANY license.
2. If you do use the GPL to license to the customer (which has the benefit of less overhead in time and money, and more developers willing to work on your project), then you have to give the customer the source, and the customer has to give the source to anyone they distribute the program to. Niether the customer or you have to give the source to anyone you do not distribute binaries to however.
Also good to note, when you are required to give the source, you either have to give prominent information on where this can be gotten or you have to give machine readable source directly. YOU CANNOT MERELY GIVE THEM THE PUBLIC SOURCE, YOUR CHANGES MUST BE INCLUDED.
Whilst this has been answered in terms of the GPL already it's worth remembering that as the author of some software you're entirely free to dual license it.
So people may have the GPL version for free, and customers can be given an enhanced version which is non-GPLd, either in source form or just installed as binaries.
I worked for a company that successfully managed to sell contracts of a "supported" and enhanced piece of GPL'd software they wrote.
Not sure if I'm kidding or not.
The reason that a lot of people shy away from Free software is the fact that they are worried about it not being well supported. Which means regular updates, someone to contact in case of a problem, and an expedient repair to their problems. So if you are selling Free Software then be sure to emphasize the support aspect of it and what it does. People need to feel comfortable with their products.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
depends on the situation. If company A creates software Foo and releases it under the GPL, nothing says they are not free to release that same code under any other license as well (though anyone who got the code under the GPL can still distribute it under the GPL). This also means that the company could release Foo under the GPL while releasing a version with additional features under some other license.
The problem can be in situations where A releases Foo under the GPL, then B submits a patch to Foo wich makes it into the codebase, A can no longer release Foo under any other license than the GPL unless B where to assign the copyright to A.
Fruthermore, if A distributes Foo to company C, then C can do whatever they want with the codebase and keep it in-house without distributing it. If they distribute it, then they must do so under the GPL or buy an alternate license from A (assuming both that A is willing to offer an alternate license and that they own copyright to the entire codebase).
Famous Last Words: "hmm...wikipedia says it's edible"
Lock-in and switching costs are another aspect of the purchase decision that are worth considering. Whenever you buy a new system of any sort, there are costs to switching from whatever you are using now and risks of being locked-in to the vendor that can increases the buyer's long-term costs. While your company wants to make money down the line with service and support, by going the open source route, your company would be reducing the buyers' future lock-in costs (and therefore current switching costs) which should increase current sales. It creates the relationships on which to build the future support business. Sure with open source there is less certainty that they will go with you for support, but your foot is in the door and if your products and support are good enough, the relationship should be strong enough to win that future business.
I've finally got around to changing my sig
Ahhh, the incredible Slashdot Business Plan at work again: ./ credo this is true (and yes, IBM pulls this off in some markets), what they fail to grasp is that the current situation makes profits for the company as it is. Switching from a lucrative business model to something different because IBM does it in a different market will not interest the MBAs too much.
1. Take money-generating, competitive-advantage, one-of-its-kind software
2. Open Source it so the competition can have it
3. NO MORE (or much less) PROFIT!
Seriously, if you have this incredible competitive advantage, you *don't* want to Open Source it. Sad but true. I'm a big supporter of OSS, but I don't think everything under the sun should be Open Sourced.
Some people here suggest that selling support and services might be a better way of doing business than selling the software itself. While in the
And, out of curiosity, does IBM Open Source their Point Of Sale solutions? They certainly sell a lot of them...
> The GPL requires release of the code only to the
> customer who pays you for it.
Totally wrong.
Payment has nothing to do with it.
Here is the beginning of section 3 of the GPL:
-----
3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:
* a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
* b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
* c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)
-----
IANAL, but as I read this, the issue is simply distribution - of the executable or object-code. You can download Linux, write a new scheduler, and release only part of your scheduling code, and that's fine under the GPL until you "distribute" a binary of your modified kernel. Then you are required to release the source.
Also, one of the replies to the parent claims that Netgear was "forced to release changes to the Linux kernel". Once again, the GPL cannot force anyone to release his/her code. The GPL is a *license*, not a contract, and it stipulates requirements for use of code licensed under it.
If company Foo is violating the GPL by releasing modified binaries of GPL code without releasing the source, company Foo can resolve this in at least two different ways:
1. release the source code
2. stop using the GPL code
If they opt for #2, it is likely they can be forced by the courts to pay a fee to the copyright holder (which is frequently the FSF).
The GPL is *not* enforceably viral - violators can always choose option #2.
After all, you only have to release source to those who you give programs too. In the case of hardware, use the OEM CD to fufill your GPL obligation and get it over with...then you won't show up here and those who want source will have it ...and never complain..get it. Also, password protect your downloads to limit them to registered hardware users. That way you're not "distributing" the drivers on line, only providing updates to your customers.
remember, your business is selling devices, not software...that's just a service. The trap many "hardware" vendors have fallen into lately is trying to sell $20 plastic hardware for inflated prices by locking up the drivers...it's a dead business model, you gotta adapt!