Làm thế nào để bạn cạnh tranh hiệu quả với một dự án nguồn mở?

Một công ty với một dự án nguồn mở vững chắc cạnh tranh với một sản phẩm nguồn đóng truyền thống dường như không thể đánh bại.

Tôi đọc bài viết này trong đó tác giả đưa ra kịch bản này:

Giả sử người ta có thể phân chia một thị trường phần mềm, nói rằng quản lý mạng giữa hai sản phẩm. Một người đã làm mọi thứ có thể và tiêu tốn 1 triệu đô la, và người kia chỉ làm 10% như vậy, nhưng miễn phí và mở.

Thẻ giá của giải pháp thương mại sẽ tự động lọc ra một số lượng lớn người dùng và những người đó sẽ phải chuyển sang nguồn mở. Nhưng một số người dùng sẽ hài lòng với chức năng 10% và chọn nó hoàn toàn.

Ví dụ, tôi có một máy tính Macintosh gốc trên bàn của mình. Nó chạy một trình xử lý văn bản gọi là MacWrite. Nó làm mọi thứ, ngoại trừ kiểm tra chính tả, tôi cần một trình xử lý văn bản để làm. Tôi có thể định dạng đoạn văn, chọn phông chữ, làm đậm văn bản hoặc in nghiêng và thậm chí dán vào hình ảnh và biểu đồ. Tất cả trong một giao diện người dùng "những gì bạn thấy là những gì bạn nhận được".

Nó chiếm tới 76K dung lượng đĩa. Đó là "K" như trong "kilobyte."

So sánh điều đó với Microsoft Word. Tôi nghĩ rằng lần cuối cùng tôi cài đặt Word là khoảng 30 MB, lớn hơn nhiều lần so với MacWrite, nhưng tôi không sử dụng nó nhiều hơn tôi sử dụng MacWrite. Giống như tôi, nhiều người dùng hài lòng với chức năng cơ bản. Họ không cần tất cả chuông và còi.

Nhưng trở lại với sự tương tự của tôi. Ban đầu, công ty thương mại có thể sẽ bỏ qua dự án nguồn mở. Nó không đại diện cho mối đe dọa đối với dòng doanh thu của họ, vậy tại sao họ phải chú ý đến một sự khởi đầu?

Tuy nhiên, nếu dự án này là lành mạnh và bền vững, trong một năm hoặc lâu hơn có lẽ nó làm 15% -20% những gì sản phẩm thương mại làm. Điều này sẽ làm chảy máu thêm một vài người dùng từ doanh nghiệp của họ và có lẽ bây giờ họ bắt đầu chú ý.

Nhiều khả năng, sự chú ý này sẽ có hình thức tiếp thị chống lại dự án. Họ sẽ tuyên bố rằng nó quá nhỏ hoặc quá thiếu năng lực để thực hiện nghiêm túc. Và trong ngắn hạn, điều này có thể sẽ làm việc. Nhưng thực tế là họ thừa nhận dự án sẽ gây hứng thú. Một số người sẽ tự xác định rằng nó không quá nhỏ cũng không quá yếu và sẽ bắt đầu sử dụng nó.

Một hoặc hai năm nữa trôi qua và bây giờ dự án lên tới 50% chức năng của sản phẩm thương mại. Mọi người bắt đầu tham gia dự án theo lũ. Các công ty thương mại bây giờ phải làm một cái gì đó. Họ làm gì? Họ thêm nhiều tính năng.

Hãy nhớ rằng, sản phẩm thương mại đã làm 100% những gì mọi người cần. Vì vậy, những loại tính năng họ có thể thêm? Những thứ không cần thiết. Họ có thể thay đổi giao diện của giao diện người dùng hoặc thêm các tính năng bên ngoài quản lý mạng. Trong mọi trường hợp, sự phát triển này sẽ tốn tiền và điều đó sẽ bắt đầu ăn vào lợi nhuận của công ty.

