[Update: for french readers, a translation is available here]

Well, it’s actually day 2 of the Open Source Think Tank 09, but I wasn’t able to attend to the whole first afternoon because of some travel trouble. Apparently I wasn’t alone: the audience grew by 35% today ( this from visual impression, not real data). I’ll report on the insightful talk by Mark F. Radcliffe in a specific post about legal aspects of the OSS ecosystem.

Overall I think the audience is skilled, smart, experienced, very available and open to the discussion. And we're all here because we're involved in the business of open source. The level and the number of my fellow attendees show how much the open source ecosystem has grown for the past 2-3 years. There is serious business being done here, more than ever, and it's just the beginning.

So, to get back to today’s session…

Business case “how to a business leveraging an open source project?”

We started with a “Business Case”, where the audience is divided in workgroups (of 6-8 people). Each group works to answer a set of questions and when time's up each group presents the results to the audience. It’s interesting to compare the results, obviously, and highlights the differences, that are usually interesting takes / ideas.

Today’s business case was about “Start a software company from scratch, leveraging a popular open source project”. Here is an extract:

Company “C” is a recently established venture-backed commercial open source company looking to capitalize on a very successful open source GPL-licensed project with a large supporting community. Company “Cs” application is principally a commercially supported version of the project, with development focused on productizing the project and developing plug-ins that make the product more directly applicable to a specific set of customers they are targeting.

The community is mostly developers from a wide variety of backgrounds – about half are individual contributors to the project, and half are contributors from companies that see a potential use for the technology within their company and for their customers, both end users and SIs and ISVs. None of the key developers is interested in “new” employment, feeling they can best run the project from their current positions. Company “C” currently does not employ any of the major contributors. Company “C” has developed a product roadmap that extends the product into a fully functional set of applications targeted at global retailing. They have received very positive feedback from several beta sites that have deployed the new applications. Company “C” however, has not formalized the sales and marketing strategy beyond a few “proof of concept” beta sites and is looking for guidance on how they should launch their product in the face of a community that has no established relationship with Company “C”.

The first reaction to this from open source vendors was: “I want to talk to that VC guy!” because investing in a company wanting to build on an open source project without being involved whatsoever in its ecosystem is pretty bold move…

To complete this, most of the groups made the following assumptions:

• what the company is really doing is making a vertical product on top of a generic platform

• while being GPL, the project allows to build proprietary plugins / extensions

• there is no other company involved in the project that might offer a similar product / service

From this, here is what came from the groups about the following questions… [note: I'm summaryzing, the main points resulting from the brainstorming. I might have forgotten / misunderstood some, so don't hesitate to correct / comment.]

A. How should Company “C” approach the community? What are the 3-4 must do?

1. Get involved without antagonizing the team: communicate often, be honest, explain your intentions and where you’re going [Personal note: I think this is valid when starting any business, OSS or not]. Also, keep a low-profile and do some work. For example starting with some “easy but boring work” that nobody took the time to do, might be a good start. And again, communicate, keep  the core developers posted about your experience, successes, failures, feedback from actual customers/end-users. Developers usually like to know how people actually use their product.

2. Get goodwill: proposes bug fixes, propose extensions / evolutions, participate in architecture debates. You might also pay some consultancy work from core developers. Your work needs to be of  interest to the community, some of the company’s plugins might be open source too.

3. Have a distinctive identity: don’t steal the project’s popularity (by using its brand without asking for permission), differentiate your offering by addressing a different market than the project’s one, do not compete with an already established and recognized company

4. Become a contributor: if you’ve followed the previous 3 items, there is good chance you’ve got committer-level access rights. If not, since the core team cannot be hired (it’s in the assumptions), you can try to hire non-core developers that are yet involved. Offering them to work full-time (or a lot of time) on the project might close the deal and let them be more involved, getting more weight in the community.

So globally, it’s like most things in life. Don’t be rude, stay open and fair, work hard. That’s all it takes. People involved in OSS project are normal human beings, after all.

