Kinh doanh của nguồn mở

The business of open source

By Matthew Langham, Indiginox, Published: 03 February 2009, Reviewed: 17 February 2012

Theo: http://www.oss-watch.ac.uk/resources/businessofopensource

Bài được đưa lên Internet ngày: 17/02/2012

Lời người dịch: Có nhiều mô hình kinh doanh xung quanh một sản phẩm là phần mềm tự do nguồn mở (PMTDNM). Việc một công ty chọn mô hình kinh doanh nào cho phù hợp là phụ thuộc vào năng lực của chính công ty đó, có thể với những tư vấn kinh doanh bổ sung khác. Bài viết này đưa ra những mô hình kinh doanh xung quanh các phần mềm nguồn mở và những công việc mà một công ty cần phải chú ý khi lựa chọn các mô hình kinh doanh nguồn mở đó.

Thậm chí ngày nay, khi nhắc tới các từ 'kinh doanh' và 'nguồn mở' trong cùng một câu có thể thu hút những lưu ý kỳ lạ từ một khán thính phòng còn chưa được quen với thực tế là quả thực có một nền kinh tế kinh doanh xung quanh phần mềm nguồn mở (PMNM). Đã từ lâu các công ty sử dụng PMNM đã thường nghĩ rằng bất kỳ dạng hỗ trợ hoặc dịch vụ nào khác xung quanh các phần mềm 'tự do' cũng sẽ sẵn sàng không mất tiền. Trong khi sự hỗ trợ miễn phí đã không mong đợi thì được giả định rằng sự hỗ trợ chuyên nghiệp không bao giờ là sẵn sàng. Cùng lúc, các cộng đồng nguồn mở cũng đôi khi thấy khó để tương tác một cách cởi mở với các thực thể thương mại.

Tuy nhiên, mọi điều đã thay đổi và những ngày này chúng ta có thể thấy sự tham gia cởi mở giữa các cộng đồng nguồn mở và các công ty thương mại hóa các phần mềm được các cộng đồng đó sản xuất. Các công ty cũng đã bắt đầu nhận thức được rằng việc kiếm tiền từ phần mềm nguồn mở, khi mà không trao bất kỳ thứ gì trở ngược lại cho cộng đồng hoặc dự án có lẽ là cuối cùng sẽ gây ra sự thất bại của các sản phẩm nguồn mở có liên quan của họ. Các tổ chức từng được thiết lập xung quanh các dự án nguồn mở, như Quỹ Mozilla, Quỹ Linux, Quỹ Eclipse và Quỹ Phần mềm Apache đã làm việc cật lực để thúc đẩy sự tham gia giữa cả 2 bên và điều này đã tạo ra một số kết quả mà có thể, cho tới rất gần đây, đã từng được xem là 'không thể'. Ví dụ, Microsoft, về lịch sử là kẻ chống đối kịch liệt nhất đối với mô hình phát triển nguồn mở, đã và đang đóng góp và đỡ đầu cho một số cộng đồng phát triển PMNM chủ chốt kể từ năm 2008.

Ít năm gần đây nhiều mô hình kinh doanh khác nhau đã tiến bộ xung quanh PMNM và vì thế nó đã trở nên quan trọng cho một nhà cung cấp nguồn mở tiềm năng để nghĩ thận trọng về mô hình kinh doanh nào có thể phù hợp nhất để làm bền vững cho sản phẩm và thị trường đích theo yêu cầu. Bài viết này đưa ra tổng quan về các thành phần khác nhau của các mô hình kinh doanh nguồn mở. Một tài liệu bổ sung đưa ra các vấn đề về tính bền vững có liên quan tới việc xây dựng các mô hình kinh doanh xung quanh các dự án nguồn mở.

Nguồn mở không phải là một mô hình kinh doanh

Trước hết, và có lẽ rõ ràng nhất, điều để chỉ ra, là bản thân nguồn mở không phải, và không bao giờ từng là, một mô hình kinh doanh. Các nhà cung cấp sẽ khác nhau trong việc sử dụng khái niệm nguồn mở như thể nó từng là cách tiến hành kinh doanh. Nguồn mở, đơn giản mà nói, là một cách thức phát triển và phân phối phần mềm.

