In 1991, Sun Microsystems created Sun Microsystems Laboratories with the express purpose of solving difficult technical problems brought to Sun by customers. Over the years, the results have been impressive. (See sidebar for more details.) In the fall of 2003, Glenn Edens was named Senior Vice President and Director of Sun Labs. Edens himself has an inspiring record of technological innovation. In 1979, he co-founded Grid Systems Corporation, the company that developed the first laptop computer. He also founded WaveFrame Corporation in 1985, which developed the first all-digital audio workstations for the motion picture, television, and recording industries. From 1992 to 1998, Edens managed the transfer of research results into external product companies at Interval Research Corporation. From 1998 to 2001 he was president of AT&T Strategic Ventures, while also serving as VP of Broadband Technology there. From 2001 to 2003 he was Vice President for Strategic Technology at Hewlett-Packard. We met with him to learn about the direction he is taking Sun Labs. You've asked the question, "What follows the Java language? What follows Solaris?" Can you hint at some answers? Those are rallying questions that are designed to give the Labs permission to think about these issues so we can experiment with alternatives. It's not clear that we're actually going to come up with anything better, though we may come up with something better in specific areas. So, for example, there's been a long tradition of work in the Labs challenging Java technology, called Self, which was a totally different model of object-oriented programming, factoring, and reflection.
The Java platform is a very robust franchise. It's a marketplace. It's a community. It's a programming tool. So we ask questions: What are the alternatives? How do we make the Java runtime smaller? How do we make it faster? How would we change the memory model for the hardware? We're looking at different versions of virtual machine and garbage collection technology. Sometimes in research experiments, we'll change a language feature and experiment with it. And the jury's out as to whether those will ever be significant enough to then launch a JSR process. If you look at the history of programming languages, they don't last forever, because the technology changes, programming styles change, and the good languages last 15 or 20 years.
So, I would bet money that no matter what happens, whether Sun Labs existed or not, 10 years from now, the Java language will look different than it does today. Humans are really interesting, because we love to build tools, and we learn from that prior building experience to build better tools. So, it's conceivable to me that the Labs could develop an interesting alternative that would be commercially successful. At this point, we're really working in two main areas: How do we make current Java implementations better and how do we make them smaller and faster? One area of current research explores the link between a Java type object-oriented work load and hardware. In the Labs, the real exciting work isn't about instruction sets. It's about the memory model. So, we have projects like Mayhem and Barcelona, which we don't talk about much, where we're working hard to construct hardware and system software differently. So we're looking at different run time environments. If a large bank or a large customer's main workload is a Java 2 Platform, Enterprise Edition workload, then there's a good chance we could design computers differently to run those workloads better. We also have a project code-named Squawk, in which we're working on a very compact, high performance Java environment written entirely in the Java language. We're also interested in offering developers in the device world a complete Java stack that doesn't require integration with numerous other system software vendors. Running but not Managing Sun Labs
You are quoted as saying that you can run a research lab, but you can't manage one. What did you mean by that? A research lab attracts a different personality than a pure product group. And pure academic research and big science attract an even different personality type. So, we're kind of in the middle. My joke about this -- and I get a lot of grief over it, but I still think it's a good metaphor -- is that product organizations are mostly staffed with engineers. And engineers are mostly nerds, who ask: "How are we going to get this done? How does this work? How can we make it better?" How, how, how.
A research lab tends to consist of hippies, and hippies just ask why. Why, why, why. Why do I have to do it this way? Why should I do that? Why do I need to fill out this form? Why do I have to -- anything. Everything is a question. There is nothing that happens here without an argument. But that's part of our robust culture, and it's the "why" versus the "how". The reason I get in trouble with that analogy is, of course, there are very good engineers in the labs, and there are very good hippies in the product groups. When managing a set of independent people, you can't tell them what to do. There are only three areas that I directly affect: First, I have some control over the people we hire. Second, I can present questions we ask, bringing in customers, suggesting something to discuss in Sun's Executive Management Group. And third, I can decide what to fund. But that's about it. That's why I say that you can run Sun Labs, but you can't manage it. Five Kinds of Projects at Sun Labs
Sun Labs has reinvented the way it works in the last year. You divide projects into five kinds: consulting projects that solve specific customer problems; advanced development projects that support business units with new technology; long-term vision projects; micro-business projects; and community projects. We decided that we wanted to be crisper about where and how researchers spend their time. So, we perform our role as a teaching organization through consulting with the business units and our customers. We get called on to attend project briefings and hold workshops where we transfer our knowledge. We consult for free, which gives us the freedom to say, "No, we don't want to work on that one." If we charged for consulting, then we're a business. Some of our peer company research labs have gone to that model, but I think that's death for a research lab. Once you start chasing money on a per person basis, you turn yourself into a professional services organization with a lot of Ph.D.s and are no longer a research lab. Advanced development, the next category, is something we do rarely. But sometimes a business unit will ask us to solve a problem, and we'll take it all the way to a releasable state. That's an expensive proposition for the labs. However, we're taking the Honeycomb project, an integrated storage and server project, very far through this process. The vision projects are the core of what we do, and we do some interesting things in this area. Each researcher has a project that they pick by themselves and work on for some part of Fridays. They can work on anything they want. The only rule is they have to publish some results. But they get to pick how they spend Friday. Then we have our regular vision research projects, which are funded and evaluated, and we review them and nurture them through to hopefully get transferred to business units. That's probably more than 60% of what we do. It's interesting that Sun Labs actually launches products through the micro business units with the intent of breaking even, in an effort to keep projects alive. Often we'll have a technology which is a little too small to transfer to a business unit, so we decide to launch the product ourselves. We run these break even, not wanting to lose money on them, but not needing to make money. We want to keep the technology alive and get customer engagement. Real-Time Specification for Java (RTSJ) was headed down that path. We were initially engaging with customers, and then things changed, and we were able to transfer RTSJ to the business unit. Finally, we have the community projects. And those are everything from open source work to patents, which eventually become public when they get issued. Community projects include chairing conferences, being on program committees, speaking, publishing technical reports and papers. We try to be very interactive with other universities and other conferences, and I think that really helps get that two-way information flow going. Moving Data at 60 to 100 Times Current Speeds
Sun Labs recently was awarded a 49.7 million dollar contract from the Defense Advanced Research Projects Agency (DARPA) to help design next-generation supercomputers. This asynchronous design research, advanced by Dr. Ivan Sutherland and Dr. Robert Drost, has already yielded a breakthrough in silicon design with the potential to move data at 60 to 100 times as fast as current top speeds. They are developing Proximity Communication whereby a pair of chips are positioned face-to-face within microns of each other, but not necessarily touching. The proximity IO work at Sun Labs got us the DARPA contract. This is a research project, so there are many questions. It's a substitute for printed circuit boards that allows you to design the hardware and connect chips together differently. The data rates between chips are now as fast as the data rates inside a chip. And so the distance controls the data delay. You can now start putting cache memories and different parts of systems outside in different chips, and the system will run just as fast. This research could change the way we approach silicon for processor design. It might have interesting applications for how switches and routers are built. If we're lucky, this could change how people design high performance computers -- we'll just have to see. Knowing Customers
It is a given that a lot of the projects at Sun Labs will eventually "fail" -- or perhaps, eventually show up in products in a different form, or become part of human knowledge. In a recent interview on java.sun.com, we talked to Sun's Rick Catell, who spent six years at Xerox PARC watching the invention of brilliant technology that went nowhere, he argued, because the researchers did not know their customers. In doing visionary research, how close should researchers be to customers? Do visionary products fail because researchers are out of touch with customers? One thing that I find very amusing is that, from the perspective of Xerox, Xerox PARC was a complete success. There was no business model that required Xerox PARC to produce technology that shipped. Xerox PARC was funded because Xerox was afraid that IBM would invent the paperless office; then you wouldn't need Xerox. So, what's paradoxical is that everyone criticizes Xerox PARC, but from their perspective, it was a complete success.
At Sun Labs, we work hard to make sure that our research staff is grounded in what's happening in the world. What's happening in pop culture? What are kids doing? What's this IM and learning to type with your thumbs about? Because kids, artists, and renegades are going to define how the technology gets used going forward. We bring in speakers and projects and work with other research labs. We work with schools. We bring in a lot of customers. We make sure that for the areas we're working in, we know as much as we can about what other labs are doing and what people's perceived problems are, because they can rarely articulate their real problems. So, a customer might say, "I'm spending too much money on IT." Well, what does that really mean? Does that mean that the money they're spending is not effective? Or does it really mean that it's effective, but they want to spend less? Do they believe it can be cheaper? Is it really a service problem? You have to decompose that. But at the end of the day, the spark of innovation still comes from someone asking, "Why, why, why, why, why? Why do I have to do it that way? Why is this done this way?" And you cannot replace that spark with any automated or procedural mechanism. It just has never happened. Now, maybe someone will eventually stumble onto the science to "make" innovation occur, which would be quite interesting. What you can do is equip your research lab with as much intelligence, creativity, and knowledge about what's happening in the world as you can. And the more you do that, the more relevant the solutions are going to be. See Also
|
'paper and essay' 카테고리의 다른 글
bash 스트링 조작하기 - String 함수 구현하기 (0) | 2008.01.18 |
---|---|
bash shell (0) | 2008.01.18 |
Becoming A Real Programmer (0) | 2005.02.28 |
Why Do Universities Fail Teaching Software Engineering? (0) | 2005.02.28 |
How to write papers (0) | 2005.02.15 |