OSCON06: Taking a Closed Source Product Open

Neelan Choksi gave a talk at OSCON entitled "Lessons Learned in Taking a Closed Source Product Open" about BEA making Kodo (Java persistence APIs) an open source project. Choksi is the senior director of products at BEA. Why did he work at making Kodo open source? The users kept asking them to do it and BEA can make more by open sourcing it by selling support and add-ons. He had some good advice about the whole process. First, note that it is a one way process, once you go open source there is not turning back. Company leadership buy-in is a must, because you need your whole organizations support. Even though the project is open sourced it will still need management, marketing, documentation, and quality assurance testing. Good documentation is very important for an open source project, it helps make it easier for developers to decide if they want to join and where they can contribute. One goal is to reduce market costs by building a community around the product. To do this you need a really good evangelizer, someone who can hit the speaker circuit. Ironically it probably costs more initial to open source a close project than starting one from scratch. A lot of effort has to be devoted to getting the documentation up to a level that will help build a community. Make sure your support organization will be able to handle the increased load, especially if you offer some low cost support to get people to seriously try out the software. Lastly, don't expect results overnight, make sure your management understands that it will take at least a year or more to build up a community.

OSCON06: So, You Want to Build an Open Source Community...

J Aaron Farr gave a talked at OSCON titled "So, You Want to Build an Open Source Community: Learning from Apache" about, obviously, building an open source community and a bit about Apache Incubator. First, community is the key to any open source project (this was restated in about every talk I attended at OSCON). It's not just about having a community of developers and users but about growing and evolving them so that all the developers are also users and many of the users become involved more directly. It reminded me of how Firefox has a lot more than just software developers, they have graphic artists, writers, lawyers, marketers, etc... contributing to the project. He emphasize that commiters (contributers) should eat their one dogfood. In other words, the developers and users should really believe in the project. Growth of the community is really needed to ensure the stability of the project. If you have a stable community then as people come and go others can continue it.

So what do you need to build the community? At a minimum working code that developers can contribute to and a good means for the community to communcate. Like a good web site with documentation, mailing lists, newsgroups, an issue tracking system, and a source code repository. Once you have all this you really need a clear pathway for people to see where they can contribute; like a web site that makes easy for people to see how they could contribute to the project and how to become a member.

He also discussed the Apache Incubator, which is a process the Apache Foundation setup to review projects for inclusion into the Foundation.

The slides for his talk are here and his blog is CubicleMuses.

OSCON06: Open Technology Development

John Scott's talk on Open Technology Development: Open Source and the U.S. Government was about how to change the culture in DoD and the U.S. Government in general to foster better software development, be it in-house or contracted development. Not surprisingly, canvassing DoD he found huge interoperability problems, lots of re-invention, lots of failed projects, and that those in the field use whatever it takes to get the job done rather than try and do it by the book. This is entirely a problem of policy, not a lack of technology. So DoD is looking to the open source software model to provide a faster development process. The current acquisition process for DoD software fosters interoperability, stifles innovation, and is far from cost effective (for all the contracts DoD has with PeopleSoft they could have acquired the company). Worse, many opponents "out develop" the DoD because the process is so slow. So how does one go about creating a community that develops software collaboratively across all of DoD? First, you rename "open source" to "open technology development" so as not to scare those afraid of open source. Next, you need a policy that allows and even encourages it. (The part he is currently working on.) It can be done, there are some isolated projects that DoD has contributed a lot too such as openssl, geo-spatial tools, solid modeling, and secure linux.

Scott co-authored a report entitled OTD Road Map that outlines why and how DoD should create a DoD open source software development community. On 14 September 2006 there is a conference by the Association for Enterprise Integration on Open Source New DoD Paradigm, or Business as Usual?. Some other related sites are Open Technology Development and Governement Forge.

OSCON06: Asymmetric Competition