Khi nhiều hơn các tổ chức thương mại đã bắt đầu hiểu những ưu điểm của việc sử dụng và tham gia với nguồn mở, thì cũng trở nên rõ ràng là đã có những rào cản mà các nhà cung cấp nguồn mở cần phải vượt qua trước khi họ có thể thực sự bắt đầu thay thế các giải pháp đã hình thành bằng các sản phẩm của họ:

• Những lệ thuộc không rõ ràng vào các thành phần phần mềm khác và các cơ chế cài đặt khó

• Thiếu hỗ trợ và các dịch vụ mức thương mại xung quanh sự tích hợp và áp dụng phần mềm

• Lộ trình không rõ và thường là dự án rất 'động'

• Thiết các kỹ năng cần thiết trong doanh nghiệp

• Cần tới sự huấn luyện, tài liệu và giáo dục

Để vượt qua được các rào cản đó, các nhà cung cấp nguồn mở đã bắt đầu thiết lập các mô hình kinh doanh đáp ứng được các nhu cầu của các khách hàng thương mại. Các mô hình kinh doanh đó được xây dựng xung quanh các phần mềm nguồn mở (PMNM) và được xác định theo cách mà các dòng doanh thu sẽ được tạo ra. Sự lựa chọn dạng các dòng nào có thể được tạo ra phụ thuộc chủ yếu vào PMNM nào theo yêu cầu và vì điều này nên phải được nêu rằng không có điều như là 'Mô hình kinh doanh nguồn mở' hoặc 'mô hình kinh doanh nguồn mở tốt nhất'. Việc xây dựng một mô hình kinh doanh bền vững sẽ khác với việc phụ thuộc vào ai đó mà bạn đang bán cho, những gì bạn đang bán và những gì thị trường kỳ vọng.

Các dòng doanh số

Các cách thức khác nhau của việc tạo doanh thu có thể được chia thô thành các lĩnh vực sau:

• Đóng gói và phân phối

• Chào một giấy phép được trả tiền cho một sản phẩm nguồn mở

• Đưa ra các dịch vụ và sự hỗ trợ xung quanh một sản phẩm nguồn mở

Bổ sung thêm vào sự tạo doanh số có thể còn có các cơ hội giảm chi phí thông qua sự phát triển được chia sẻ của các thành phần phần mềm cốt lõi. Xem xét tiếp chủ đề này là nằm ngoài phạm vi của bài viết này.

Đóng gói và phân phối

Mô hình kinh doanh nguồn mở đầu tiên trở nên phổ biến là việc đóng gói và phân phối PMNM theo một cách thức mà làm cho dễ dàng để cài đặt và bắt đầu sử dụng. Những phát tán khác nhau của Linux, một hệ điều hành nguồn mở, là những ví dụ của mô hình kinh doanh này.

Thậm chí phần mềm mà có Giấy phép Công cộng GNU (GPL) có đi có lại có thể vẫn được bán với một phí. Thường thì, các công ty sẽ lấy phí cho việc đóng gói và phân phối phần mềm trong một vật trung gian như DVD.

Các cách thức khác để đóng gói PMNM bao gồm:

• Đóng bó các phần mềm với một thiết bị

• Xây dựng và phân phối một 'kho' hoàn chỉnh các thành phần nguồn mở

Những ví dụ của tiếp cận các thiết bị là các bộ định tuyến router mạng phổ biến dựa vào Linux. Trong các trường hợp mà ở những nơi các phần mềm nằm bên dưới được cấp phép theo một giấy phép có đi có lại như GPL, thì nhà cung cấp phải làm cho mã nguồn của phần mềm sẵn sàng cho khách hàng - mà không có lấy tiền thêm. Không làm được điều này có thể có nghĩa là nhà cung cấp cuối cùng có thể thấy bản thân mình ở tòa.