Cuối cùng, với một cộng đồng lành mạnh và lượng người dùng mới này, dự án nguồn mở cuối cùng sẽ tiếp cận 80% -90% những gì sản phẩm thương mại làm. Đã hết tất cả các con đường tạo doanh thu, công ty thương mại vẫn có một lựa chọn cuối cùng: đặt ốc vít cho các khách hàng còn lại của họ. Tìm cách tính phí cho họ nhiều hơn, để tìm ra những gì họ có thể từ khoản đầu tư của họ, điều cuối cùng sẽ khiến khách hàng của họ bỏ đi.

Farfetched? Tôi không nghĩ vậy. Chỉ có hai yêu cầu chính:

Đầu tiên, tìm một thị trường nơi nguồn mở cung cấp một sự thay thế hấp dẫn, chẳng hạn như quản lý mạng.

Thứ hai, xây dựng một cộng đồng bền vững xung quanh dự án nguồn mở.

Có vẻ rất hợp lý. Nếu bạn là công ty nguồn đóng, bạn sẽ cạnh tranh như thế nào ??

Vì bạn không thể cạnh tranh về giá, sau đó cạnh tranh trên tất cả các điểm bán khác mà phần mềm có:

• Tính năng, đặc điểm
• phẩm chất
• hiệu quả
• tích hợp với các phần mềm khác
• dịch vụ
• ủng hộ
• bán hàng trực tiếp

Về cơ bản, bạn làm những gì mọi công ty khác làm khi họ cạnh tranh về giá: theo kịp hoặc thay đổi trò chơi.

Bằng cách làm cho sản phẩm của bạn tốt hơn so với việc cung cấp nguồn mở. Đó là cách Photoshop có thể cạnh tranh với GIMP.

Tôi nghĩ rằng phần bạn đề cập là rất sai lệch, trong đó nó hoàn toàn coi thường chất lượng của đề nghị nguồn mở. Tự hỏi bản thân một câu hỏi hơi khác nhưng có liên quan:

Làm thế nào một công ty có thể tồn tại tồn tại khi bán phần mềm nguồn mở?

Là người thường xuyên đóng góp cho một vài dự án nguồn mở, tôi cảm thấy có quyền hợp lý để trượt một vài vòng bùn nơi nó xứng đáng.

Không có điều gì sau đây áp dụng cho các dự án OSS sao như Linux, Firefox, MySQL hoặc PostgreSQL, làm phiền bạn. Đây là những điều không điển hình, trong đó chúng được hỗ trợ bởi các công ty và / hoặc các lập trình viên dày dạn.

Dù sao, như lý do khách hàng sẽ trả tiền cho phần mềm:

OSS có xu hướng có tính năng creep / Khách hàng sẽ trả tiền cho phần mềm đơn giản hơn

Những người đóng góp OSS đều có tính năng thú cưng của họ. Chúng cuối cùng sẽ tìm đường vào cơ sở mã. Phải mất một lãnh đạo cực kỳ dày dạn, vững chắc và lôi cuốn để tránh vấn đề, và giống như bất kỳ chàng trai nào khác, một nhà phát triển cốt lõi OSS thiếu ít nhất một trong những đặc điểm này.

Thêm sự xúc phạm đến thương tích, đối với mọi tính năng không thiết yếu xuất hiện, người khác sẽ không muốn điều đó và điều này sẽ dẫn đến việc thêm các tùy chọn. Các lập trình viên có xu hướng thích các lựa chọn, nhưng từ quan điểm UI, họ là một con đường chắc chắn dẫn đến cái chết chậm chạp và đau đớn bởi hàng ngàn vết cắt.

Người dùng cuối muốn các công cụ đơn giản. Họ cần phải hoàn thành công việc của mình mà không cần học hỏi hay làm phiền. Họ muốn các công cụ của họ đưa ra quyết định đúng đắn cho họ; không phải lựa chọn. Nếu bạn có thể cung cấp một cái gì đó đơn giản hơn so với triển khai OSS độc lập, bạn sẽ nhận được khách hàng trả tiền.

