OpenSolaris: Lessons Learned

As Sun opens more of its software, some people from other projects around the company have been asking me what we’ve learned from OpenSolaris. They’d like to benefit from our team’s experience, and we are more than happy to help. So, here is the beginning of my “lessons learned” (in no particular order right now). Consider this a working draft of my initial thoughts. They are all personal, so you may or may not agree. I already listed some lessons learned from the OpenSolaris Pilot Program, so these lessons grew from those lessons. If you’ve been involved in OpenSolaris, and you’d like to share what you’ve learned or comment on these, please feel free to contribute. I’m going to keep building this list by adding new lessons and descriptions, so this entry will grow until I stop learning. Which means it’s going to get really, really big. Since I’ll be editing this post consistently, I put a link — Lessons Learned — in the right nav bar.

OpenSolaris: Lessons Learned

1. Think in terms of collaboration, not feedback – the community is not your focus group.

This issue came up occasionally during the early pilot days last year. We were supposed to be building a community, but sometimes we saw the pilot as separate from our internal program team. So, you always heard something like this: “Go get some feedback from the pilot.” In other words, we are in here … go out there and get their feedback … and bring it back in here for evaluation. The problem is that you get feedback from a focus group, not a community. The culture of a community seems based on direct participation in the creation of something, not getting feedback on something when it’s already done. Now, as a practical matter, many people in the community do offer feedback along the way, and that’s great because people participate at different levels. But if you view the entire community as simply a feedback mechanism, you’ve missed it. If you want a community, you need to participate as an equal and involve people early.

2. Encourage people to join the community and work from within the community – all groups, not just the engineering implementation team.

Many times people asked me to send their stuff to the community. Plans. Messages. Whatever. After I learned lesson #1, though, I started telling  people that if they wanted their stuff sent to the community they should join the community and engage in a conversation about their stuff. If it’s good enough, it will fly. If not, oh, well. Try again. So, anyone who touches Solaris in any way whatsoever should join the community — marketing, service, docs, engineering, etc — and do their business from within the community by involving the community. Everyone has something of value to contribute. Otherwise, there’s an “us” and “them” mentality that hinders the process of building a community. Even now, more and more teams throughout the company are engaging the OpenSolaris community. Which is excellent. I’ve said it many times since joining this project … OpenSolaris is transforming Sun.

3. Encourage debates, but ignore flames and competitive attacks (but expect them).

I’ve bounced back and forth on some of these.

First, flames. I don’t like dousing flames on mail lists. If people want to have a knife fight in front of thousands of people on list, I’m going to pull up a chair and watch the show. Every time I’ve tried to assertively put out a flame, I just got burned or ignored. Flames come and go. Don’t contribute to them, but don’t worry too much, either. Just try to increase the number of quality people on the list and the flamers will have less to say.

Second, debates. These are excellent, but they require that you educate some people that debates are normal and healthy and generate new ideas (as long as they don’t degenerate into flames, of course). This is generally not an issue at Sun because we debate everything to death anyway. So, most people are used to it. Some people, however, may be uneasy about debating across the firewall. Take it slow and stick to what you know.

Third, competitive attacks. Now this one drives me nuts because there really is no right answer for all circumstances, and I’ve never — absolutely never — been convinced otherwise. It all depends on your style, your belief, your skill set, your guts, your resources, and the competitive situation you find yourself in. I’ve played all sides of the fence on this — the sides generally being (1) ignore them, (2) attack back ten times harder like Al Capone, (3) attack back but via third parties, so there are no fingerprints, (4) simply correct the FUD dispassionately and move on like you are above it all. They all work well in some situations and fail miserably in others. My current thinking is that competitive fights in public forums burn too much energy, so ignoring is probably the best option in the long run — as long as you are moving fast in asserting your own agenda (or project, or whatever). Focus more on your positive, and less on reacting to their negative. OpenSolaris generated a lot of competitive response because it made some people nervous out there, and I spent a lot of time defending this project in my blog. It burned me out, to be honest, so I’m more included to either ignore a direct attack, make fun of it, or deflect it to talk about an issue without even actually responding directly.

4. Focus on people writing and talking about code. It’s all about the code. Don’t fool yourself.

The single most import element here is the code. In fact, what strikes me most about this project is just how much the code pervades every conversation I hear and read. It’s all about the code. Great developers get together around great code, and the conversation grows directly from how involved everyone is.

5. If you have an NDA pilot program, run it as one team, not two.