Trong mô hình 'kho', một nhà cung cấp biên dịch một gói PMNM hoàn chỉnh để đáp ứng được nhu cầu trong một lĩnh vực kinh doanh nhất định. Ví dụ, điều này có thể là một biên dịch các thành phần nguồn mở cần thiết để cài đặt và chạy trong một hệ thống quản lý tài liệu chuyên nghiệp. Mô hình này cũng được sử dụng để tạo doanh thu từ các dịch vụ, như chúng ta sẽ thấy sau.

Tất cả các mô hình phân phối và đóng gói tìm cách giải quyết 2 trong 5 quan ngại mà những người áp dụng nguồn mở đối mặt (xem phần 1), đặc biệt:

• Những phụ thuộc không rõ vào các thành phần phần mềm khác và các cơ chế khó cài đặt

• Lộ trình không rõ và thường là một dự án rất 'động'

Các lựa chọn thay thế thương mại

Nếu một nhà cung cấp sở hữu sở hữu trí tuệ (IP) hoàn toàn của một dự án nguồn mở, sau đó anh ta tự do chọn cách mà phần mềm được chào cho các khách hàng. Thường thì, một nhà cung cấp sẽ cung cấp một phiên bản phần mềm theo một giấy phép nguồn mở có đi có lại (thường được gọi là một 'phiên bản cộng đồng') trong khi cùng một lúc đưa ra một phiên bản thương mại (hoặc 'phiên bản chuyên nghiệp') của chính phần mềm đó. Điều này thường được tham chiếu tới như là 'việc cấp phép đôi' và từng được làm cho phô biến từ các công ty như MySQL. Những khác biệt giữa các phiên bản thương mại và cộng đồng có thể là:

• Sửa lỗi sẽ được áp dụng thường xuyên hơn và phần mềm được phát hành thường xuyên hơn

• Các module nhất định của phiên bản thương mại được thay thế bằng các lựa chọn 'tốt hơn'

• Các thành phần bổ sung được đưa vào trong gói phần mềm cho phép tích hợp trong một môi trường thương mại

• Phiên bản thương mại đi với một gói hỗ trợ như là cả bộ

Một nhà cung cấp nguồn mở cung cấp sự truy cập tới mã của phần mềm, vì thế cho phép một khách hàng tiềm năng cũng áp dụng và mở rộng phần mềm đó cho sử dụng cá nhân. Nếu khách hàng có thể 'làm được' với phiên bản cộng đồng (như bằng việc có khả năng hỗ trợ sản phẩm trong nội bộ) sau đó, một phiên bản cộng đồng có thể là đủ. Nếu không, sau đó khách hàng có thể lựa chọn mua phiên bản thương mại mà sau đó đi với sự hỗ trợ.

Các dự án nguồn mở được cấp phép theo các giấy phép dễ dãi như Giấy phép Phần mềm Apache, cho phép tái cấp phép phần mềm đó theo bất kỳ giấy phép nào khác, bao gồm cả một giấy phép thương mại. Điều này cho phép một nhà cung cấp thương mại lấy dự án được cấp phép dễ dãi và phân phối mã theo một giấy phép thương mại. Ví dụ, điều này có thể xảy ra khi một nhà cung cấp phần mềm kết hợp các thành phần nguồn mở vào trong một sản phẩm thương mại lớn hơn. Ví dụ, IBM đã tích hợp dự án của Apache là Xalan, một trình xử lý XSLT, vào trong bản chào thương mại của hãng trong WebSphere.

Cung cấp các dịch vụ

Việc cung cấp các dịch vụ xung quanh một sản phẩm nguồn mở là một cách phổ biến tạo doanh số. Dải các dịch vụ có thể được cung cấp là rộng và khác nhau tùy theo các kỹ năng của nhà cung cấp.

Các dịch vụ tiềm năng mà có thể được chào cho các khách hàng bao gồm:

• Tư vấn (nghĩa là giúp khách hàng hiểu được những lợi ích và rủi ro của sản phẩm nhất định)