Tim O'Reilly interviewed Jim Buckmaster (ceo, craigslist) about craigslist. Jim pointed out the craigslist is starting to charge a samll fee for some real estate listings. However, this was at the users request to cut down on spam and repeated listings. Tim asked him if he felt guilty sucking so much revenue out of newspapers? His answer: "No, they still make a profit." Tim asked about future plans. Jim stated they don't need to do something new, they just need to do a lot more of what the users ask for.

An interesting blog about craigslist is on the O'Reilly radar here.

Photo courtesy of James Duncan Davidson/O'Reilly Media.

OSCON06: What's Microsoft Doing with Open Source?

Danese Cooper interviewed Bill Hilf (general manager of platform strategy, microsoft ) on "What's Microsoft Doing with Open Source." Bill started by pointing out that microsoft does support the open source community via conferences like OSCON and Port25. Over the past three to four years microsoft has gone from fearing open source (linux) to becoming a lot smarter about it. To learn from open source microsoft has to engage it and get involved. Bill's team is composed of about 20-30 in Redmond and another 100 people worldwide, compared to about 60,000 total at microsoft. The goal is to try to influence by spending about 75% of their time with the production teams. Yet microsoft still really needs a governance model.

Cooper: Now that Martin Taylor left is that helping you in your job?
Hilf: He did help centralize the company on the same page.

Cooper: But he did fund a lot of disinformation about open source?
Hilf: We never had a disinformation campaign. The message format needed to be better (the audience laughed a lot at that answer).

Danese and Bill discussed the plug-ins being developed to store microsoft office documents in an openXML format. Cooper commented that microsoft is still not providing enough information to the project for the plug-ins to accurately convert documents between openXML and the ODE format. Bill really was not up-to-date on how well the plug-ins are working.

Cooper: What is the hardest part of your job?
Hilf: Dealing with the closed mindedness on both sides, (at microsoft and in the open source community).

Cooper: Do you thing the European Union did a better job of teaching microsoft to play fair then DOJ?
Hilf: The DOJ ruling had quite an effect on microsoft.

Some questions were taken from the audience near the end. Kartik Subbarao asked how can microsoft be trusted (in the open source community) and Bill gave the best answer possible "By consistent action over time going in the right direction."

Overall Bill Hilf did a "great" job of answering the questions, but I was kind of surprised he wasn't more knowledgeable about the state of the openXML project.

Photo courtesy of James Duncan Davidson/O'Reilly Media.

OSCON06: Ghost in the Machine

At the "Ghost in the Machine" panel discussion Tim O'Reilly essentially asked Jeremy Zawodny (developer relations, yahoo), Chris DiBona (open source program manager, google), and Jim Buckmaster (CEO, craigslist) how do they use open source and how do they contribute to open source. First, all three basically said they would not exist without open source. Jeremy said yahoo uses freeBSD, linux, C, C++, PHP, Perl, and Python on its servers and the desktops are "across the board". Chris said google uses linux, mysql, gcc, g++, and python, but not a lot of apache. They have developed their own web server for better throughput. Jim said that craigslist uses the LAMP model (linux, apache, mysql, perl) and ubuntu on the desktops.

How do you contribute to the open source community? First, they all have developers who submit patches to many different open source projects. Second, yahoo and google have hired many major contributors to open source projects who have the job of continuing the development of the project; but they also make enhancements that are not rolled out because it gives them a competitive advantage. Also, google and yahoo have free APIs and all three make monetary contributions to open source projects.

Why don't you contribute more of your code to the open source community? All three said something akin to 1) the code is not up to the standard of open source code (it would be embarrassing), 2) the code is what sets us apart from our competitors, 3) the code would be useless without the underlying infrastructure, 4) moving from closed source to open source can take a lot of resources so its hard to determine what would be best to open source, and 5) we don't want spammers learning how we find spam.

Also, Jim Buckmaster has to be the most laid-back CEO of a successful company I have ever seen.

Photo courtesy of James Duncan Davidson/O'Reilly Media.

OSCON06: Face 2 Face: Processes for OS Communities