OSS có xu hướng chất lượng thấp / Khách hàng sẽ trả tiền cho chất lượng cao hơn

Không có gì sai khi học viết mã bằng cách đóng góp cho OSS, làm phiền bạn.

Tuy nhiên, phải nói rằng, đối với mọi OSS hoặc thư viện chất lượng cao được hỗ trợ bởi tất cả các lý do của các công ty và các lập trình viên dày dạn, có một loạt mã spaghetti dễ bị lỗi được viết bởi các lập trình viên thiếu kinh nghiệm đang đóng góp OSS trong nỗ lực để học lập trình, và những người có ít ý tưởng về những gì họ đang làm.

WordPress, ví dụ, được rẽ nhánh từ B2 (do sinh viên thiết kế) bởi một sinh viên. Nhiều phiên bản và số lượng băng keo chưa được bán sau đó, nó hoàn thành công việc. Nhưng dưới mui xe, nó là một lỗi của rất ít nếu có kiểm soát chất lượng. (Lần cuối tôi thử, nó đã không thành công vượt qua bộ thử nghiệm của chính nó.)

Khách hàng sẽ trả tiền cho phần mềm được bảo trì tốt và được kiểm tra tốt. Hầu như tất cả họ sẽ thử những thứ miễn phí, làm phiền bạn, và nhiều người thậm chí sẽ chịu đựng các lỗi đến một điểm. Nhưng nếu doanh thu của họ phụ thuộc vào nó, cuối cùng họ sẽ tìm kiếm phần mềm chất lượng cao hơn và trả tiền cho nó.

OSS có xu hướng có chu kỳ phát triển quá ngắn / Khách hàng sẽ trả tiền để tránh những rắc rối

Điều này là cố hữu cho quá trình phát triển. Các tính năng thú cưng được đưa vào cơ sở mã cần được phát hành theo thang thời gian hợp lý. Nếu họ không, rủi ro là dự án OSS sẽ mất một số người đóng góp.

Tuy nhiên, về lâu dài, các công ty thích chu kỳ phát hành dài; càng lâu, càng tốt. Đó là ít kế hoạch và làm việc ít hơn cho bộ phận CNTT. Sẽ không có vấn đề gì lớn nếu người dùng cuối nâng cấp trình duyệt của họ cứ sau ba tháng hoặc lâu hơn. Đó là một câu chuyện hoàn toàn khác nếu bạn đang nâng cấp các ứng dụng quan trọng.

Có một cuộc thảo luận gần đây về việc tăng tốc chu kỳ phát hành trong danh sách tin tặc PostgreSQL. Đối số cuối cùng không phải là về QA và cần có thời gian thử nghiệm beta mở rộng. Đó là một số công ty đã bỏ qua mọi bản phát hành khác, bởi vì chu kỳ phát hành hiện tại (1 năm) đã quá nhanh đối với họ.

Tương phản với WordPress, hiện đang tranh luận về chu kỳ phát hành 3 tháng mỗi lần và mặc dù chu kỳ đã quá ngắn. (Betas của họ, cho tất cả ý định và mục đích, phiên bản xy0 của mỗi bản phát hành.)

Có một vài khách hàng sử dụng WordPress, tôi có thể đảm bảo với bạn rằng họ rất vui khi tôi chăm sóc họ để đảm bảo rằng các trang web của họ không bị nổ tung khi họ nâng cấp. Khách hàng sẽ trả tiền cho việc không cần phải lo lắng loại rắc rối này.

OSS có xu hướng vô thức nắm lấy các tiêu chuẩn mở / Khách hàng chỉ cần những thứ để làm việc

Thẻ video HTML5 là một trường hợp điển hình ở đây.

Trường hợp của Mozilla để từ chối h.264 là họ muốn có một codec nguồn mở. Và họ hoàn toàn chính xác theo nghĩa này: điều cuối cùng họ muốn, là nằm trong danh sách các troll bằng sáng chế; Vì vậy, họ đẩy cho Ogg.

