Sessions at Open Source Bridge 2009 about business entrepreneur opensource consult on Wednesday 17th June

In this talk, I will share my experience growing a open source consulting company from a one man freelance operation to a global corporation employing 20 persons in 8 countries. We will explore some of the challenges that a business owner will face, and the unique issues that a company building open source software must embrace.

What does it take to be an open source consultant? It's usually not enough to be a good developer. You need to know about the business side of software development, including sales and marketing and legal and accounting. Fret not - just like programming, these are skills that can be learned!

How do you find work and how do you determine how much to charge? We will discuss the merits of time and materials billing, optional scope contracts vs. fixed bid contracts. Blogging, speaking at local tech events and search engine optimization are some inventive ways to attract new customers.

How do you compete against commercial proprietary software vendors and dispel the myths around open source. What are the unique selling points that can help catapult your company to the shortlist? Positioning your services and finding a niche are essential to differentiate yourself from other competing vendors.

How do you structure contracts to allow for the software you create to be GPL licensed? The legal issues cannot be overlooked if you want to ensure your software remains open source. Education of your customers is important to get them to think of software not as an asset, but a liability.

How do you recruit and retain talented developers? The transparency of open source software provides you with developer footprints that reveal far more about a developer's technical skills than any resume. I have recruited some of my best developers solely by reading their code and their blog posts to get a sense for how they communicate.

Open source software is often developed by distributed teams, in which the leaders and developers are geographically dispersed. Can this team dynamic work for consulting projects? We've learned through many failed attempts what works and what doesn't, navigating timezones, multi-currency payments, remote pair programming, and global conference calls.

How can you be a profitable company and still be a good citizen of the open source community? Where do you draw the line between paid customer work and unpaid community work? If structured properly, the community work can complement the billable work and vice versa.