Slashdot Mirror
Red Hat to Coax Code Contributions From Companies
Stony Stevenson writes "New Red Hat CEO Jim Whitehurst has hit out at enterprises, bemoaning that billions of dollars are wasted each year because 95% of companies won't share code.
Speaking at the Open Source Business Conference in San Francisco, he said his company must take a larger role in urging enterprises to participate in open source projects and, in some cases, coax code contributions out of companies that have made in-house improvements. He now feels Red Hat should lead the way
'It should be part of Red Hat's job to define development in a new way, and get companies to work together' on shared projects, he said. The joint development projects would be designed to cover non-competitive parts of an industry, with individual companies still focused on their own competitive business applications."
My first read of the title was WHAT? Code for coaxial cable? Me no get it.
While I agree with Jim's sentiments being an Open Source advocate and all, I think Red Hat has no right to attempt to coax or coerce companies into giving away code. If OSS is the future, then it will happen, with or without Jim's little tantrum.
It is ridiculous for a CEO to attempt to paint his company as some kind of inspired model upon which other companies should remodel themselves. Aside from being futile, attempting to turn the Old Establishment around does nothing but hurt the nascent organisations that will make up the New Establishment by casting doubt on their methods and making them look like they are non-viable without the support of the Old Establishment. I can see Ballamer right now, in a room full of beaureaucrats saying "See? OSS is all about getting handouts to survive." Furthermore, it is brining wolves in amongst the lambs.
If Jim wants to make a difference, he should fund new development from emerging pools, like Google with the GSoC (not that I'm a Google fan, but that's another story), or IBM with their paid employee time contributions, or EnterpriseDB with their backports to the PostgreSQL team or Sun with their (somewhat clumsy) contributions to the OSS community. There are plenty of companies already doing what he says, he should be happy for that and encourage those already willing rather than attempting to project an agenda onto those it does not suit.
Having a whine that companies in the Old Establishment should be putting free money into his playpen is a naieve, futile and potentially harmful thing for Jim to be doing. It'd be better all round if he put his money where his mouth is rather than asking others to put their money where his mouth is.
I hate printers.
Red Hat still has proprietary, non-open source products of their own, such as the Certificate Server products they purchased from Netscape. Shouldn't those be open-sourced before they complain that other companies don't open-source their products?
If companies start sharing code, there will be less code that needs to be written in-house, which means some people are going to be losing their jobs. I'm sure they'll be really thankful to Red Hat.
There was no mention of licenses; open source licenses include the MIT and BSD licenses, and many similar licenses that permit keeping the source to derivative works closed. And in fact, Microsoft itself uses a lot of BSD code in Windows, without sharing any of its source.
I was very unhappy about signing such a contract, but I needed the work.
I never really asked why they wouldn't even allow source under the MIT or BSD licenses. I expect that it was a lack of education. If that's the case, I expect their attitude is not uncommon, and sorely needs to be corrected.
For what it's worth, my current employer (I'm no longer consulting) releases the source code to its Linux and BSD drivers as open source, with their source code being provided on our installation CDs.
Request your free CD of my piano music.
how businesses usually think. Share their stuff with others? Give other companies an advantage that WE paid for? NEVER! So yes, it's a huge waste. But you'll have a hell of a time convincing them to change. Um, imho.
Nevermind the trollish title, this guy's disposition is asinine. Enterprises should be asked to share more code in the interest of the free software movement and adhere to the spirit and not only the letter (instead of forcing people to GPL3 their stuff to avoid being "cheated"), ok.
But if the license allows to keep the software in house and do whatever they want with it, then they are rightfully entitled to do that. A company with its business model "rooted" in free software ought to respect it.
Chant of the '60s revised for the 21st century.
/. main page.
Inspired by the
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
After seeing the absolute filth that is spewed out of most corporations' in-house "development" teams, I'd be very wary of this.
Perhaps a better word would be to encourage or evangelize. Coercion should have no place in business and the word coax can mean either to benignly encourage or to coerce.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
It may be news to a CEO, but programmers who write code (and their children) want to eat and have roofs over their heads, too.
It could also be that the products they have acquired are encumbered in such a way that prevents them from releasing them as open-source. I think that was the position of ATI or nVidia for a while on the graphics drivers - they licensed technology from other places that wouldn't let them release the code.
"Anyone who [rips a CD] is probably engaging in copyright infringement." - David O. Carson
Its easier to keep it in-house then to hire a lawyer to make sure everything is going to be OK.
Technically, if they share code, they can do more with their business, thus drawing in more consumers and hire more people to do more work.
If companies start sharing code, there will be less code that needs to be written in-house, which means some people are going to be losing their jobs.
That is "fixed pie" thinking. Underneath your statement is an assumption: that there's only a fixed amount of work to be done, that the amount of work "pie" available is fixed and unchanging. That simply isn't true.
The real purpose of a job is to generate wealth. Janitors create the wealth of a cleaner environment. CEOs create the wealth of a smoothly running organization. Factory works create the wealth of manufactured goods. And so on...
If wealth gets generated more efficiently, everybody benefits, because there's more total wealth to be distributed. An organization that "eliminates" a few positions is then wealthier, which then makes it more likely to increase its product base, thereby creating more positions. While there are cyclical deviations and occasional abuses, (generally covered by existing laws) it's largely a self-regulating system.
Don't be afraid of change. Be afraid of stagnance.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Disclaimer: I am currently a Fedora Translator
Fedora currently uses Transifex, which makes all translations go Upstream, thus sharing what we've translated, with other Software Projects.
Check out Unsealed: Whispers of Wisdom! http://unsealed.k3rnel.net It's an action-RPG about Open Sourcerers.
... than the code produced by most teams.
Re-use is not just about shoving code on a server and letting people copy it. You also need design, documentation, comments, testing, and ideally some level of support.
A lot of in-house code comes with none of these and as a result is worthless.
Reduce, reuse, cycle
Am I permitted a chuckle?
Seriously though, he should try to get enterprises to contribute usable user documentation, not code. If he succeeded, in the fullness of time, using FOSS products wouldn't be a never-ending easter egg hunt.
I'm a Programmer. That's one level above Software Engineer and one level below Engineer.
If I'm the CEO of a big-ass Insurance Company, Bank, Airline or Widget Manufacturer and I just invested a bajillion hours of developer time into creating software that gives me an advantage over my competition, why would it be in my best interest to give my code away?
The joint development projects would be designed to cover non-competitive parts of an industry, with individual companies still focused on their own competitive business applications.
No such thing as non-competitive parts of an industry. If two companies say, make toilet paper, and one of them has a custom program that let's say, saves energy by turning off unused lights in their buildings. That company saves money on their power bill. That is still a competitive advantage over the other company, even though it has nothing to do with the industry. Why would the company that developed that give that to a competitor, and allow that competitor to improve their bottom line? Every piece of doing business is a competitive advantage. There are no insignificant parts of any business.
I don't respond to AC's.
Big Corporation goes to Big ERP vendor and says "we want your product to provide functionality X". Big ERP vendor goes, sure, no problem we'll do it for $X and if you want support sign over the code and give us an extra $Y to support it. Big Corporation goes "gosh, that's not too great a deal. But no one at Big Corporation knows how to do this so we *are* at least buying their obvious expertise". The expertise being obvious because it is expensive. They also ignore the fact (or are clueless to it) that in a series of cubes somewhere there are several applications programmers which, over a period of years have already created code for the existing business application to handle the business rules and could probably port it quite nicely, thank you.
So Big ERP Vendor develops and installs the application with functionality X (after the sales people scoot away with their bonuses). Big Corporation lays off said applications programmers losing years of very expensively obtained expertise. Since the programmers of Big ERP vendor have no clue of the business rules (even ignoring the language and/or cultural differences offshoring may create), it takes a number of iterations, much lost productivity and large amounts of $$$$$$$$ to finally get it right. Sort of. It looks slicker but often acts clunkier.
So Big ERP Vendor goes to Another Big Corporation and says "we have this module with functionality X which is based on best practices and with minor modifications in your business processes would work great for you."
So Big ERP Vendor sells the module that Big Corporation paid for to other companies, including possible competitors to Big Corporation. And loses any business process advantages it may have had.
So thank God they never went open source!
putting the 'B' in LGBTQ+
You are not entitled to your opinion. You are entitled to your informed opinion. -- Harlan Ellison
Your analogy assumes that the existing open source code solves the problem and that universities all work on the same static issue - which is far from true.
I for one am glad that multiple universities work on the same problems/research projects in their own unique way Open source isn't an analogy of efficiency in the example you make because those efficiencies are already here - BOINC, Clustering, Linx et all and other types of programs being a showcase example.
Open Source and LGPL libraries are where its at - give you a foundation to save time/money on the mundane and repeatable tasks but allow - such as in your example - universities to do the research as they see fit.
On the inverse side, universities are a poor example of the efficiencies because they often already share the mathematics, theory and processes of their research and the software is merely a framework/testcase to prove it - not necessarily it its best/most reliable/proven way. SOrt of like a test case that works but isn't pretty. Would sharing that make other universities spend less time? not sure since other universities may prove their research in other ways - cheaper/more efficient/more reliable or simply prove things wrong.
Its the competition & differences that make university research strong and forward thinking - not necessarily the foundations that are common between them (which again, for the most part already exist)
Companies who write their own code internally are stealing business from professional software developers. Let's outlaw internal code development.
/sarcasm mode=OFF
Companies whose IT departments repair/upgrade/modify their own computer hardware in-house are stealing business away from professional hardware repair shops. Let's outlaw internal IT hardware techs.
Companies who have internal marketing departments are stealing business away from outside professional marketing agencies. Let's outlaw internal marketing departments.
*Companies who have their own in-house attorneys and legal departments are stealing business away from professional law firms. Let's outlaw internal legal staff/depts.
And the list can go on, and on, and on.....
(*) Actually this one might stand a chance of coming to fruition once the lawyers figure out that they can get even richer and gain more control by raping the snot out of big business by organizing amongst themselves to force all businesses to hire private law firms instead.
If you contribute back to a F/OSS project, such project grows and attracts new contributors, who will in turn give you stuff for free.
Win/win.
You make your little changes to an open source library. Ten revisions of that library go by. With each revision you need to update and retest the code. At some point the effort and cost you expend will be greater than the competitive advantage you think you might have. The truth is if you've thought of it, 20 other companies have done the same. At least if you roll your changes into open source, then your project will benefit from people correcting bugs in your contribution and adding features to it.
That's the broken window falsehood in a nutshell, with a false dichotomy thrown in on the side.
Money and staff spent, in this case, re-inventing the wheel, is money and staff not spent on the core business activities. So,even if it's learning from others mistakes, going FOSS saves effort and that in turn boosts your core business activities (assuming reinvestment and not skimming by the execs). Software is only a tool, an enabler, for those core activities. In case you missed the last 25 years of computing, it's not an XOR choice between using the open source development model and making a profit. In fact, it's been show again and again that it's not only profitable, but makes your company more recession-proof. We've been through a few now and have seen the benefits.
Beta is broken and the link to classic doesn't work. Stop wasting our time or there won't be anybody left here.
Maximum RPM was last updated in 1997 and the suite has since seen some rather sizeable changes. The reason I was given back in 2001 or so regarding the absence of updates was higher priorities elsewhere. He should look in-house before throwing stones at others.
Dog is my co-pilot.
I think the original comment (lack of education) is most likely correct. I think you misunderstimate the stupidity of modern IT management. There is a class of people who read all of the MS FUD in trade journals and take it as gospel. To these people, open source means copyright infringment, patent risk, etc.
But if you want a semi-legitimate reason to be afraid of open source, I can think of one. What happens if the consultant finds an open source product that can be slightly modified to become the system he is supposed to be building? If the project is budgeted for 1000 hours and the goal is to build a blog that works just like Slashdot, what if he books 990 hours surfing for pr0n, downloads Slashcode and strolls in the door with an invoice? This is an extreme case, but I can think of many projects that can be broken down into pieces that can be handled by open source.
I once had a large project to build a highly specialized XML editor to produce files that could serve as lab reports and also be parsed into a relational database. I tried very hard to find open source products that would expedite our development, but I found nothing I wanted to use. As I planned, budgeted, and launched the project, I was worried that someone would find an open source project that I missed, which would have proved that I wasted money on something that could have been downloaded for free.
I made quite a career for myself by exploiting open source. It's kind of like potato chips -- once you get started it's hard to stop.
Rarely do companies engage in custom software development to produce something reusable. No one rewrites databases or web servers (except, perhaps, Google) or operating systems. What people do write over and over (and then not always) are custom solutions that tie a bunch of crap together and make it accomplish a business goal. Making this software "sellable" would require four times the effort and three times the complexity and then the money would be wasted on consultants who charge $200 an hour to get an overly complex system up and running. And guess who thinks they will provide the consultants? Aaaassright! RedHat.
Businesses should look at it as splitting the cost and effort of stuff that they'll all each be using anyway. In an extreme case, businesses could even eliminate Microsoft as the middleman between them and their computers if they got together and funded work on operating system software that they would each be using anyway, and in the end they would be more free to customize it for their own needs.
Twinstiq, game news
I'm sure a lot of this code gives different companies different advantages over others. The point of a business is to make money and find ways to keep ahead of the competition. I will never understand why people want all of this source code to be opened up to the public. Stop crying...write it yourself or pay someone to write it for you. Open source is a great way to help keep everyone on the same level. Whats that word that best describes China's government? Oh yeah...communism. My blood pumps capitalism ladies and gentlemen. Give me my damn paycheck and keep that source code locked up. Cash money 99-2000. Deal those cards like the palm trees in Puerto Rico......HOT
>Trying to paint OSS evangelism as trying to get "free money" is naive and shows a complete
>failure to understand how OSS development cuts costs for participants.
See, this sentence sums up why I wonder why businesses would want to jump on the OSS bandwagon.
It's great if you're a startup, as you can leverage the work of other people. But if I'm already the Goliath that everyone is chasing, it is in my interest to keep barriers to entry into my market as high as possible - why would I want to make it easier for other participants?
Sure, it might cut my costs, too, but I'd rather keep my costs a little higher because I have to do more in-house creative work than lower the costs for my competitors so that they can more easily catch up to me without the investment in creative work that I've already put in.
A work that expires before its copyright never enters the public domain and thus enjoys eternal copyright protection.
We've made lots of money selling other people's free work and we would like to make more money buy selling other stuff we didn't pay for.
Hey, maybe it just as simple that people in these enterprises think Red Hat's a bunch of assholes. Maybe Red Hat is dating their sisters and showing up uninvited to their parties. Maybe Red Hat is prank calling them at all hours.
Shit, I wouldn't share code with people like that.
Has they been Microsoft, they would have put out a statement extolling the virtues of companies that do not violate IP by buying customized business solutions from Microsoft itself.
They've been sharing chunks of code for a while now.
http://nocturnal.insomniacgames.com/index.php/Main_Page
Not to mention that it's BSD'd code which means that other companies can actually use it! So, sorry, but RH has been beaten to the punch. And from an industry that's *far* more competitive to boot!
Request your free CD of my piano music.
Right, if you don't understand the benefit of a community of people getting behind your product, helping to produce it (and helping themselves become experts at it in order to consult) and then having a pool of eligible consultants who know your product down to the code level, you probably are better off leveraging SAP consultants at $$$/hour to save cash; your logic would be consistent that way. Just remember one consultant has it in their best interest to serve you best (you can hire another one from the pool), and the other has it in their best interest to waste your time (paid per hour, and the only way out is to start from scratch... the hole gets deeper by the hour).
If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.
But then someone turned me on to Emacs and the GNU Manifesto. That's what made me decide to take programming seriously, and to do what it took to learn to do it well.
Request your free CD of my piano music.
One problem that I've seen in Perl is that some Linux vendors have been making their own fixes, but never sent them upstream to the Perl core to be applied. Its bad when its a normal bug fix. When its a security fix, its unacceptable.
"Can't rape the willing!"
Hardware companies care only about selling a product and keeping the customer satisfied for the first 30 days after which they can't return the said hardware. They don't care if the patches to Linux don't get upstream because as long as the hardware works fine with the version of Linux that they hacked up and pre-loaded, they're customers will be temporarily satisfied.
And when it comes time to upgrade the Linux OS in a year or two, the new version won't work, so the customers will be forced to buy more "up-to-date" hardware with more hacks and band aids. Even presumably FOSS-friendly companies like System76 change the pre-installed Ubuntu on their laptops by adding tons of hacks and then don't bother to even report them upstream, much less to develop a sustainable solution.
See the following threads on the System76 forum:
Real Linux drivers for System76 laptops, NO thanks to System76
Merge System76 Driver with upstream kernel and HAL
Although I can't find the original anymore, this same concept was presented in 1999.
http://portal.acm.org/citation.cfm?id=1268359
Like Heaven's Gate or Jim Jones or the Super Adventure Club?
A big bundle of twisted pair looks too much spaghetti code. Coax code can have the same problems but is not as bad.
LedgerSMB: Open source Accounting/ERP