Ngược lại, trường hợp của Apple để sử dụng h.264 là rất thiết thực: nó đã được hỗ trợ rộng rãi và có khả năng tăng tốc phần cứng cho nó (do đó cho phép kéo dài thời lượng pin của iPhone); Không có điều đó cho Ogg.

Hàng triệu thiết bị iOS được bán sau đó, các trang web lo lắng về việc cung cấp video cho những người dùng iOS này hỗ trợ html5 / h.264. Nói cách khác, khách hàng đã nói: họ không quan tâm đến các định dạng mở.

Công ty duy nhất hài lòng với kết quả của cuộc chiến độc hại về codec này là Adobe: Người dùng Firefox, trên thực tế, sẽ tiếp tục cần Flash nếu họ muốn phát video. Nếu một trang web chính chuyển sang video chỉ có html5 / h.264, một lập trình viên ngoài đó sẽ nhanh chóng đưa ra một tiện ích mở rộng hoặc plugin để chuyển đổi các thẻ video cần thiết thành trình phát video flash. (Nó thậm chí có thể tồn tại.) Nhân danh các tiêu chuẩn mở hỗ trợ (mà flash, tình cờ, thì không).

Không ai từng bị sa thải vì chọn IBM

Đó là một trò đùa của ngành công nghiệp cũ, nhưng có một sự thật trong đó: khi sử dụng ngân sách CNTT, bạn sẽ không bị sa thải vì chọn những gì đồng nghiệp coi là tốt nhất của giống.

Những người mua lớn của công ty, những người không cảm thấy muốn mạo hiểm sẽ tiếp tục mua máy tính để bàn, Office, SAP, và những gì không; ngay cả khi có các lựa chọn thay thế nguồn mở. Giống như shit xảy ra .

Khi OSS xâm nhập vào môi trường doanh nghiệp lớn, thường thì không phải vì CTO đã nhìn thấy ánh sáng và quyết định sử dụng các công cụ miễn phí; thay vào đó, nó đang được một bên thứ ba cung cấp dịch vụ (giá cả) trên đầu trang.

Tôi nghĩ mấu chốt của tranh luận, rằng "sản phẩm thương mại đã làm 100% những gì mọi người cần" là nơi tranh luận sụp đổ. Không có sản phẩm nào có thể yêu cầu thực hiện 100% những gì mọi người cần và chắc chắn không phải là hiệu quả tuyệt đối nhất (về hiệu quả của nhà điều hành), cách dễ sử dụng và được chấp nhận phổ biến nhất.

Nếu điều đó là có thể, thì dĩ nhiên thứ duy nhất còn lại để cạnh tranh là giá cả. Nhưng vì một mục tiêu "tốt nhất" và một ứng dụng "hiệu quả nhất" là không thể, nên sẽ luôn có nhiều thứ hơn là giá cả để cạnh tranh.

Có một số điểm tốt trong bài viết đó, nhưng một lần nữa, thế giới thực dường như có rất nhiều ví dụ mà các công ty nguồn gần đang làm tốt. Đây chỉ là một vài

1. Linux so với Windows
2. PHP so với ASP.NET
3. [cái gì đó khác] so với Visual Studio
4. GIMP so với Photoshop (nó đã được trả lời trước tôi, nhưng tôi thực sự cần ví dụ không phải MS :))
5. Diễn đàn so với 30+ gói bảng thông báo khác

Vấn đề với nguồn mở là nó mở. Nếu bạn có mã đó tạo ra sản phẩm A. Tất cả các đối thủ cạnh tranh của bạn có cùng một mã. Vì vậy, bạn dành toàn bộ thời gian để viết phần mềm, được cấp bởi một số phần mềm có thể được thực hiện bởi những người đóng góp khác, nhưng nếu bạn điều hành một công ty, bạn đang sử dụng tài nguyên và bất cứ ai cũng có thể đi cùng và bắt đầu bán chính xác như bạn đã dành nhiều năm đang phát triển. Vì vậy, mối đe dọa lớn nhất đối với một công ty nguồn mở có thể không cần thiết là một công ty nguồn mở, nhưng 5 công ty nguồn mở khác.