We could have easily made our internal implementation team part of the NDA pilot program itself with one list for communication. One team, basically. For me, it became confusing … this part is “internal” … that part is “external” … be quiet here … open up over there. In retrospect, it wasn’t necessary for most issues I was involved with, but I suppose we had to learn this slowly so I’m ok with it now. We’re opening more and more teams as we go, and that’s great. And I’m actually un-subscribing from various internal lists because I don’t want the traffic. I’m only interested in open conversations. Things move faster in the open, anyway.

6. Use the NDA to define your pilot identity and share everything with your nascent community.

We could have done a better job at this one, but again, perhaps we needed to experience it slowly. There was no model for what we were doing, after all. But I figure, if you have an NDA, your pilot community is locked in, so you may as well open up to them, right? In some areas were were re
markably open — to the point of really stretching that NDA, too — but we could have gone further here in other areas. As it is, we learned a great deal from the pilot experience, and that program helped change this company. I wanted to do more, though. I guess my point is, don’t be afraid to go further than we did.

7. Dump internal lists or make them public.

We still have a lot of internal project lists. Some are necessary because a given project is still internal, but they are migrating, so I’m not concerned. Other internal lists are just hold overs from the closed cathedral days. Trying to close these closed lists is somewhat challenging, too. But they serve only to distract people from the openness of the project, and they keep the conversation fragmented. So, if a conversation is not confidential, get it out in the open. If it is confidential, keep it on a properly marked internal list and keep the number of people on that list small. I have zero interest on being on confidential lists, by the way.

8. Transparency increases speed in most cases because it shines a light on internal politics.

Some people are concerned that dealing with large numbers of developers and users in a community will slow things down. All that extra email! This may happen initially, but in many instances transparency actually increases the speed at which things can operate. This is anti-intuitive, but I’m convinced it’s true if you give it a chance. Perhaps it’s because transparency reduces the internal politics by shining a light on the trivial things we sometimes focus on. Perhaps the openness naturally attracts the people who are specifically interested in a given project, so you weed out the non-performers without offending anyone. I don’t know. All I know is that for my activities, working in the open is faster and it’s not even close. NOTE: This issue fascinates me more than any other in this list. I’d especially like to hear about what you have experienced.

9. Make core governance and development decisions before opening even if you have not fully implemented the system.

We didn’t launch with a lot of initial infrastructure for co-development, which made things somewhat difficult for the non-Sun community members. However, external community members can search the bug database, report bugs, offer fixes, and request sponsors to putback that code. And they are. Which is great. And more is coming, obviously. But the point is to think these things through (remember: the code is the most important part of the project) before opening, so you can lead strongly through the implementation process when you are open. We have been planning for co-development all along. We specifically wanted the broader, post-pilot community involved in the decisions since the pilot community was small (by necessity). We set up the Community Advisory Board (CAB) to develop an OpenSolaris Charter and Governance (both currently drafts on the CAB’s open list), and there’s an internal team (with three CAB members participating) working on specifying the actual co-development infrastructure. People want this part of the project to move faster (and we do, too). We hear you.

This issue is also important because you want to know what kind of community to build. Some people asked me really early in the project — like pre-pilot early — what the OpenSolaris community would look like. They asked for a prediction, basically. Yah, right. They’d ask this — over and over again — before we had a license, before we had business model, before we had a CAB, before we had a Charter and Governance, before we had a co-development plan. Nice, eh? I ignored them, basically. I simply just keep on saying that we are transforming the Solaris market into a community, and that community would consist of Solaris developers, system administrators, and users from Sun’s customers, ISVs, and partners. That’s your community. The key, however, is how would Sun engage, build, and grow that community. To answer that question you have to also answer the governance, license, business model, and infrastructure questions. They are quite directly linked.

10. The conversation is the (Cluetrain) marketing.

It’s best to not market to a community from the outside by shouting “messages” at people. Instead, marketers should join the community and participate in the marketing process with the community as co-equals. I think we’ve done a pretty good job on this one for a corporation. We had a pretty interesting launch with more than 150 Solaris engineers blogging personal tours through their code, and there were dozens and dozens of community blogs that lit up on launch day as well. We’ve been open about our intentions to open Solaris all along, too. Yes, there was a press conference (pretty traditional), but we had engineers meet the press along with the executives (an improvement). There was no formal press release with quotes, though. Instead, PR sent out what they call a “media advisory” and we tried to keep their pre-briefings down to an absolute minimum. We wanted the blogs to lead, we wanted the code to lead, we wanted the community to lead. For a year, I had advocated no launch at all. I just wanted to open the site when the code was ready, and, well, that’s it. The community is already well connected on list and via blogging, and besides, no one would expect that from Sun, right? Some (read: most) people thought I was nuts, of course, but I had no time for a traditional marketing/PR-driven launch on this project. Then Bryan came up with the idea of a blog launch. OpenSolaris would be launched on So, he sold it and went about driving it with Liane. It worked out great, and I’d argue that the OpenSolaris launch was the single most credible thing Sun has done for developers  since I’ve been at the company. Ok, I’m biased but whatever. So, if you want to do marketing on an open source project, go Cluetrain and join the community.

