I have done a new presentation on the 5 year journey at EDS, building an open source community within a Microsoft addict Corporation.

30 September – 1 October 2010, Paris

The Open World Forum is the premier global summit meeting bringing together decisions-makers from across the world to discuss the technological, financial and social impact of the Free/Open Source world, and to cross-fertilize ideas and initiatives in these areas. It offers a unique opportunity to:

• Discover the latest trends in open technologies
• Explore the future of Free/Open Source initiatives
• Share  insights and best practices with many of the most respected visionaries, entrepreneurs and community leaders worldwide
• Network with 1,500 decision-makers, Free/OpenSource gurus, CxOs, analysts, CIOs, researchers and investors from 40 countries.

I will be presenting a short how-to on “building a community within a corporation” within Floss Visions conferences .
This presentation will focus more on process than the previous one I gave earlier this year.

I had the pleasure to give a short presentation at Solutions Linux in Paris, a short journey through the creation, building and management of EDS Open Source Community.

The slides can be found here.

Posted via web from New Balance

First we created JOSS, Journal of Open Source Software, based on SPIP, a simple open source publishing system for internet. The purpose of JOSS was first to collect and re-publish interesting news on open source, thus creating the place to go for open source news. Then people started to contribute and write their news on open source at EDS.
I would give the same advice than for the mailing list. There should be at list one news everyday.

Second, we created RING, Ring Is Not Gforge, a forge based the open source version of Sourceforge. The purpose of RING was to provide an environment for members to collaborate on real projects, creating and delivering assets. RING was first used to “publish” existing assets since there was no entry barriers. Then, people started to collaborate developing snippets that solved their day to day business. Further, they collaboratively develop assets to deliver to clients. RING was the best tool we used to really penetrate the corporation.
After few months, RING became EDSource, EDS source for reusable assets, something I will write on later.

Third, we created a monthly newsletter, EDSource Newsletter, which ends up with more than 1000 regular readers. Indeed, we used the success of EDSource to communicate widely and deeply on open source software. I will discuss EDSource Newsletter later.

I should add another very interesting initiative named “Monday Morning Thoughts”. Every Monday morning, I used to send an email on a subject related to open source for discussion. The subject was a little bit provocative.
This had two main effects :

1. Start the discussion on the mailing list after the week-end
2. Create a ritual

This last point was more important than I thought. And I remember some emails I received when I was unable to send the “Monday Morning Thoughts” during vacations, traveling, … Hopefully, now there is twitter – and iPhone.
I would recommend to create rituals within your community. It should be simple, frequent, generate reactions and repeat almost forever.

I learnt a lot from these intiatives :

• Start small but never stop growing
• Find a hook to grab the corporation
• There is life where there is something happening. Silent is death.
• Create rituals people can refer to

To give a little bit of context, my team and I were located near Toulouse – SW of France – in one of the smallest agencies of a huge American company. In a nutshell, we didn’t exist, but we knew it !

We were convinced that EDS could not avoid Open Source. More, EDS had to embrace Open Source practices and the Open Source Community was key in this change process.  To promote our ideas, we decided to be very active and visible from the beginning and to speak with one voice.
One strategy we adopted was to have only few people from the team sending emails to the Community. In fact, I was almost the only channel used by the team. In a short period of time, I became “JY” in the Community. And it gave me the freedom to suggest and the privilege to be listened.

Another strategy was to share what we were doing on the open source side with some clients since EDS was running interesting projects, one of them being introducing open source within a major telco company.

I have learnt a lot from the team – some of them being involved in Debian community for years – on how to email : short, strait to the point, positive, with real value (vs show off).

I learned to lead while practicing. And I woud say that leading a community is about 4 main things :

• listen to what is said and to what is not
• respect all community members
• be collective
• create a vision

It is crucial that you take your filters off, the ones that make you see red when it is orange or green. If you really listen to the community you get tremendous information on their motivations.
This doesn’t mean you do not have any position, any point of view. You must have one.

A leader must care about the community. That means :

• there must be at least one email a day : write it
• bring out the positive from the negative
• leave a space for other leaders to emerge
• focus on the Community interest not on yours
• send positive stokes, warm fuzzies both private and public
• trigger people motivations among the 16 available

A community is a collective experience.  Play collective.

To do so, we first did 4 things :

1. we created our front page on the corporate website : objectives & registration
2. we sent emails invitations to  our network - friends, colleagues - within the company
3. we sent invitations to departments that would be interested in joining
4. we sent invitations to all community leaders who forwarded to their members

I was also leading a small group of Open Source geeks locally. We had a brainstorm from where came out few ideas of projects we shared with the new community. Thus, we started to feed the Community with ideas and potential projects such as OpenCoE - a Linux Desktop -, Amistad - a Linux Server, and few others.
This created immediatly a lot of activity on the mailing list which was the main media we used. The discussions around these projects created new discusions and also generated requests for advice or assistance. This last point is key because the community was able to create value from the beginning.

The coreteam spent a lot of time – and some nights – trying to organize the discussions and the information. We wanted to understand where the community would be able to engage – what project – and to make our best to turn ideas into something concrete. So, we started to communicate to our Management and to the EDS fellows on some of the good ideas that emerged from the discussions.

