Can IT Use Open Source To Develop Internal Apps?By Allan Alter | Posted 2006-11-29 Email Print
Mainstream companies are using open source methods to develop their own software. Lynne Ellyn, CIO of DTE Energy, shares her thoughts on how to make it work.
DTE Energy in Detroit, a diversified $9 billion energy company that includes Detroit Edison, Michigan Consolidated Gas Company and other energy companies, is undertaking an experiment: Its software developers are using open source techniques to develop reusable code. Lynne Ellyn, senior vice president and CIO of DTE Energy, and a senior consultant with the Cutter Consortium in Arlington, Mass., told Executive Editor Allan Alter how far her company has gone down the open source path, and what's required to make it work.
CIO Insight: What's the difference between open source software and open source methods?
Ellyn: Open source software is any software product offered under the Open Source Foundation charterApache, Linux and so on. Open source methods allow people to voluntarily contribute their software to general purpose use, or a particular audience. In the open source community, people who have established themselves as experts in software review those contributions for quality, fit and usability. Then, based on the merits of the software, the experts accept, reject or suggest changes. So the method requires enthusiastic individuals who will contribute their own work, and volunteer experts to review them. It's a very good example of a meritocracy; that's essentially the heart and soul of any open source work.
Are these the kinds of practices you have in place at DTE Energy?
Yes. But these practices need to be adapted to a corporate context. In our case at DTE, one of our objectives is to build a software component library that accelerates code reuse. That reduces cost and increases the speed at which we can deliver new capabilities to the business. A problem with reuse is that people tend to be disinclined to use other people's code; it always seems easier to a developer to write his own code rather than look at somebody else's. So one of the ways we have accelerated reuse is by applying this meritocracy principle to what goes into the reuse library. That has generated more interest on the part of developers to contribute. Our lead architectsand there's only a handful of these very skilled architectsthen review each contribution. The submissions are often made anonymously, so they are vetted on their own merits without regard to who wrote the code.
How are the lead architects chosen?
The people in those roles have years of broad-based experience in the development of all kinds of software. They understand the objectives of reuse, quality and testing. Many of them have advanced degrees in computer science. The adoption of open source methods inside our company depends on this small community of skilled people who can be the coaches, mentors, and judges of what is going to be accepted in our component library.
And how many people actually submit code?
At any one time, because we do use some contingent workforce, we have 300 to 400 people involved in the development of software. A pretty small percent of that are making contributions to the library. I can't tell you how many because this is an iterative process.
Why aren't more people contributing to the process?
Some people decline to participate. Keep in mind that we're asking people to volunteer their best ideas. You cannot take participation for granted. It will die if you're not providing recognition of superior accomplishment. So once a contribution is accepted, we make a big deal out of it. There's a lot of recognition. Software developers compete with themselves to create elegant, high-quality code, and they appreciate being recognized for their contributions.
Are there other ways to reward people who make contributions?
The way we value our employees is broadly based on how much work they do, the quality of their work and how well they collaborate with others. Those who actively think of ways to promote reuse and participate in this voluntarily are valued pretty highly. Our normal financial rewards and recognition activities comprehend that. But you must remember that there are thousands of people contributing to the open source community because they care about software, and are motivated by recognition. They aren't directly compensated.
Human beings want to be recognized for the good things they do. You can slave away 30 years developing software inside a company and get your raises, but the recognition from your peers that you operate at a level of excellence is worth a great deal, and it's highly motivating.
Are there other projects underway at DTE that embrace open source methods?
This is unique to the IT department, but not merely confined to code. We have several examples of conceptual components that were contributed and then reused. Of those projects where people are deploying new application functionality, perhaps only 20 or 30 percent might be reusable by the next application or another business unit. But any group working on a project can take part of their project and volunteer it for inclusion in our reuse library.
How well do business executives understand and support these practices?
I would say there's very little understanding, but there doesn't need to be any. The executives outside the IT department are interested in how good the IT department is at helping them do a better job. My budget today is 52 percent less than it was in 2000, yet we produce more and have a higher satisfaction rate among the people we interact with in the company than we ever have. So I get a lot of support because we get very good results.
Sounds like you have obtained the benefits you anticipated from adopting these open source methods.
I would say we started as an experiment and we have raised our expectations as the experiment has progressed. And we are definitely getting as much or more than we anticipated. Last year we produced 52 significant reusable components, and we have saved over $200,000 this year on the reuse of those components. I think five years from now we're going to have an even better story.