• Công việc tích hợp (như, tích hợp giải pháp nguồn mở vào một môi trường đang tồn tại)

• Huấn luyện (như, cung cấp các cuộc hội thảo và/hoặc huấn luyện để giúp một khách hàng đuổi kịp tốc độ trong sản phẩm nguồn mở theo yêu cầu)

Vì bản chất tự nhiên của các sản phẩm nguồn mở, một khách hàng sẽ kỳ vọng nhà cung cấp các dịch vụ sẽ có tham gia với dự án nằm bên dưới và sẽ là trực quan khi có tri thức phù hợp xung quanh phần mềm đó. Một nhà cung cấp có thể nhấn mạnh sự tinh thông của anh ta bằng sự tham gia tích cực trong dự án phần mềm đó và bằng việc đồng thanh thông qua các blog và bài báo trong các xuất bản phẩm phù hợp.

Mô hình thương mại hóa dịch vụ tìm cách giải quyết những quan ngại còn lại mà những người áp dụng nguồn mở có (xem phần 1), đặc biệt:

• Thiếu hỗ trợ và dịch vụ mức thương mại xung quanh sự tích hợp và áp dụng phần mềm

• Thiếu các kỹ năng cần thiết trong doanh nghiệp

• Cần tới sự huấn luyện, tài liệu và giáo dục

Tác động lên cộng đồng

Bất chấp những người khởi xướng sản phẩm nguồn mở thực sự, mỗi người dựa vào một số dạng này hoặc khác trong một 'cộng đồng' những người dẫn dắt sản phẩm tiến lên đó. Cộng đồng đó có thể là một tập hợp đa dạng những người hoặc chỉ giới hạn trong một ít nhân viên từ các công ty khác nhau. Tuy nhiên, bất chấp cách mà cộng đồng được tạo ra, mỗi thành viên đặt thời gian và nỗ lực vào trong việc dẫn lái sản phẩm nguồn mở đó theo vị trí hiện hành của mình.

Mô hình kinh doanh bất kỳ được xây dựng xung quanh PMNM sẽ vì thế, theo một số cách thức, tác động tới cộng đồng. Bất kỳ suy nghĩ nào của nhà cung cấp về việc xây dựng doanh nghiệp xung quanh phần mềm đó cũng cần phải tính tới điều này trước khi vội vã bắn lên các đề xuất kinh doanh của mình khắp trên Internet. Nó có thể nhanh chóng bị bắn trả nếu cộng đồng nghĩ anh ta có ý định kiểm soát hoặc sở hữu dự án và cộng đồng của nó, đặc biệt nếu nhà cung cấp còn chưa tham gia tích cực trong dự án cho tới thời điểm đó. Sức mạnh của một cộng đồng nguồn mở là nó có thể 'biểu quyết với đôi chân của nó', nghĩa là nó có thể chọn quay đi và bắt đầu dự án khác bằng một rẽ nhánh của dự án nguồn mở đó, tiềm tàng gây hại cho bất kỳ mô hình kinh doanh nào được xây dựng xung quanh phần mềm đó. Bất kỳ doanh nghiệp nào tham gia với một dự án nguồn mở vì thế phải là nhạy cảm với các nhu cầu và mong muốn của cộng đồng và làm việc với cộng đồng để đảm bảo rằng, càng xa có thể càng tốt, tất cả những lợi ích và quan ngại được làm thỏa mãn.

Tìm kiếm tư vấn bổ sung

Như chúng ta đã thấy trong bài này, việc chọn một mô hình kinh doanh phần mềm bền vững là phức tạp hơn việc chỉ chọn giấy phép phần mềm. Một mô hình kinh doanh nguồn mở có thể được làm từ các thành phần khác nhau, phụ thuộc vào phần mềm và các nhu cầu của những khách hàng. Vì thế, nhà cung cấp cần phải hiểu những tác động của từng thành phần và cách mà chúng có thể được áp dụng cho phần mềm nguồn mở đó theo yêu cầu.