The discussion also generated some negative posts, mainly complaining on EDS position towards Open Source. Indeed, EDS was qualified as a “Microsoft Company”.
You must be prepared to it. I will write later on this subject but the main advices are :

• listen to the negative posts, do not ignore them
• be constructive taking the positive side of the message
• don’t feed the troll

What did I learn ?

• Get your members where they are, use the tools they use
• Suggest subjects of interest to create initial dynamic
• Be prepare to negative feedback and manage them
• Find a way for the community to create value – even very small - as soon as possible
• Communicate with your Management

And I encourage you to train like a sailor to sleep little for a while.

EDS Knowledge Management department was providing support to Communities of Practices : a documented process with several steps, roles, activities, input, output, tools (mainly a mailing list), governance and a forum for community leaders to share ideas and knowledge.
This made easier the creation of a community and it was a formal recognition of role of Communities within the Corporation.
On this other side, EDS could keep an eye on the Communities and influence them, injecting some Corporate objectives and values.

One of the key best practice when first creating a community, is the leadership. It should be legitimate within the Corporation and among the future community members. This is key in a Corporation since leaders make the necessary link between the bazaar and the cathedral.

Charles, who was leading EDS midrange servers hosting services, was our first community leader. Charles was an “old EDSer”, able to understand EDS strategy and thus discuss with top management. Moreover, Charles’ team was running most of the Linux and Unix systems for EDS clients.

We formed a coreteam with whom we thought were the most legitimate people :

• Mark : leader of Linux on Mainframe activities
• Franco :  Charles counterpart in EMEA
• Erik : the Knowledge Management group representative
• Jean-Yves : the energy guy

We defined our objectives and published them on the “Corporate Community wall”. It took us some times to formulate it through several, simple items. But I know believe we could have done it easier if we would just have agreed on the main objective : “promote open source software within EDS”.

I have learned 2 main things at this time :

1. How important it is to work on both sides – Corporation & Community – when you start building your community. And how important it is to have relays since the beginning because you cannot be everywhere. Forget it !
   You need a group of committed people, a coreteam, woking for the same purpose.
2. You can define any objective, publish it anywhere, what count at the end of the day is what you do ! So, decide with your coreteam what you want to achieve, say it simply and do it !

One element to also take into consideration is the leadership change that can happen because people are leaving the company. I will write more on this subject later but you should consider it from the beginning. There is little chance a Community in a Corporation can survive if the only leader is leaving. You need to reach the right level of maturity and at least a Collaborative Leadership… and few more tricks.

Indeed, I had lead EDS Open Source Community from the beginning until … the end.

I couldn’t give him a short answer. So, I decided it may worth it to share my experience building EDS Open Source Community. It is neither a strategy  nor a framework. It is only a short human story where I tried to listen and learn during the journey.

EDS Open Source Community journey starts during fall 2003.

It is late evening in my Office, Christophe and I having a confcall with 2 influent people at EDS. Tom is an EDS Fellow, Sue is in charge of Microsoft partnership at EDS for EMEA. Although they have different motivations in creating the Open Source Community, they decided to help us, behind the scene. And their help is essential for the journey as you will see later.

They are our “moral approval” when we cross the borderline and they can connect us with the right people.

The first lesson I learned is that you need a sponsor, high enough in the management chain, when you want to create change. I would prefer an invisible sponsor – behind the scene – rather than a too visible one.

The data provide a snapshot of the state of open source policy. Open source
policy is divided into four categories: research, mandates (where the use of open source software is required), preferences (where the use of open source software is given preference, but not mandated), and advisory (where the use of open source software is permitted). They also looked at whether an initiative was made at the national, regional, or local level, and whether it was accepted, under consideration, or rejected.

In 2008, they found 275 open source policy initiatives.

Extract of the introduction :

“Changes in the software industry have affected open source policy. Many software companies are creating new business models that blend proprietary and open software development. One result of this shift is that software business models at many companies focus on how to capture the benefits of collaborative processes in coding (including collaborative processes involving both employees and non-employees).
The business model at many companies has diversified beyond writing code to include the provision of services, acquisition of smaller innovative firms, and a focus on collaborative, standards-based development. Standards and standard-setting are particularly important for business models that mix open and proprietary software. Standards provide the basis for the collaboration. While there is general consensus that “open” standards are best – as they expand the scope for collaboration and innovation – there is less consensus on what qualifies as open. Software designed to an open standard can be either proprietary or open source. The result is a complex mix of issues involving intellectual property and competition. The open standards discussion exhibits some of the same tensions (but not the same degree of heat) as the open source debate. We have not counted open standards initiatives unless, in our view, they embodied a de facto requirement to use open source software.
By mid-2008, a majority (70%) of the open source initiatives we found were described as completed. Final action had been taken on 193 of the 275 open source policy initiatives. One hundred seventy-seven were approved and sixteen rejected (decisions remain pending for the rest). Since our last survey, we found only twenty-three new open source policy initiatives around the world. Our estimate is that the open source debate is being subsumed into a search for business models that can profitably blend open and proprietary processes and products.”

Worth a look … and a discussion …

JY