In Nortel's case, the engineers want to get their needed code into the kernel in order to control high-resolution timers that send "wake-up" calls to the kernel for use in the switches that route mobile phone calls.

Nortel had its engineers create custom code to get the work done, but since they did it on their own, they have to redo their work every time a new Linux kernel comes out for their phone switches.

Such a problem is common for many companies that do their development work outside the open source community, Bottomley said. "That's where the big strain comes," he said. Going solo can cost companies thousands of dollars in costs and many hours in staff time, and then they have to do it all again manually each time a new kernel is released.

To avoid having to rewrite the code each time a new kernel comes out, Nortel wants to get its changes into the mainline kernel so they are there automatically for every future version.

"Your maintenance burden is significantly reduced," Bottomley said. "You still have to test and check the code, but you don't have the massive front-end work in the race to keep up with the kernel."

Typically, Linux kernels are updated every two to three months by the kernel maintainers. That can be a challenge for companies like Nortel that want to keep up with the latest kernel, but it's also where getting involved in the process pays off, Bottomley said.

Getting started

The way to start, Bottomley said, is to have your developers post to the kernel community mailing lists and monitor them for the issues you are experiencing. "Start posting and getting involved in the discussions," he said. "It's a community, sharing development. They're negotiating to get the best implementation that suits them all."

Some of the key kernel mailing lists are:

• {xref:http://marc.info/|marc.info]], the kernel mailing list archive.

• kernel.org, the place to start and to find the proper mailing lists for the communities and subcommunities where your developers want to get involved.

• kernelnewbies.org, for resources about the kernel, the processes and the communities.

• The Linux Foundation, for more helpful information and collaboration-building resources.

Once your developers are involved, he said, they can stay involved after your changes are included so you can watch over the kernel and keep your changes updated.

Daniel Frye, manager of IBM's Linux Technology Center and another conference participant, said he's seen plenty of business users that have similar issues to what Nortel faces with its switches. For those companies, he said, having to learn the open source community's way of doing things is "counterintuitive."

"They don't how it works," Frye said. "Some of them have cultural barriers, some of them have misconceptions."

The Linux Foundation is working on ways to teach businesses how to get what they need from the open source community and how to communicate better with open source developers, Frye said.

That starts with knowing who makes up the communities that are working on the code in the kernel parts that affect your business, he said. "If you don't know who the kernel maintainer (the lead person for a specific part of the kernel development process) is, then you're not even started," Frye said. "You've got to know who the subcommunity is" and who makes up those five to 10-person groups.

To get this information, Frye recommends that companies ask lots of questions, do research and poke around in the mailing lists to see how they work. Communities can work in different ways, making them even more intimidating, he said. "Listen and find out how decisions are made, and then go ahead and participate, then adapt to the community."