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.
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.
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)