Đối với nhà cung cấp đang tìm cách phát hành một sản phẩm theo một phiên bản nguồn mở thì có ý nghĩa để có được việc tư vấn và chỉ dẫn bổ sung khi chọn mô hình kinh doanh.

Vào tháng 01/2009, OSS Watch đã tổ chức một hội thảo một ngày với đầu đề các Mô hình Kinh doanh và Bền vững Xung quanh Phần mềm Tự do Nguồn Mở. Báo cáo của hội thảo đưa ra nhiều thông tin hơn về các mô hình kinh doanh thương mại.

Even today, mentioning the words ‘business’ and ‘open source’ in the same sentence can solicit strange remarks f-rom an audience not yet accustomed to the fact that there is indeed a large business economy around open source software. It isn’t that long ago that companies using open source software commonly thought that any kind of support or other services around the ‘free’ software should also be available without c-harge. Whilst free support was not expected it was widely assumed that professional support was never available. At the same time, open source communities sometimes found it difficult to interact openly with commercial entities.

However, things have changed and these days we can see open engagement between open source communities and companies commercialising the software produced by those communities. Companies have also begun to recognise that making money f-rom open source software while not giving anything back to the community or project is likely to ultimately result in the failure of their open source related products. Organizations that have been established around open source projects, such as the Mozilla Foundation, the Linux Foundation, the Eclipse Foundation and The Apache Software Foundation have worked hard to foster engagement between both sides and this has produced some results that would have, until very recently, been considered ‘impossible’. For example, Microsoft, historically the most vehement opposer of the open source development model, has been contributing to, and sponsoring, some of the key open source software development communities since 2008.

Over the last few years many different business models have evolved around open source software and so it has become important for a potential open source vendor to think carefully about which business model may be the most suitable for sustaining the product and target market in question.

This article provides an overview of the various components of open source business models. A complementary document explores sustainability issues associated with building business models around open source projects.

Open source is not a business model

The first, and perhaps most obvious, thing to point out, is that open source itself is not, and never has been, a business model. Vendors should be wary of using the term open source as if it were a way of doing business. Open source, to put it simply, is a way of developing and distributing software.

As more commercial organizations began to understand the advantages of using and engaging with open source, it also became clear that there were barriers open source vendors needed to overcome before they could actually begin to replace established enterprise solutions with their products:

• Unclear dependencies on other software components and difficult installation mechanisms

• Lack of commercial-grade support and services around integration and adaptation of the software

• Unclear roadmap and often a very ‘dynamic’ project

• Lack of necessary skill-set within the enterprise

• Need for training, documentation and education

To overcome these barriers, open source vendors began to establish business models that met the needs of commercial customers. These business models are built around open source software and are defined by the way revenue streams are generated. The choice of what sort of streams can be generated depends largely on the open source software in question and because of this it has to be stated that there is no such thing as ‘The open source business model’ or ‘The best open source business model’. Building a sustainable business model will differ depending on whom you are selling to, what you are selling and what the market expects.

Revenue streams

The different ways of generating revenue can be roughly split into the following areas:

• Packaging and distribution

• Offering an al-ternative paid licence to an open source product

• Providing services and support around an open source product

In addition to revenue generation there may also be opportunities for cost reduction through shared development of core software components. Further examination of this topic is out of scope for this article.

Packaging and distribution

The first open source business model to become popular was that of packaging and distributing open source software in a way that makes it easy to install and start using. The various distributions of Linux, an open source operating system, are examples of this business model.

Even software that falls under the reciprocal1 GNU Public License (GPL) can still be sold for a fee2 . Usually, companies will c-harge a fee for packaging and distributing the software on a medium such as a DVD.

Other ways to package open source software include:

• Bundling the software with an appliance

• Building and distributing a complete ‘stack’ of open source components

Examples of the appliance approach are the popular Linux based network routers. In cases whe-re the underlying software is licensed under a reciprocal licence such as the GPL, the vendor must make the source code of the software available to the customer – at no extra c-harge. Failure to do this can mean that the vendor may eventually find himself in court3.