Mặt khác, nếu tôi phát triển phần mềm nguồn đóng, vâng, bạn có thể sao chép ý tưởng của mình nhưng tôi vẫn có thể đi trước bạn nhiều năm trong việc phát triển phần mềm và đến khi bạn tham gia thị trường, tôi đã có thể sở hữu 90%.

Cuối cùng, nói chung, các công ty không chia sẻ mã nhưng tính phí cho phần mềm của họ, tạo ra nhiều doanh thu hơn các dự án nguồn mở. Ngay khi doanh thu đó được tạo ra, một phần của nó được tái đầu tư không phải bằng kỹ thuật (mà bạn có thể tranh luận có thể là miễn phí nếu bạn có nhiều người đóng góp nguồn mở) nhưng tiếp thị và quảng bá sản phẩm và bây giờ bạn đang nói về hàng triệu đô la mà không có thứ gọi là lao động tự do.

Vào cuối ngày, đây là công thức cho sự thành công của bạn: [đổi mới kỹ thuật] x [marketing] = lợi nhuận. Bạn có thể có sản phẩm tốt nhất, nhưng nếu không ai biết về nó, không ai sử dụng nó. Và rõ ràng nếu bạn xây dựng một cái gì đó nhảm nhí, không có số lượng quảng cáo sẽ tiết kiệm nó. Tôi tin rằng nhiều dự án nguồn mở luôn gặp rắc rối với [tiếp thị] khi thâm nhập vào thị trường tiêu dùng nói chung.

Một lĩnh vực mà hầu hết các phần mềm nguồn mở không thể cạnh tranh với phần mềm độc quyền là trong quá trình học tập.

Trong lịch sử, tôi đã có một thời gian khó khăn để kết hợp tất cả trừ một vài phần mềm nguồn mở phổ biến nhất vào bộ công cụ của tôi. Chúng thường tuyệt vời khi tôi tìm ra chúng, nhưng tôi thường không gặp phải sự thất vọng ban đầu này với phần mềm độc quyền.

Tôi không chắc tại sao lại như vậy. Tuy nhiên, tôi có thể nói rằng tôi sẵn sàng trả tiền cho phần mềm hoàn thành công việc với nỗ lực tối thiểu từ phía tôi. Đó là mục đích của phần mềm .

Làm cho nó dễ thực hiện hơn so với cạnh tranh nguồn mở và mọi người sẽ trả tiền.

Tính khả dụng và tính năng - một điều mà một dự án thương mại nguồn đóng có hầu hết các dự án nguồn mở không có là khả năng kiểm soát tầm nhìn mạnh mẽ về những gì sản phẩm được cho là và làm.

Tất cả điều này phụ thuộc vào kích thước / độ phức tạp, nhưng một sản phẩm phần mềm một nhóm nhỏ hơn sẽ có thể tập trung vào thị trường mà họ đang cố gắng thu hút. (Ví dụ khác - làm thế nào BBEdit và TextMate có thể thu hút một nhóm người sẵn sàng trả tiền cho một trình soạn thảo văn bản với sự sẵn có của jEdit, gEdit, v.v. TextMate cung cấp đủ hấp dẫn để khiến mọi người vượt qua $ 20 - $ 30?)

Bằng cách tập trung vào các vấn đề khách hàng cụ thể. Nhiều lần tôi đã thấy các tổ chức chi hàng ngàn đô la cho 'tính năng đó'.

Là một sản phẩm nguồn mở, họ phải tập trung vào số đông (không may là số đông không mua phần mềm 10K + đó), như một nguồn đóng cho tổ chức lợi nhuận, nếu bạn có thể đáp ứng nhu cầu của khách hàng quan trọng / quan trọng của mình, nhiều doanh nghiệp sẽ theo dõi.