Ever attended a meeting that you felt just wasn't focusing on the
real issues and knew others at the meeting felt the same. Kaliya
Hamlin's "Face 2 Face: Processes for OS Communities" tutorial at OSCON 2006 provided good techniques to make meetings and conferences a lot more productive. While her tutorial was targeted at a conference to addresses problems within an open source community, they apply to just about any size gathering of people invited to resolve some issues. Some of the methods are obvious while others would be considered avant-garde. Also, at the request of many participants, we discussed ways to deal with people who derail meetings, or worse, get verbally confrontational or blow-up.

First, an important part of any meeting, that is often overlook, is to let everyone introduce themselves and if time permits provide more than just their name. Obviously this is for groups having people who don't know each other by name (yet). It is really important for people to put a face to name.

At the level of a conference or large meeting she emphasized that the "art of invitation" is really important in getting the right people to attend. Express your hopes and goals of the meeting in the invitation. Also, if it is for a large conference try to come up with a cool name or logo, some examples are winecamp and the internet identity conference. Next, at the start of the conference get participants to suggest sessions on a sheet of paper and create a chart of the available rooms and time slots. Let everyone post his or her sessions to the chart. Once all have seen the suggestions ask people to negotiate a better arrange and/or come up with better sessions. We did this pretending to attend a conference on ways to "improve online collaboration". I suggested a session entitled "ways to reduce office email using a community blog". About three others had similar session ideas and we quickly rearranged and merged our sessions into a topic track we all like. I was somewhat surprising how smoothly this went, I expected some chaos to ensue but none did.

To "break the ice" of a meeting we played the "game" called "A Strong Wind Blows..." akin to musical chairs. Everyone sits in a circle except for one person standing in the center. The center person states a quality about themselves like "a strong wind blows for all linux users". Those who use linux get up and scramble for a new open seat, including the center person. The one left standing then takes a turn. I have to admit I had some reservations at first but was amazed at how well it worked. There was quite a bit more openness and energy in the room after only about 10 rounds. I wouldn't try this technique at the next board meeting; however, it really seemed perfect for an offsite. It is a technique to get people to know one another and get a sense of who is in the room.

After this she outline the "fishbowl technique". In this method a set of chairs are arranged in concentric circles starting with about seven in the center. Get six volunteers to sit in the center or choose six with differing opinions about an issue being addresses. During the conversation among the six when someone outside has something to add they sit in the empty chair and one of the others self-selects themselves to step out. The method worked well for our discussion, how to deal with someone who blows-up at or derails a meeting. Some of the suggestions were "work hard not to hire such people", "have some formal communication methods", "everyone should take a break and the manager should talk to the person privately". When talking with such a person emphasize connection, build up their trust, and that you are giving them the attention they are asking for and they now need to give others equal time. When listening don't always do an analysis (male trait). (read Six Thinking Hats by Edward de Bono). Try to make the environment as open as you can to allow everyone to comment. If you find a meeting spiraling into defensive communications, e.g., hearing a lot of "I don't think …" or "no that's not …" try to pull it out possibly by pointing out the defensive patterns observed. If you find someone keeps shooting down ideas create a forum (meeting, community-blog, etc…) of some kind having the sole purpose of generating ideas and forbid any negative comments for a period of time (a week or two) after an idea is posted. Another issue raised was how to handle someone who doesn't follow through on tasks? Create a list of action items at the meeting and check-up on each person about their task. If they have not completed it ask if they still "want to own it". If not, move it to the orphaned list. At the next meeting review the list, if important items are on it they will be addressed.

The other technique we did was called spectrogram and is meant to get the range of opinions on a critical issue. We choose the question "Can you trust Microsoft?" A line of tape on the floor represented the range from "yes" to "no" with the middle being "don't know". You stand on the line where your opinion lies. (I was alone at the "no" end, surprising since this was at OSCON.) Most people hovered around the middle. Next, we had someone ask people why they chose to stand at this point on the line. It was enlightening to here other points of view. A lot of people seemed the feel that Microsoft is changing for the better these days.

Kaliya had another technique called speed-geeking that she wanted us to try but time ran out. Overall it was good excellent session and I learned a lot.

Benjamin Smedberg also blogged about the session.