Challenges

 
 
By eweek  |  Posted 2006-01-29 Email Print this article Print
 
 
 
 
 
 
 


That rate of change can be a challenge. Can it be too much, and make things too complicated? Im referring more to the high volume of change. As any Gentoo user can tell you, you emerge something, and then things dont work, and you have to sort through to fix it. Yeah, Ive been running Gentoo for the 2002 to 2003 time frame, and Ive had several issues. Ive said to myself, well, you know, the change rate is worth it. Change destabilizes, but change is good, and thats kind of a classic problem. I dont want to suffer from innovators dilemma at E-Trade. I want to keep pushing this company very, very hard. So I want to drive change. The downside of that is if you try to change, you can destabilize the system.
[Gentoos Chief Architect] Daniel Robbins always wanted to do a server variant of Gentoo, which the project, I dont think, ever started, but its always been something that was kind of on the mind of the Gentoo community—that there should be the top-of-tree distro, and behind it something a little more stable, almost exactly mirroring what the Fedora community project is and the Red Hat AS series of servers.
So, here I am, the guy whos trying to push change. I work on a Gentoo box, while our production system is Red Hat AS 3.4, which is very stable. And so thats kind of a good way of balancing aggressive change and stability, in our mind. But back to that WSJ article. In some regards, [the Microsoft situation it describes] is the same as at E-Trade. We have a very large code base with a large number of committers, and [there is] the probability of conflicting change occurring. We have a very complicated application—nowhere near as complicated as a project like Microsofts Longhorn, but complicated enough that youll have, say, our stock options business, which is an employee benefit. They have some developers there who can make a change, and then somebody in our cash transfer business puts a change in, and they conflict, and we have to resolve that conflict in our build process.
The way the open-source project does that is that the guys who are submitting the change for the employee benefits site would submit a patch, and the other team doing cash transfer would submit a patch, and the committers would look at both and go, You know, that might conflict. We should probably do one versus the other. And this is the way that you now do your development at E-Trade? Let me back up a little bit. I think IBM kicked off the open-source phenomena in a big way. Of course, Richard Stallman kicked it off in the 80s, but whats happened is its a disruptive technology event. The first time we looked, the first time we saw Mosaic—in 93 or 94—we thought, "This changes everything." It was a disruptive technology event. The way I see things architecturally, with open source, is its a disruptive technology event. Theres such a predominant availability of raw material, and that raw material is code, and the change rate of that code is so high. You know it, because youre a Gentoo user—youre subjecting yourself to that rate of change. Its blowing out all the processes that corporations have established for dealing with change. Its an order of magnitude larger. So, the game is: How do you change your technology development and change processes to adapt to this realization that theres a massive amount of raw material, code, and it changes very, very quickly. Thats probably the biggest architectural effort in the company right now. And so youre at the beginning stages of trying to take that on? And youre looking at open-source projects as examples of how other large projects are dealing with that? Absolutely correct. And, by the way, Microsoft has a similar issue. Who did they hire recently, over the summer? Thats right, Daniel Robbins. You know, if you look at pluggable strategy in software, like a servlet or a Web service or, in this case, just a tarball of code, you look at the number of packages that are in a, say, Red Hat or SUSE distro—its about 1,200 to 1,400. Fedoras pretty good—I think its in the 3,000 to 4,000 range. Nice, 4,000 packages. Gentoo has 14,000 packages. BSD ports, as well, 14,000 to 15,000 packages. Debian, also. Yes, Debian package, also quite good. I did a deep dive on distro tools, and actually got a lot of the E-Trade stack running with small source-code bases. I would say, hands down, our developers hated it. And so, we studied it, and we looked at the OpenPKG thing. The other thing were looking at is using, not a distro automation tool to run what Im calling the package-centric approach to software development, but a development automation tool like Maven to drive the creation of distros. So were working with a lot of the Maven guys right now. Well let you know how it goes. Next Page: Desktop Linux.



 
 
 
 
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Thanks for your registration, follow us on our social networks to keep up-to-date
Rocket Fuel