Như @SnOrfus đã được đề cập, dịch vụ và hỗ trợ là rất quan trọng. Tôi đã thấy hàng trăm lần, các tổ chức thích nguồn đóng hơn nguồn mở (và thậm chí trả thêm tiền) để có được sự thoải mái khi có thể nắm giữ một số just_in_case!

(điều này có thể là một chút để tập trung vào khách hàng của công ty)

Giải pháp thương mại có thể khẳng định một cách đúng đắn rằng vận may của nó phù hợp với thành công của khách hàng. Đây là những gì định vị sản phẩm là về. Với một số ngoại lệ, các công cụ nguồn mở nói chung thường được xem là thiên đường của hacker, không chính xác là một giải pháp điểm tập trung của khách hàng.

Nếu khách hàng của bạn cần một số tính năng, bạn có cơ sở tài chính để cung cấp đúng hạn. Bạn có khả năng cung cấp hỗ trợ 24x7 (và tính phí cho nó), đảm bảo khắc phục các sự cố nghiêm trọng cấp 0, truy cập vào công nghệ thế hệ mới sớm hơn nhiều so với cộng đồng nguồn mở nếu bạn làm việc với các OEM.

Sử dụng chúng để lợi thế của bạn. Hãy để sản phẩm miễn phí cũng có mặt trên thị trường, đừng thù địch. Nếu bất cứ điều gì, điều này mở rộng thị trường - đến một lúc nào đó, người dùng sản phẩm miễn phí có thể muốn thử chuông và còi của giải pháp thương mại của bạn.

Để đơn giản, hãy tập trung các yếu tố thành công của phần mềm vào ba "khoản đầu tư":

(Ở đây, "đầu tư" là một thuật ngữ tập thể cho các hoạt động mà bạn phải trả ngay bây giờ, để nhận doanh thu sau này.)

• bán hàng và marketing
• phát triển (bao gồm mã nguồn, thiết kế sản phẩm / giao diện người dùng, tài liệu và tài liệu đào tạo. Số lượng nhân với Chất lượng. Bất kỳ sản phẩm làm việc nào được sản xuất ở đây đều có thể được nhân rộng với chi phí thấp đến số lượng người dùng không giới hạn)
• dịch vụ (chuyên môn về phần mềm và miền và khả năng cung cấp các cải tiến giá trị gia tăng trên cơ sở mỗi khách hàng)

KPI để phát triển rất đơn giản: bạn có thể phát triển cùng một thứ tốt hơn và rẻ hơn những thứ khác. Một phần của việc này là đầu tư tài nguyên tuyệt đối và phần khác là sự khôn ngoan của kiến ​​trúc sư và nhà thiết kế.

Đối với các dịch vụ, có quyền truy cập vào mã nguồn của sản phẩm là một phần thưởng lớn. Một công ty không có quyền truy cập vào mã nguồn thường không thể cung cấp cùng một mức dịch vụ như một công ty khác có quyền truy cập.

Bây giờ trở lại câu hỏi của OP: một công ty nguồn đóng có chiến lược tồn tại không?

Bài báo được trích dẫn bởi OP dường như là tự giới hạn bởi vì nó chỉ xem xét hai thái cực:

• Một công ty nguồn đóng phát triển tất cả mã nguồn ra khỏi túi của mình và không có dòng mã nguồn mở nào.
• Một công ty nguồn mở hoàn toàn tuân thủ nguyên tắc và mở ra mọi dòng mã từng được phát triển.

Làm thế nào về căn cứ giữa?

• Một số công ty phần mềm ký thỏa thuận cấp phép chéo để chia sẻ một phần mã nguồn và / hoặc API? (Trong đó một trong các bên được định hướng dịch vụ.)
• Các công ty sử dụng tốt các thành phần hoặc thư viện nguồn mở được cấp phép theo kiểu BSD (và đóng góp bằng hiện vật) mà không cần mở mã nguồn của sản phẩm chính?
• Các công ty cung cấp mã nguồn của phần mềm đang thực hiện thông qua sự sắp xếp "xem trước cộng đồng" có giới hạn thời gian?
• "Nguồn sẵn có": các công ty cung cấp mã nguồn cho khách hàng trả tiền?

