Reflections of Open Source Diva Morocco RPCV Danese Cooper: There were a lot of people who started at Peace Corps who've ended up doing social consciousness work or working for NGOs
Reflections of an Open Source Diva
[Excerpt]
Mad Penguin: You're someone who is trusted by both by suits and hackers in the open source world. How did you start out in open source?
Danese Cooper: You know, I might actually have been predisposed to it. I was in the Peace Corps when I was in my twenties; and I've lived in several collective community situations through the years. I try to live my life really transparently because it's just easier for me, but in the years before I came to Sun, I worked in software engineering for some of the biggest companies in the world, and I was appalled at the wasted time and the lack of transparency inside some of these companies.
People looking in from the outside think of the big brands like Apple or Microsoft as one big entity, everyone working together, it's a hive, and everyone's doing their job. But actually, they're often more like warring feudal fiefdoms. They're composed of these competing business units, and they're competing for resources and they're competing for funding, obviously, and sometimes they don't play very nicely with each other in a lot of companies.
I experienced a lot of engineering inefficiency. For example, I've worked on projects where part of the team came from another project in the same company that was maybe a related project, and the people from the previous project were not happy that they left. It was not uncommon to see the former group hide the code from their colleagues. So these engineers who maybe invented this code would be blackboxing it, meaning that they are coding as though they haven't ever seen the code before, because it's not like they can remember exactly what it says. They're coding to a set of behaviors, rather than the actual code, which is much less efficient, because their fellow employees won't let them see the original code they wrote. That's not an unusual story in my experience in engineering management in some of these big companies.
The last job I had immediately before I came to Sun was working for Symantec. The part of Symantec I was working in doesn't exist anymore. I was working on ACT!, which is a PIM program that is still widely used. When I started we were working on its fourth revision. It make a lot of money every time they released a new version. They had reasons for wanting to resuscitate the ACT! brand because Outlook had come out and they had real competition for the first time.
So they hired a group of crack young managers to kind of pull this team together and re-motivate it to get it going on the next version. We did a pretty good job of shipping that version, and then we started working on the subsequent version, which was shipped as ACT! 2000.
At that time, there were other properties that were owned by Symantec that were famously in trouble like Delrina WinFax. Senior management was spending all of their time trying to fix those problems. Because our team had just turned out a good first performance, they left us alone.
What they didn't realize was that we had taken this idea of transparency to heart, and we decided to run ACT! 2000 from an engineering perspective and a design perspective as a massively transparent project. We put everything on the web inside of Symantec. We essentially used open source and extreme programming methods to create ACT! 2000, and we got two-thirds of the way through the project before senior management realized that we had drastically changed the methodology. Of course, they had a fit. But when we shipped it, ACT! 2000 cleared 1500 bugs out of the queue that had been there for years and years, because we had that much extra time! We had pre-validated all of the designs, and developed everything transparently, so everyone knew everything that was happening the whole time. The whole process worked so much better, that I was completely sold on this model.
My very next job was to come to Sun to work on the community-building around the release of Java code under the SCSL (Sun Community Source License), but after six months I quit. I officially went in and said, “I don't think I want to do this job any more, I'll just go find another job outside of this company,” because it was clear to me at that time they they weren't interested in building community around this code base. Sun was very content to get all of the good publicity for releasing the code, but when people tried to give them bug fixes, they weren't interested in taking them. They weren't interested in having conversations.
To be fair, the Java engineers were not given extra time to deal with any of that. They had the same requirements to get software done. When you already have too much work to do, and everyone at Java soft was working very hard, you're going to do what you know, rather than trying to learn something new, because it feels like it's going to take longer [to learn something new].
Trying to learn how to work in a collaborative community where some of the people don't work in your company was not a high priority for most of the Java engineers. So I offered to leave. My manager at Sun said, “Please don't leave. Please stay.” Unemployment in the Valley was something like one percent, and employee retention was really important. So they said, “What would you be interested in doing if you stayed?” I said, “I think you need to understand open source. I don't think you get it now, even though Bill Joy helped found this company, and even though it was founded on BSD code, I think that you guys have forgotten how to work collaboratively with people outside the company.”
In reply, management said, “Ok, fine, go study open source.” So I set up a study group to check out open source. I used the Open Sources book that Tim O'Reilly had just released, and I asked each and every author from Open Sources to come give a talk at Sun with a group of vice presidents and directors who subscribed to this study group. I assigned a chapter of reading before each talk, and the author would come and talk about why he or she thought that Java should be open sourced. That was the big topic of discussion, and it was a big carrot for the open source community, because they so greatly wanted to see it happen. It was the ultimate topic for Sun, because they were getting beaten up for SCSL, because it wasn't really open source.
After a few weeks of running this study group, the team that had been trying to convince Sun to donate JSP code to Apache as Tomcat finally got their approvals. Right after that, JavaOne was approaching, and Sun decided they wanted to open source NetBeans. And the month after that, Sun wanted to open source OpenOffice.org. It started to snowball, and they starting pushing all this code out the door, mostly for disruptive reasons.
There were always people who wanted building communities to be the goal of those projects, but when you work for a big company, you have to work for the stated goal, and fit in the other stuff surreptitiously. That's how you create change. I give a talk often now that I call “Guerrilla Evangelism”, which is about coming up with ideas that are going to serve two goals; where one goal is the apparent one that the corporation signs up for, but there's another goal that they may or may not realize is going to come along with the package.
A really good example of that is blogs.sun.com. I and others argued for years to create a blogspace at Sun. There were other Sun employees who were blogging out in the blogosphere, on their own, and sort of taking their careers into their own hands because it was not a sanctioned activity.
So we suggested setting up a blogspace over and over again, and we eventually convinced people that Sun needed to create blogs.sun.com, mostly because it would help a certain community of developers begin to have a dialog with the outside world; (Sun was getting ready to announce OpenSolaris). We felt like we needed to give the Solaris developers and others an outlet to start changing minds about interaction with the community. This was in part due to my experience five years earlier with the Java community, where the Java developers sort of weren't consulted about the idea of having to deal with the greater community. We wanted the Solaris engineers to be ready.
But after a little while, all of the other good stuff that we thought would happen, started to happen. Like, for example, people talking with enthusiasm about what they work on inside of Sun, and feeling a sense of freshness and lightness about being able to talk that way; and the press starting to notice that things were happening; and then Jonathan Schwartz deciding that he wanted to blog to set the record straight when he was misquoted in the press; and discovering how powerful it is to be able to control the message that you're delivering, because you're writing it and you're putting it up, and you're not having to have it filtered through journalists. So, those were the unintended consequences, in a way, of blogs.sun.com, when the original goal was to help some engineers get used to dealing with the outside world.
We designed a lot of projects like that. Java.net is an example of enriching the open source developer space with more collaborative tools that all developers were starting to use, but that weren't available in a single place. SourceForge sort of defined what open source hosting feels like. You know, there's a code management tool, there's a mail list tool, there's a bug tracking tool, you can download some binaries, that's pretty much what you get. Oh, and plus there's some statistics that can be returned.
But we were noticing people starting to actually share code and run projects with wikis, and make major statements outside of the mail lists or the forums in the blogging tools, and we decided it would be lovely to create basically a playground for Java developers that were working on open source projects. The prevailing wisdom was that Java and open source didn't mix, and yet we knew that there were an awful lot of Java developers working on open source projects, and we were hopeful that Sun would decide that they wanted to push code out on Java.net as well, which has happened a little bit, not quite as much as we were hoping for, but you know, I've got my fingers crossed always.