11. Credibility and reputation grow from involvement, humility, work, and code – not talk.

We did a lot of talking leading up to the opening of Solaris. Too much, actually. I’m glad we were open about our intentions, and we did get some credibility for opening our conversations in the press and in our blogs. But I would have been more comfortable had we launched a little earlier or cut the chat a little along the way. I also think we sometimes confused corporate competitive issues with community building issues. I know I surely did. Also, for a very long time we didn’t have much to show; we were running a closed, NDA pilot. It wasn’t a real big deal in the end because we knew the code was coming, but if I had to do this all over again … well, I’d tone it down a little.

12. Focus the project goal and strategy on the opportunity to do something great,
not on trying to solve issues common to all products.

Having a strong, clear goal is the way to go. We sometimes churned with lots of little goals that were all good but pretty typical for a corporation. This is one area I think we could have involved the pilot community more. To me, I see the goal for OpenSolaris as being the perfect opportunity to build a community around some really amazing code. Everything grows from that. And I see three groups directly involved: (1) The Sun executives want to expand the Solaris market, drive Solaris into new markets, and sell more systems and services. (2) The Solaris engineers want to engage developers outside the company, share code, and improve an already great system. And (3) the Solaris market/community wants to see the code, optimize applications, contribute to Solaris development, and create ports and distributions of their own. The strategy for all this involves transforming the current Solaris market into the new OpenSolaris community. Sun is opening up and engaging the Solaris community (developers, sys admins, customers, ISVs, partners, universities,  users …), and we are quite literally enfranchising that community with an open source license, a governance based on merit, and a new co-development infrastructure. I’m trying to put all that into one sentence. 🙂

13. Be prepared to lead.

Leadership is just as important in community building as it is within a corporate or government structure. It manifests very differently, though. In communities, power seems to be distributed among the people who have earned the credibility because they have done the work. And since these people work transparently everyone knows what they’ve done. This is not always true in a traditional environment. Also, what I like about the culture of leadership within a community is that leading, following, and learning seem to mix pretty seamlessly. And there’s an endless amount of opportunity for those who are willing to work their way up to a leadership position.

14. Don’t manage the community like it’s just another project. It’s not.

A community is special. Treat it that way. Actually, you’ll have to since it’s not “your” community. Unlike an internal project, you are not paying your community, so you’ll have to lead by example. And it’s impossible to “manage” a community, so, again, the only way is for managers to join and participate. Manages may have seniority internally, but they have to earn their way externally within the paradigm of the community.

15. There’s no substitution for participation.

You can’t fake this, so don’t try. You are either part of the community and contribute, or you are on the outside looking in. Give it a try. Join the community. Be humble. Learn. Lead in your area of expertise, defer in areas where others are more knowledgeable, and earn your way like everyone else. Trust that someone else will be leading the things that you are not.


One thought on “OpenSolaris: Lessons Learned

  1. Good blog Jim,
    I’d like to make some observations.

    1. Your focus-group points are very important, there were many times we felt “disempowered”. If you want a community you must treat them with respect. This means that you have to “explain yourself” to the community particulraly in justifying why you have taken an action counter to the will of the community. This can be very very difficult for exec types.

    2. It’s important to give your community something meaningful to do while the “internals” are being churned. There could certainly have been much more involvement in building the web site or branding and other activities off the critical path.

    3. I think the scope of OpenSolaris “branding” could have been defined much earlier (It’s scope still escapes me). Infrastructure could have been provided much ealier for “branded” allied projects. For example a repository like savannah is for gnu, to house OpenSolaris allied projects. This one thing could have accelerated takeup by months and would still be a good thing to do. Console makers know this, when you launch you need 20-30 branded titles . Personally, I think we missed the ball on this one.

    4. Finally, I think your point about working with a bunch of opinionated volunteers is critical. It’s critical to understand that these volunteers are in it for themselves, the glory or the product. There is nothing keeping them there and you deserve no loyalty from them other than what you earn. If you try to treat them like employees (give orders) or focus groups (need to know basis) then your community will either die or drag you elsewhere anyway. BTW Jim, I think you earned your stripes in this respect, a great job.


Comments are closed.