Quan điểm của tôi là các công ty có thể tồn tại nếu họ áp dụng chiến lược mã nguồn mở một phần, đóng một phần và nếu họ làm tốt trên cả ba mặt trận (tiếp thị, phát triển và dịch vụ). Các công ty áp dụng triết lý chân thực cũng có thể tồn tại và họ cũng sẽ phải làm tốt trên ba mặt trận tương tự.

Mặc dù có một cảnh báo: nếu một phần mềm là miễn phí, khách hàng sẽ chọn phần mềm đó thay vì ngay cả khi phần mềm hoạt động kém trên một số số liệu?

• bán hàng và tiếp thị: bạn có thể quảng bá một sản phẩm mà hầu như không mất phí, thông qua tiếp thị lan truyền không?
• phát triển: một dự án nguồn mở có thể nhận được hầu hết các tài liệu thiết kế / phát triển / tài liệu từ các tình nguyện viên không được trả lương không? Một công ty có thể gặt hái lợi ích từ dự án như vậy?
• dịch vụ: một dự án phần mềm có thể cách mạng hóa miền phần mềm của nó để làm cho nó rất đơn giản, để mọi người có thể trở thành một chuyên gia tức thời, hạ thấp rào cản gia nhập về không?

Dự án nguồn mở đang theo đuổi dự án thương mại về các tính năng. Điều này để lại một loại chênh lệch thời gian cho công ty thương mại để cạnh tranh về các tính năng. Họ phải chạy đua để thực hiện các tính năng liên tục để giữ lợi thế so với công ty nguồn mở. Nó đắt tiền, nhưng nó có thể làm việc.

Như những người khác đã đề cập, các tính năng có thể bao gồm tài liệu và dễ sử dụng.

Tập đoàn có thể cố gắng thấm nhuần nhà cung cấp khóa, nhưng điều đó chỉ làm chậm sự mất mát; nó không mang lại cho bạn bất kỳ khách hàng nào.

Điều này để lại hai cách chính để giữ thị phần: hỗ trợ và khai thác sự mất lòng tin của người quản lý đối với phần mềm nguồn mở. Đáng buồn thay, sau này sẽ giúp bạn đi khá xa. Mặc dù vậy, hỗ trợ bán hàng sẽ hoạt động và ngay cả khi dự án nguồn mở bắt kịp đủ để có một công ty bán hỗ trợ cho nó, giải pháp thương mại sẽ có lợi thế bằng cách là người đương nhiệm và có nhiều kinh nghiệm hơn, và từ ấn tượng rằng họ là quen thuộc hơn với sản phẩm của họ.

Về lâu dài, bạn có khả năng bị lừa, nhưng điều này có thể biến "ngắn hạn" thành "tương lai gần".

Một điều không ai khác đã đề cập là tài liệu. Rất nhiều chương trình không thực sự cần nhiều để có thể sử dụng được (Firefox, Openoffice), nhưng nếu bạn viết thư viện, một loại máy chủ, ngôn ngữ lập trình hoặc chỉ là một chương trình thực sự phức tạp, tài liệu có thể khiến bạn nổi bật.

Cải thiện tài liệu có thể làm giảm sự thất vọng của người dùng của bạn (khiến họ có nhiều khả năng tiếp tục sử dụng sản phẩm của bạn và đề xuất sử dụng nó trong tương lai) và bạn có thể quảng cáo rằng tiền được chi tiêu tốt vì khách hàng của bạn sẽ không mất nhiều thời gian để mã hóa (và thời gian == tiền).

Điều này không nhất thiết là nguồn mở so với nguồn đóng - Mặc dù vậy, mọi thứ đều được ghi chép kém. Có thể là đối thủ cạnh tranh của bạn nằm trong 1% dự án có tài liệu tốt, nhưng điều đó không thể xảy ra;)

