Speaking in a keynote session at the Linux Foundation's Collaboration Summit, Dan Frye, vice president of open system development at IBM, provided his insights into some do's and don't when trying to work with Linux.
For IBM, one of the hardest lessons it had to learn was one about control. Mainly, there is none.
"There is nothing that we can do to control individuals or communities, and if you try, you make thing worse," Frye told the audience. "What you need is influence. It goes back to the most important lesson, which is to give back to the community and develop expertise. You'll find that if your developers are working with a community, that over time they'll develop influence and that influence will allow you to get things done."
Frye noted during his keynote that an early question that IBM asked internally about Linux was how it could control a chaotic development process. As it turns out, Linux development isn't a chaotic process, though it may appear that way to some looking from the outside.
Joining the Linux community as a participant in a broader ecosystem also proved to yield a key lesson for IBM.
"It's easy to form a community around yourself," Frye said. "It's much harder and more valuable to participate in a community that you do not control -- it took us time to learn that."
Fry recalled that a few years back, IBM wanted to push its own Linux scalability effort -- an initiative that didn't work out, as IBM did not get any community input for the project. The problem was that IBM didn't know how things worked in the Linux community, Frye said.
For example, he said someone would send a note on a mailing list about an IBM effort, and then the IBM people in turn would have a team huddle to determine a response. Frye noted that it would take IBM a lot of time to respond, and by the time it did, the interested community individuals would be long gone.
"We spent far too much time behind the IBM firewall, discussing things, and we tried to polish our external communications," Frye said. "So we banned internal IBM communication on the Linux kernel. Anyone working on the kernel at IBM was not allowed to talk to anyone else inside the company. All communications had to be external."
That effort led to IBM having more success in dealing with the community. In addition, IBM learned that it doesn't work to make large code donations, either. Frye stated that it's far more effective to start working inside of a community and then deliver incremental pieces of work.
While IBM discovered that it can't control the process, Frye noted that it is possible to work on the things that were important to IBM even within the community model.
"It is perfectly acceptable to scratch your own itch," Frye said. "You can work on the things that are important to you and your company, and things will work out."
The other lesson that IBM has learned is that it's the end result that matters in Linux, and not who runs a project or starts a particular effort.
"It does not matter whose code is eventually shipped," Frye said. "If your folks drop code and someone takes that code, rewrites it and makes it better, that is fine."
One of the ways around the issues of security and control that make some businesses wary of cloud computing is to build a private cloud -- one that remains within the corporate firewall and is wholly controlled internally. Private clouds also increase the agility of IT an organization's IT infrastructure and make it easier to roll out new technology projects. Download this eBook to get the facts behind the private cloud and learn how your organization can get started.