B. How critical is it if the open source project leaders don’t commit to incorporating Company “C” contributions in a timely manner? How can this best be managed?

Is it surely critical if you can’t get your patches in the product fast enough. You can manage it by talking with the core team openly about this issue. Understand why your patches are not going in faster: might be a problem of process, quality, doc, direction, etc. Fix it and you’ll get your patches in. If you’re doing a good job and that it’s just a lack of resources from the core team, there is a good chance you’ll get committer rights.

C. Is it important for Company “C” to take control or fork the original project? Under what conditions might this be the case?

General consensus: never fork for any reason.
Especially when it’s done like a “declaration of independence”. It will attach a nasty reputation to the company and you’ll have to make a lot of effort to get rid of it, plus do the usual amount of work required to make an OSS project successful. So it’s usually a very bad idea. [Personal Note: I’m not aware of any successful fork from a community project, so take this recommendation seriously].

There is several ways to work faster than the project, is you need to. First, you can maintain and make public a “vendor branch” of the core product. And anyway, you’re gonna need it, technically, to work easily and propose patches. Making this branch public and how you advertise it is the key here. Present it as an “experimental branch” or as your “dev branch” from which you can propose consistent patches and let people get involved with your work and contributions.

So don’t fork and work openly on the code. If you’re producing good code, there is a good chance other people will notice it and it will give you traction and weight in the project.

D. Under what circumstance would involving a standards body make sense?

Simple answer from all groups: “none”.

More seriously, a standards body might make sense if you want to standardize an existing protocol/model, which might be the case as the project we’re are discussing is already mature and popular. An example of this is Jabber Inc. standardized its Instant Messaging protocol after having worked with it for a few times and open sourced the implementation. And it was a wise decision, creating value and growth for the company (as well as for all vendors/users that are leveraging the protocol).

E. Can you identify one or two situations where prioritizing the community over its product roadmap (and customer base) may make sense for Company “C”? What are they?

Interesting question, too. The answers were pretty much the same, here:

1. If you’re proposing a contribution and you get the answer “Good idea but I would prefer to see it done on another way, could you change this before I integrate it?” from the core team, it makes a lot of sense to do it even if it delays your product a bit.

2. Keep aligned with the core product and avoid maintaining a fork, which can be the easy way when you’re in a rush for a delivery. Don’t forget to reserve time to keep up with the development of the core product, and port your patches on it. It’s a short term pain / long term gain.

And keep in mind: what strengthen the community strengthens your business.

Talk from Mårten Mickos and Mike Olson on “Exit & Acquisitions”

For the newcomers to the OSS ecosystem, Marten is the former CEO of MySQL (acquired by Sun for ~$1B) and Mike is the former CEO of Sleepycat (acquired by Oracle for an undisclosed amount — where undisclosed sounds like a nice one).

It was a great talk about selling an (open source) company to a large corporation. How the process starts, how it has been managed, how it feels like to sell, how life changes, how it feels after… and many other topics! I won’t transcript the whole talk here, because I’m running out of time.

It was a very interesting, inspiring talk and discussion. Enjoyed it a lot. Thanks to Marten and Mike for sharing their experience.

Wine Tasting & Dinner

I wasn’t able to attend to the wine tasting session scheduled in the afternoon, because of some important business commitments. But I heard great feedback! (no kidding…)

The dinner was pretty good and allowed me to engage fruitful / funny discussions with some great people of the OSS world. Sharing experiences and vision about open source business, or just talking about where I should go next time I’m in L.A.

Not sure I can put names here because of the (wise) blogging policy of the think tank, but it was fun and interesting. Thanks to all the people at the table (and others too, btw).

So far, great experience. Interesting discussions. Don't hesitate to comment on this post if you want to get involved / react to the discussion that has started here, in Napa.

See you tomorrow, for the next episode!

EB.

• Previous Entry: Open Source Think Tank 2009 (and meet up availability)
• Next Entry: Open Source Think Tank 09 – Tuesday & Thank you!