Rất đơn giản, mẹo là tiếp tục xác định lại 100%. FOSS không có cùng quy mô và nhân lực của một dự án thương mại và có giới hạn về mức độ bạn có thể cạnh tranh với một sản phẩm hiện có. Công ty nguồn đóng sử dụng các móc nối UI, do đó việc sử dụng một sản phẩm cạnh tranh cảm thấy không thể do khác nhau, ví dụ như các phím tắt. Ngoài ra, họ tiếp tục bổ sung các tính năng chính mà đối thủ cạnh tranh FOSS đơn giản không bao giờ có thể xem xét. Ví dụ, hãy xem xét Visual Studio. Nó chỉ là một IDE C ++, nhưng sau đó họ bắt đầu gói các ngôn ngữ và khung hoàn toàn mới, như .NET. Hoặc Visual Studio 2010, gói một thư viện phân luồng cấp thương mại (như trong, Intel bán một thư viện luồng độc lập tương đương) cho C ++. FOSS không thể theo kịp sự phát triển đó và thường là độ tin cậy.

Nhắm mục tiêu thị trường doanh nghiệp truyền thống và được phổ biến.

Đối với nhiều công ty truyền thống lớn, có ba điều sau:

• một nhà cung cấp mà họ có thể ký kết hợp đồng ràng buộc với (khả năng và độ tin cậy)
• một nhà cung cấp họ có thể thực thi hợp đồng một thỏa thuận cấp độ dịch vụ cụ thể với (chất lượng hỗ trợ tốc độ)
• đánh giá của gartner (đây là phương trình hiện đại của "không ai bị sa thải vì chọn IBM)

Cả ba đều vô tâm làm theo, và không đặc biệt hợp lệ. Các vấn đề về khả năng luôn được đặt ra quá mức, SLA luôn có một lý do và gartner chỉ khảo sát loại người nghe gartner, nhưng khi bạn là quản lý cấp trung trong một công ty có rất nhiều quản lý cấp trên gặp rắc rối với quản lý cấp trên khi quản lý cấp cao cuối cùng nghe rằng đã có một quyết định đau đầu đã tiêu tốn một khoản tiền lớn, bạn cần một số tài liệu từ bên thứ ba hỗ trợ vị trí của bạn nếu bạn muốn cứu công việc của mình. Ngay cả khi bạn biết rõ rằng từ quan điểm kỹ thuật, bạn đang đổ một đống tiền lớn xuống nhà vệ sinh, thì cũng không đáng để mạo hiểm làm điều đúng đắn.

Có bao nhiêu cách sử dụng xấu của SAP hoặc SharePoint mà bạn đã thấy đưa ra trong ngành? Bao nhiêu trong số đó sẽ tốt hơn nếu chúng được thực hiện trên một thứ khác phù hợp hơn, nhưng không phải là một tên công nghiệp lớn?

Tôi sử dụng nhiều công cụ của Microsoft và tôi có tài khoản MSDN, nhưng tôi thực sự nhận được sự giúp đỡ tốt hơn từ những người MS trên twitter so với tôi thông qua trung tâm điện thoại MSDN. Tôi không thể tưởng tượng được rằng tôi sẽ nhận được sự giúp đỡ tồi tệ hơn từ những người đứng sau và dự án nguồn mở so với những người không ủng hộ tweet trong thời gian rảnh rỗi, nhưng điều đó không đi vào phương trình Trách nhiệm / Gartner.

Như SnOrfus đã nói bán các tính năng chúng tôi làm điều đó.

Ví dụ: Chúng tôi phát triển các plugin với một số tính năng phổ biến và giúp tải xuống miễn phí trên trang Wordpress. Đồng thời, chúng tôi có plugin phiên bản trả phí có các tính năng chuyên nghiệp.

Điều này giúp bạn giới thiệu sản phẩm của mình tới những người đại chúng, tức là sức mạnh của nguồn mở và con người.