In the ‘stack’ model, a vendor compiles a complete package of open source software to meet a specific business domain need. This could, for example, be a compilation of the open source components necessary to install and run an enterprise document management system. This model is also used to generate revenue f-rom services, as we will see later.

All of the packaging and distribution models seek to address two of the five concerns facing open source adopters (see section 1), specifically:

• Unclear dependencies on other software components and difficult installation mechanisms

• Unclear roadmap and often a very ‘dynamic’ project

Commercial al-ternatives

If a vendor owns the complete IP (intellectual property) of an open source project, then he is free to choose how the software is offered to customers. Often, a vendor will provide a version of the software under a reciprocal open source licence (often called a ‘community version’) while at the same time providing a commercial version (or ‘enterprise version’) of the same software4. This is commonly referred to as ‘dual licensing’ and has been made popular by companies such as MySQL. Differences between the commercial and community versions could be that:

• Bug fixes are applied more frequently and the software is released more frequently

• Certain modules of the community version are replaced with “better” al-ternatives

• Additional components are contained in the software package that allow for integration into a commercial environment

• The commercial version comes with a bundled support package

An open source vendor provides access to the code of the software, therefore allowing a potential customer to also adapt and extend the software for individual use. If the customer can ‘make do’ with a community version (e.g. by being able to support the product internally) then, a community version may be enough. If not, then the customer can opt to purchase the commercial version that then comes with support.

Open source projects licensed under permissive licences such as the Apache Software License, allow re-licensing of the software under any other licence, including a commercial licence. This allows a commercial vendor to take a permissively licensed project and distribute the code under a commercial licence. This can happen, for example, when a software vendor incorporates open source components into a larger commercial product. For example, IBM integrated the Apache project Xalan, an XSLT processor, into its commercial offering WebSphere.

Providing services

Providing services around an open source product is a popular way of generating revenue. The range of services that can be provided is wide and differs according to the vendor’s skills.

Potential services that can be offered to customers include:

• Consulting (i.e. helping the customer to understand the benefits and risks of the specific product)

• Integration work (i.e. integrating the open source solution into an existing environment)

• Training (i.e. providing workshops and/or on-site training to help a customer get up to speed on the open source product in question)

Because of the nature of open source products, a customer will expect the vendor of services to be engaged with the underlying project and to be visible as having the relevant knowledge around the software. A vendor can emphasize his expertise by active participation in the open source project and by being vocal through blogs and articles in relevant publications.

The service model of commercialisation seeks to address the remaining concerns that adopters of open source have (see section 1), specifically:

• Lack of commercial-grade support and services around integration and adaptation of the software

• Lack of necessary skill-set within the enterprise

• Need for training, documentation, and education

Impact on the community

Regardless of the originators of the actual open source product, each one relies in some form or another on a ‘community’ of people who drive the product forward. That community can be a diverse set of people or limited to a few employees f-rom different companies. However, regardless of how the community is made up, each member has put time and effort into driving the open source product to its current position.

Any business model built around the open source software will therefore, in some way, affect the community. Any vendor thinking about building business around the software needs to take this into account before rushing to splash his business proposition across the Internet. It could quickly backfire if the community thinks he is attempting to control or own the project and its community, especially if the vendor has not been actively engaged in the project up until this point. The strength of an open source community is that it can ‘vote with its feet’, meaning that it can choose to walk away and start another project using a fork of the open source project, potentially damaging any business model built around the software. Any business engaging with an open source project must therefore be sensitive to the community’s needs and desires and work with the community to ensure that, as far as possible, all interests and concerns are satisfied.

Finding additional advice

As we have seen in this article, choosing a sustainable open source business model is more complex than just choosing the software licence. An open source business model can be made up of different components depending on the software and the needs of the consumers. Therefore, the vendor needs to understand the implications of each component and how they can be applied to the open source software in question.

For a vendor looking to release a product in an open source version it makes sense to obtain additional consulting and guidance when choosing the business model.

In January 2009, OSS Watch held a one-day workshop entitled Business and Sustainability Models Around Free and Open Source Software. The workshop report provides more information on commercial business models.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com