开源软件社区的发展需要新鲜血液的补充
时间：2008-04-09 来源：linux论坛
Fresh blood - the new fight for open source
他是美国一家大银行的Java程序员，他们公司大量地采用了开源软件产品，他本人非常热衷于参与开源项目，但是他的公司对这却不是这样想的。
对他来说，回报开源社区是件很正常的市场，但是因为雇主的原因，他成为了佐罗（zooro），暗地里为开源社区做贡献，因为他的工作性质决定了，他这样做存在着很大的风险，因为他现在公司的时间里创造的软件专利等都是属于公司的，但是他把这些捐赠给了开源社区。
而这一切就是目前大部分开源项目所面临的问题，这些项目的开发者是来自收雇佣的程序开发人员，这些开发人员受到他们雇主的影响很大。
我们就不用说类似于SCO公司对Linux的起诉，或者微软公司不停的腻歪，开源项目面临的最紧迫问题是缺乏足够的志愿者，需要他们写出足够的代码来支撑起这些开源项目，否则这些项目的发展就不能跟上业界发展的脚步，就无法满足用户的需求，就更谈不上和专有软件展开竞争了。
Meet "Zorro, master of the night". Zorro is a Java developer for a major US bank that makes widespread use of open source software. Zorro is keen to participate in open source projects, too, except for one thing - his employer won't let him.
"For me, to contribute back to open source, I'd have to become 'Zorro, master of the night' - you have to go underground," our programmer said during last week's MuleCon in San Francisco, under condition of, yes - you guessed it - anonymity. "You have to understand the risk that we take."
We're so deep here, Zorro isn't even his real alias - he just plucked it out of the air - but his case is typical. Like many developers working for The Man, his time and any intellectual property he creates during work hours belong to the company.
And that's creating a serious challenge when it comes to open source projects, as they rely on the contributions of volunteers who are paid for, and effectively owned, by employers.
Forget potential litigation from another SCO. Get over the shadow of Microsoft. The real challenge facing open source is how to bring in fresh contributors and code contributions to sustain projects and meet users' needs. Without fresh blood, projects progress relatively slowly and are likely to stumble towards meeting the requirements of the end user, the consumer of IT.
Jim Whitehurst, Red Hat chief executive, last month joined a growing chorus voicing frustration with lack of corporate participation in open source projects. This means that IT projects do not get the direct input they need from a requirements perspective. For all Red Hat's success, Whitehurst knows that unless more users participate, Red Hat faces a significant challenge filling out its technology stack, delivering software users want and - ultimately - growing its business.
Drumming up corporate involvement also explains the motivation behind the creation of companies like the Collaborative Software Initiative. This is working to bring projects to open communities that might actually be useful, as opposed to peddling some vendor-filtered dream of what it wants you to want.
The challenge is real. Open source has done well in operating systems and middleware. Fedora and MySQL are regarded as successes. It's the fledgling projects that face the challenges as the industry tries to define what's next in open source middleware and applications after things like JBoss?
Open source projects are being particularly challenged because many large organizations - such as Zorro's employer - suck in huge quantities of open source code, but are not returning changes, which could have been useful to the community at large.
Fortune 500 companies who can't give the code back are the biggest challenge facing MuleSource, an open source service-oriented architecture (SOA) start-up from San Francisco, says chief executive Dave Rosenberg.
MuleSource customers include large banks, big financial institutions and major retailers and their reluctance to commit, may stem legal challenges - the companies own the IP - or the feeling among the developers that their bosses know their Gmail address, and that they will get in trouble if they flout company rules.
Peer recognition is a strong motivator for many open source coders, so having to work under a pseudonym is a big disincentive, says Zorro. "We find it unfair because developers value the recognition [of participating in open source] they say, look at that Ross Mason [Mule project founder and MuleSource chief technology officer], he's smart."
When changes to the code are not returned, projects like Mule must rely on part-time volunteers and a handful of paid employees to fill the technology gaps in the portfolio, over time. With a few decent code donations, common issues could be fixed relatively quickly to everyone's benefit. The original Mule project was, after all, founded by Mason in 2003 to offset the "donkey work" associated with internal systems integration, and to spread the load by involving the community.
MuleSource has an ambitious roadmap to complete in the coming months and is looking to developers inside its customer organizations for support. The Mule integrated development environment is scheduled for May, and Mule 2.0 for the Enterprise, featuring JDBC connectors, is scheduled in the third quarter. Further out - and here’s where it gets tricky based on the level of community participation - is certification, documentation and completion of Saturn, the MuleSource business activity monitoring software that's in beta.
“The reason it’s in beta is because we need guys like you to pick up the beta and tell us what you want from the tool," Mason told MuleCon attendees. “The vision for '08 is to build and bring all these things together.”
Taking from the whole
The irony is that organizations increase their maintenance costs when they take open source code from projects like Mule in-house and add their own code. In all but a few areas companies are duplicating efforts made elsewhere, and wasting time and effort in repeating boring infrastructure programming, under the illusion they are adding competitive advantage. "There's so much duplicate effort," Zorro said, echoing Red Hat's Whitehurst, who claimed last month that "billions" of dollars are wasted each year in internal, non-commercial software development that re-invents the wheel.
So let's put down the hippie peace pipe and get real. Banks and retailers participating in projects, and sharing code for a common good ? are you serious? Yes, we are - and here's an example.
The Advanced Message Queuing Protocol was donated a few years ago by the core development team of JP Morgan Chase with Iona Technologies and Red Hat. It has since received backing from rivals including Credit Suisse, Deutsche Börse Systems and Goldman Sachs. AMQP was donated "in response to internal requirements, market demand and partners' electronic trading needs".
According to Mulesource's Rosenberg some banks and institutions have dismantled the barriers that previously stopped their staff from donating code. But they are the exceptions. "Most big companies are not sophisticated in open source. Mention IP, and people go 'eugh!'," he said.
Three objections stand in the way of end-user participation:
* Your time on our dime. With so many developers working inside companies, employment contracts state that IP created on the company's time or on the company's machines belongs to the company.
* Legal fears. Attorneys are unwilling to release code lest it expose their company to litigation in any future court case.
* Helping the competition. Companies find it difficult to shake the belief that in-house modifications to community code gives them competitive advantage over rivals and should not be released.
So how does the open source community change such sentiments? The answer is to reach out beyond the usual narrow gene pool of vendors and actively recruit large non-tech companies.
The Liberty Alliance and Web Services Interoperability organization for example are dominated by vendors, but they also got early support from major users of IT. These include Citibank, Boeing, Fidelity Investments, Wells Fargo, the Mortgage Bankers Association and US Department of Defense at Liberty. The WS-I organization, meanwhile, counts DaimlerChrysler, Ford and Freddie Mac among its members.
What's their appeal? Helped by prodding from key vendors such as Microsoft or Sun Microsystems, companies realized they had a vested interest in participating in, and shaping, technologies critical to their success; in these cases, improved access to their services online by customers and better integration with suppliers, via federated identity and web services.
Suits not sandals
The challenge for open source is to snag the interest of the business - to make business managers realize how they can save money in software development and maintenance by letting employees donate their time and by allowing their organizations to release code that's a burden to them but gold to projects. Unless there is buy in, open source software will - at best - remain invisible in the eyes of business decision makers, and - at worse - become perceived as a quaint exercise in API geekery by the IT department.
Only by convincing the business managers that it's in their company’s best interests to participate will open source attract more individuals from end-user organizations. According to Zorro, user participation in projects and groups such as Eclipse - popular with the industry but woefully lacking in end-user representation - will legitimize open source at last, providing a broader understanding and enabling individuals like him take off the mask and contribute in force.
来源：regdeveloper.co.uk
[ 本帖最后由 Send_linux 于 2008-4-10 10:06 编辑 ]
他是美国一家大银行的Java程序员，他们公司大量地采用了开源软件产品，他本人非常热衷于参与开源项目，但是他的公司对这却不是这样想的。
对他来说，回报开源社区是件很正常的市场，但是因为雇主的原因，他成为了佐罗（zooro），暗地里为开源社区做贡献，因为他的工作性质决定了，他这样做存在着很大的风险，因为他现在公司的时间里创造的软件专利等都是属于公司的，但是他把这些捐赠给了开源社区。
而这一切就是目前大部分开源项目所面临的问题，这些项目的开发者是来自收雇佣的程序开发人员，这些开发人员受到他们雇主的影响很大。
我们就不用说类似于SCO公司对Linux的起诉，或者微软公司不停的腻歪，开源项目面临的最紧迫问题是缺乏足够的志愿者，需要他们写出足够的代码来支撑起这些开源项目，否则这些项目的发展就不能跟上业界发展的脚步，就无法满足用户的需求，就更谈不上和专有软件展开竞争了。
Meet "Zorro, master of the night". Zorro is a Java developer for a major US bank that makes widespread use of open source software. Zorro is keen to participate in open source projects, too, except for one thing - his employer won't let him.
"For me, to contribute back to open source, I'd have to become 'Zorro, master of the night' - you have to go underground," our programmer said during last week's MuleCon in San Francisco, under condition of, yes - you guessed it - anonymity. "You have to understand the risk that we take."
We're so deep here, Zorro isn't even his real alias - he just plucked it out of the air - but his case is typical. Like many developers working for The Man, his time and any intellectual property he creates during work hours belong to the company.
And that's creating a serious challenge when it comes to open source projects, as they rely on the contributions of volunteers who are paid for, and effectively owned, by employers.
Forget potential litigation from another SCO. Get over the shadow of Microsoft. The real challenge facing open source is how to bring in fresh contributors and code contributions to sustain projects and meet users' needs. Without fresh blood, projects progress relatively slowly and are likely to stumble towards meeting the requirements of the end user, the consumer of IT.
Jim Whitehurst, Red Hat chief executive, last month joined a growing chorus voicing frustration with lack of corporate participation in open source projects. This means that IT projects do not get the direct input they need from a requirements perspective. For all Red Hat's success, Whitehurst knows that unless more users participate, Red Hat faces a significant challenge filling out its technology stack, delivering software users want and - ultimately - growing its business.
Drumming up corporate involvement also explains the motivation behind the creation of companies like the Collaborative Software Initiative. This is working to bring projects to open communities that might actually be useful, as opposed to peddling some vendor-filtered dream of what it wants you to want.
The challenge is real. Open source has done well in operating systems and middleware. Fedora and MySQL are regarded as successes. It's the fledgling projects that face the challenges as the industry tries to define what's next in open source middleware and applications after things like JBoss?
Open source projects are being particularly challenged because many large organizations - such as Zorro's employer - suck in huge quantities of open source code, but are not returning changes, which could have been useful to the community at large.
Fortune 500 companies who can't give the code back are the biggest challenge facing MuleSource, an open source service-oriented architecture (SOA) start-up from San Francisco, says chief executive Dave Rosenberg.
MuleSource customers include large banks, big financial institutions and major retailers and their reluctance to commit, may stem legal challenges - the companies own the IP - or the feeling among the developers that their bosses know their Gmail address, and that they will get in trouble if they flout company rules.
Peer recognition is a strong motivator for many open source coders, so having to work under a pseudonym is a big disincentive, says Zorro. "We find it unfair because developers value the recognition [of participating in open source] they say, look at that Ross Mason [Mule project founder and MuleSource chief technology officer], he's smart."
When changes to the code are not returned, projects like Mule must rely on part-time volunteers and a handful of paid employees to fill the technology gaps in the portfolio, over time. With a few decent code donations, common issues could be fixed relatively quickly to everyone's benefit. The original Mule project was, after all, founded by Mason in 2003 to offset the "donkey work" associated with internal systems integration, and to spread the load by involving the community.
MuleSource has an ambitious roadmap to complete in the coming months and is looking to developers inside its customer organizations for support. The Mule integrated development environment is scheduled for May, and Mule 2.0 for the Enterprise, featuring JDBC connectors, is scheduled in the third quarter. Further out - and here’s where it gets tricky based on the level of community participation - is certification, documentation and completion of Saturn, the MuleSource business activity monitoring software that's in beta.
“The reason it’s in beta is because we need guys like you to pick up the beta and tell us what you want from the tool," Mason told MuleCon attendees. “The vision for '08 is to build and bring all these things together.”
Taking from the whole
The irony is that organizations increase their maintenance costs when they take open source code from projects like Mule in-house and add their own code. In all but a few areas companies are duplicating efforts made elsewhere, and wasting time and effort in repeating boring infrastructure programming, under the illusion they are adding competitive advantage. "There's so much duplicate effort," Zorro said, echoing Red Hat's Whitehurst, who claimed last month that "billions" of dollars are wasted each year in internal, non-commercial software development that re-invents the wheel.
So let's put down the hippie peace pipe and get real. Banks and retailers participating in projects, and sharing code for a common good ? are you serious? Yes, we are - and here's an example.
The Advanced Message Queuing Protocol was donated a few years ago by the core development team of JP Morgan Chase with Iona Technologies and Red Hat. It has since received backing from rivals including Credit Suisse, Deutsche Börse Systems and Goldman Sachs. AMQP was donated "in response to internal requirements, market demand and partners' electronic trading needs".
According to Mulesource's Rosenberg some banks and institutions have dismantled the barriers that previously stopped their staff from donating code. But they are the exceptions. "Most big companies are not sophisticated in open source. Mention IP, and people go 'eugh!'," he said.
Three objections stand in the way of end-user participation:
* Your time on our dime. With so many developers working inside companies, employment contracts state that IP created on the company's time or on the company's machines belongs to the company.
* Legal fears. Attorneys are unwilling to release code lest it expose their company to litigation in any future court case.
* Helping the competition. Companies find it difficult to shake the belief that in-house modifications to community code gives them competitive advantage over rivals and should not be released.
So how does the open source community change such sentiments? The answer is to reach out beyond the usual narrow gene pool of vendors and actively recruit large non-tech companies.
The Liberty Alliance and Web Services Interoperability organization for example are dominated by vendors, but they also got early support from major users of IT. These include Citibank, Boeing, Fidelity Investments, Wells Fargo, the Mortgage Bankers Association and US Department of Defense at Liberty. The WS-I organization, meanwhile, counts DaimlerChrysler, Ford and Freddie Mac among its members.
What's their appeal? Helped by prodding from key vendors such as Microsoft or Sun Microsystems, companies realized they had a vested interest in participating in, and shaping, technologies critical to their success; in these cases, improved access to their services online by customers and better integration with suppliers, via federated identity and web services.
Suits not sandals
The challenge for open source is to snag the interest of the business - to make business managers realize how they can save money in software development and maintenance by letting employees donate their time and by allowing their organizations to release code that's a burden to them but gold to projects. Unless there is buy in, open source software will - at best - remain invisible in the eyes of business decision makers, and - at worse - become perceived as a quaint exercise in API geekery by the IT department.
Only by convincing the business managers that it's in their company’s best interests to participate will open source attract more individuals from end-user organizations. According to Zorro, user participation in projects and groups such as Eclipse - popular with the industry but woefully lacking in end-user representation - will legitimize open source at last, providing a broader understanding and enabling individuals like him take off the mask and contribute in force.
来源：regdeveloper.co.uk
[ 本帖最后由 Send_linux 于 2008-4-10 10:06 编辑 ]
相关阅读 更多 +
