A Community View from Behind the Wall

December 6, 2005 2:46 pm General

As mentioned in my previous mail a number of us sat down during a set of brainstorming breakouts to talk about a rather broad topic, ‘Community Relations’. In particular, all these breakouts were supposed to focus on 2 sets of target users, Developer and Small/Medium Business System Administrator. However, much of the discussion was obviously generic enough for many projects and open source communities both within Sun and outside. We had attendees from GNOME, Mozilla, and XOrg communities – and I’d personally like to think that we had a reasonably strong idea of what community participation meant in those areas.

In this session we started off with a bit of discussion around the topic, and then started brainstorming the issues involved using stickies and a rotation mechanism. Each person in the group started writing down issues on stickies. After a set number of time, the stickies they collected were put on a sheet of paper. That sheet of paper was passed to the person on the left. As a result, each person got to see the stickies from the person on their right, which meant they could develop those issues, or think of other issues based on the stickies. Very simple, but amazingly effective, and I’ve personally never done any brainstorming like that previously.

After brainstorming to identify the main issues that were being faced, the team managed to come up with 4 main topic areas –

  • Create and Grow communities
  • Communication
  • Interactions, goals, dependencies, costs, authority
  • Mechanics, Processes, Standards, Rules, Licensing, IP

We had some interesting comments being written on the stickies –

  • VP’s talking about Open Source, but lots of employees not really groking what that means
  • Differences between proprietary projects and open source projects and how used to a given process an individual developer is
  • Enforcing old legacy processes into new environments that don’t fit
  • Management need to assign goals and growth targets for employees to measure their involvement specifically for open source development
  • Difficulty in understanding what community interaction meant
    • how much time involved
      • purely development?
      • development and mailing list/IRC interaction
      • dev/interaction/new projects unrelated to direct job
  • Hard to find information about what communities are available, how to get involved, how to build, how to grow
  • How do we expect to be successful in a community if we can’t be a community internally?

We then brainstormed the most important next steps, voting on their popularity

  1. Provide education and support for people unfamiliar with open source practices
  2. Educate all Sun employees about the realities of community relationships
  3. Clearly state Sun goals around all communities (open source and proprietary) and practices to reach goals
  4. Assess risks of diverging before forking – persuade community otherwise if possible
  5. Ensure that all community related Sun teams are leveraging each other
  6. Build infrastructure where necessary, provide info/pointers where resources already exist

Before anyone thinks that Sun has a problem with working and managing projects within open source – it’s actually quite the opposite. I could only see a set of hugely clueful people discussing the topic, continually striving for excellence on how we might be even more effective. The great thing is that we have an Open Source Council led by Simon for exactly these types of discussions, and I’m very excited to see how some of these will be addressed in the future.

Comments are closed.