Ý Nghĩa Của Việc Định Nghĩa InnerSource

Câu Hỏi #

Mọi người thường xuyên hỏi tôi định nghĩa của InnerSource là gì. Vậy InnerSource là gì? Tôi muốn chia sẻ một số suy nghĩ về InnerSource và ý nghĩa của nó đối với tôi.

Hãy để tôi làm rõ ngay từ đầu: đây là những ý kiến cá nhân của tôi, không phải là quan điểm chính thức. Mặc dù tôi hiện đang giữ chức Chủ tịch của Quỹ InnerSource Commons, InnerSource đã được hình thành bởi nhiều người tiên phong mà tôi vô cùng tôn trọng. Những đóng góp của họ đã xây dựng nên InnerSource như ngày hôm nay.

Nền tảng của InnerSource đến từ sự đan xen của các thực tiễn doanh nghiệp, nghiên cứu học thuật, và tất nhiên, sự phát triển của chính mã nguồn mở. Với bức tranh phong phú này, sẽ là kiêu ngạo nếu tôi tuyên bố định nghĩa InnerSource một cách cá nhân. Chỉ vì tôi hiện đang giữ chức Chủ tịch không có nghĩa là tôi có thẩm quyền hoặc trí tuệ để tạo ra định nghĩa đó một mình.

Thay vì đưa ra một câu trả lời duy nhất và chắc chắn, tôi muốn chia sẻ những góc nhìn khác nhau về câu hỏi này, đưa ra những quan điểm có thể giúp bạn khám phá định nghĩa và hiểu biết riêng của mình về ý nghĩa của InnerSource trong bối cảnh của bạn.


Hai Con Đường Đến Với InnerSource #

Chúng ta đang ở một điểm uốn thú vị. Hãy để tôi nói rõ hơn về ý tôi muốn nói. Về cơ bản có hai loại người đến với InnerSource ngày nay:

Nhóm đầu tiên bao gồm những người đã thực hành mã nguồn mở, nhận thấy các phương pháp hợp tác của nó mạnh mẽ, và tự nhiên áp dụng những nguyên tắc này trong nội bộ. Đối với họ, InnerSource chỉ đơn giản là một cái tên được đặt cho thứ họ đã làm—mang sự xuất sắc của hợp tác mã nguồn mở vào tổ chức của họ.

Nhóm thứ hai khám phá InnerSource như một phương pháp luận được đặt tên. Họ có thể không có nền tảng mã nguồn mở sâu rộng, nhưng họ nhận ra rằng InnerSource như một phương pháp luận tổ chức mang lại giá trị to lớn cho việc chuyển đổi. Họ áp dụng InnerSource không phải vì họ là những nhà thực hành mã nguồn mở, mà vì chính InnerSource hứa hẹn những lợi ích tổ chức.

Sự đối lập này tạo ra những cơ hội hấp dẫn trong cộng đồng của chúng ta. Nhóm đầu tiên hiểu một cách trực quan ý nghĩa của việc triển khai InnerSource trong một tổ chức, cũng như giá trị và văn hóa của InnerSource và mã nguồn mở. Do đó, họ có thể suy ngẫm về cách InnerSource nên được định nghĩa và suy nghĩ về nó trong khuôn khổ của mã nguồn mở. Mặt khác, nhóm thứ hai không nhất thiết phải có sự tham gia với mã nguồn mở, vì vậy họ có xu hướng tìm kiếm những ý tưởng rõ ràng hơn về nó thực sự là gì.

90%


Học Hỏi Từ DevOps: Sức Mạnh Của Việc Đặt Tên #

Để hiểu thách thức định nghĩa của InnerSource, hãy nhìn vào DevOps. Đây là cách tôi hiểu về sự phát triển của nó: các nhà thực hành tại các công ty như Flickr đang làm điều gì đó sáng tạo—phá bỏ các rào cản giữa phát triển và vận hành. Khi họ chia sẻ kinh nghiệm của mình và ai đó đặt tên cho nó—“DevOps”—điều kỳ diệu đã xảy ra. Đột nhiên, các công ty khắp nơi nhận ra họ đang làm những việc tương tự, và tất cả họ bắt đầu chia sẻ câu chuyện của mình.

Hiểu biết quan trọng là: thực tiễn tồn tại trước tên gọi, nhưng việc đặt tên đã tạo ra cộng đồng. Với cộng đồng đó đến các công cụ, khái niệm chung, hội nghị, và sự tăng trưởng bùng nổ. DevOps không được phát minh; nó được khám phá và đặt tên. Việc đặt tên đã thúc đẩy mọi thứ khác.

InnerSource theo một mô hình tương tự đáng chú ý. Tim O’Reilly đã đề cập đến nó trong một bài blog vào năm 2000. Năm 2015, Danese Cooper và các đồng nghiệp, khi đó tại PayPal, đã chính thức hóa InnerSource Commons, sau đó tách ra thành một quỹ. Nhưng họ không phát minh ra thực tiễn—họ đặt tên cho thứ mọi người đã làm.

Việc đặt tên này thật kỳ diệu. Đột nhiên, các nhà thực hành bị cô lập nhận ra họ không đơn độc. “Ồ, việc chúng ta đang làm với các thư viện nội bộ? Đó là InnerSource!” Cộng đồng bùng nổ với việc chia sẻ mẫu, dẫn đến các tài nguyên như InnerSource Patterns nắm bắt trí tuệ tập thể.

DevOps Ngày Nay Là Gì? Một Góc Nhìn Trong Nhiều Góc Nhìn #

Mọi người định nghĩa DevOps theo vô số cách, và tôi không thể bao quát tất cả. Đây là một ví dụ về cách nó có thể được hiểu:

  • Một văn hóa hợp tác giữa các nhóm truyền thống tách biệt
  • Một tập hợp các thực tiễn và công cụ tự động hóa
  • Một triết lý chống lại phát triển waterfall truyền thống
  • Một tập hợp các phương pháp luận và khuôn khổ
  • Mở rộng vào các lĩnh vực chuyên biệt: BizDevOps, DevSecOps, và hơn thế nữa

Đây chỉ là một cách diễn giải. Hỏi mười nhà thực hành, và bạn sẽ có mười sự nhấn mạnh khác nhau. Sự đa dạng này không phải là điểm yếu—đó là sức mạnh tiến hóa.

90%


Nhiều Ý Nghĩa Của “Mã Nguồn Mở Nội Bộ” #

Cụm từ “mã nguồn mở nội bộ” có vẻ nghịch lý, và nghịch lý này tiết lộ tại sao InnerSource có ý nghĩa khác nhau đối với các tổ chức khác nhau. Hãy để tôi chia sẻ một số ví dụ đại diện xuất hiện từ các cuộc thảo luận cộng đồng của chúng ta:

InnerSource Như Một Con Đường Đến Sự Trưởng Thành Mã Nguồn Mở #

Đối với một số người, InnerSource mở ra con đường hữu cơ hướng tới sự tham gia mã nguồn mở và chuyển đổi số. Nó không chỉ về việc chuẩn bị cho đóng góp mã nguồn mở cuối cùng—nó về việc tạo ra một môi trường nơi tổ chức có thể phát triển thành một công ty phần mềm thực sự. Các công ty như Microsoft và Google minh họa hành trình này, nơi các thực tiễn nội bộ tự nhiên phát triển để phản ánh những thực tiễn bên ngoài, tạo ra sự hợp tác liền mạch cả bên trong và bên ngoài công ty.

Nhưng còn các công ty sản xuất, bán lẻ, hoặc tổ chức tài chính thì sao? Mặc dù họ có thể sử dụng lượng lớn mã nguồn mở, hành trình của họ khác biệt. Đối với họ, InnerSource có thể là bước đầu tiên trong một chuyển đổi dài hơn—xây dựng khả năng phần mềm, nuôi dưỡng văn hóa đổi mới, và có thể cuối cùng tìm ra cách riêng độc đáo để tham gia với mã nguồn mở phù hợp với mô hình kinh doanh của họ.

InnerSource Như Tính Minh Bạch Tổ Chức #

Nhiều người bị thu hút bởi InnerSource để chuyển đổi văn hóa. Nó không chỉ về việc gửi pull request—mặc dù đó là một phần của nó. Nó về việc tạo ra tính minh bạch hữu cơ nơi bạn có thể:

  • Gửi yêu cầu tính năng cho các nhóm khác
  • Xem những gì các nhóm lân cận đang xây dựng
  • Hiểu cảnh quan công nghệ tổ chức rộng lớn hơn
  • Phá bỏ các rào cản ngăn chặn hợp tác
  • Tạo ra một văn hóa tổ chức mở và thoáng hơn nơi thông tin chảy tự nhiên

Tính minh bạch này chuyển đổi các tổ chức từ hệ thống phân cấp cứng nhắc thành mạng lưới sống động của sự hợp tác.

Cuối cùng, những điều này góp phần vào hạnh phúc và phúc lợi của các kỹ sư, nhóm sản phẩm, và mọi người tham gia trong tổ chức. Cảm thấy được tin tưởng trong một môi trường làm việc hỗ trợ—cảm thấy được tin tưởng theo mặc định—là vô cùng quan trọng. Điều này liên quan đến trải nghiệm nhà phát triển, và do đó dẫn đến cải thiện việc giữ chân nhân tài đồng thời cũng mang lại kết quả tích cực cho tuyển dụng.

InnerSource Như Tối Ưu Hóa Tài Nguyên #

Quản lý dự án phân cấp truyền thống thêm lề ở mọi cấp độ. Yêu cầu chảy xuống, mỗi lớp thêm thời gian đệm cho sự không chắc chắn. Khi công việc đến triển khai, thời gian biểu bị thổi phồng và các kỹ sư bị ép.

InnerSource đảo ngược điều này. Những người gần nhất với vấn đề hiểu chúng tốt nhất. Họ có thể ưu tiên, thảo luận, và giải quyết vấn đề mà không cần các cuộc họp và phê duyệt liên tục. Điều này không phải lúc nào cũng đúng—các nhóm thực địa chỉ biết lĩnh vực của họ—nhưng khi cân bằng với giám sát chiến lược, nó rất mạnh mẽ.

Nhưng tối ưu hóa tài nguyên vượt ra ngoài tài nguyên con người và nhóm. Nó cũng về việc tận dụng tài sản mã, tài sản trí tuệ, và lợi thế cạnh tranh của tổ chức. Khi các nhóm có thể chia sẻ và xây dựng trên các công cụ, thư viện, và kiến thức của nhau, họ tạo ra sự cộng hưởng không tồn tại trong các cấu trúc bị chia cắt. Thư viện học máy nội bộ mà nhóm bạn xây dựng? Một nhóm khác có thể mở rộng nó theo những cách bạn chưa bao giờ tưởng tượng. Khuôn khổ kiểm thử mang lại cho bạn lợi thế cạnh tranh? Chia sẻ nó nội bộ nhân lên giá trị của nó trên toàn tổ chức. InnerSource giúp các tổ chức nhận ra rằng tài sản mã và kiến thức của họ là những tài nguyên trở nên có giá trị hơn khi được chia sẻ, không phải tích trữ.


Tiến Thoái Lưỡng Nan Định Nghĩa: Ngữ Cảnh Là Tất Cả #

Thách thức của nhiều ý nghĩa này không phải là duy nhất đối với InnerSource. Hãy xem xét cách các nhà ủng hộ Open Source Program Office (OSPO) thúc đẩy mã nguồn mở nội bộ. Họ hoàn toàn sử dụng thông điệp khác nhau cho các đối tượng khác nhau vì mỗi hoạt động cần sự ủng hộ từ các bên liên quan khác nhau, và mỗi lớp của tổ chức có những lợi ích và mối quan tâm khác nhau.

Đối với việc ủng hộ InnerSource, thông điệp có thể trông như thế này:

Với các kỹ sư: “Hợp tác với các đồng nghiệp xuất sắc, học hỏi từ mã tốt nhất, đóng góp cho các dự án thú vị ngoài nhóm trực tiếp của bạn”

Với quản lý cấp trung: “Giảm trùng lặp, tăng hiệu quả, tăng tốc giao hàng thông qua tái sử dụng và hợp tác”

Với các giám đốc điều hành: “Giảm chi phí, tăng tốc độ đổi mới và giữ chân nhân tài hàng đầu”

Cùng một sáng kiến InnerSource phục vụ tất cả các mục tiêu này đồng thời, nhưng bạn nhấn mạnh các khía cạnh khác nhau cho các đối tượng khác nhau. Đây không phải là lừa dối—đó là sự nhận biết rằng InnerSource, như bất kỳ phương pháp luận chuyển đổi nào, mang lại giá trị ở nhiều cấp độ.

Định nghĩa InnerSource của bạn không chỉ phụ thuộc vào đối tượng—nó phụ thuộc vào giai đoạn. Và điều đó hoàn toàn ổn.


Hành Trình InnerSource Của Bạn: Một Định Nghĩa Phát Triển #

Vậy InnerSource là gì? Nó là những gì bạn định nghĩa nó.

Có lẽ trong tương lai, Quỹ InnerSource Commons sẽ phát triển một định nghĩa rõ ràng hơn, có thể truyền đạt hơn khiến việc InnerSource là gì trở nên rõ ràng ngay lập tức. Cá nhân, tôi mong chờ ngày đó, mặc dù tôi nhận ra rằng việc tạo ra một định nghĩa như vậy giữa sự đa dạng như vậy là một nhiệm vụ vô cùng khó khăn.

Hơn nữa, định nghĩa của bạn có thể và nên phát triển. InnerSource giúp bạn bắt đầu hành trình có thể khác với InnerSource bạn thực hành ba năm sau. Định nghĩa của bạn có thể thay đổi khi tổ chức của bạn trưởng thành, khi thách thức của bạn thay đổi, khi hiểu biết của bạn sâu sắc hơn.

Bạn có thể mang định nghĩa của mình đến cộng đồng, chia sẻ quan điểm của bạn, và giúp tất cả chúng ta suy nghĩ về những câu hỏi này cùng nhau. Cuộc khám phá tập thể này là cách chúng ta cuối cùng sẽ đến được hiểu biết chung—không thông qua sắc lệnh từ trên xuống, mà thông qua khám phá hợp tác.

90%


Lời Kêu Gọi Hành Động #

Thay vì tìm kiếm định nghĩa hoàn hảo, tôi khuyến khích bạn trải nghiệm InnerSource:

  • Gửi một vấn đề mô tả một vấn đề bạn thấy
  • Gửi một pull request sửa tài liệu
  • Yêu cầu một tính năng từ nhóm khác
  • Chia sẻ mã của bạn với đồng nghiệp
  • Khám phá những gì các nhóm khác đang xây dựng
  • Hợp tác qua các ranh giới tổ chức

Thông qua thực hành, bạn sẽ khám phá InnerSource có ý nghĩa gì đối với tổ chức của bạn. Bạn thậm chí có thể phát minh ra các mẫu mới mà phần còn lại của chúng ta có thể học hỏi.

Tham Gia Cuộc Trò Chuyện #

Năm 2025, khi AI chuyển đổi cách chúng ta viết và hợp tác trên mã, các nguyên tắc InnerSource trở nên thậm chí còn liên quan hơn. Làm thế nào chúng ta duy trì chất lượng khi AI có thể tạo ra hàng nghìn dòng ngay lập tức? Làm thế nào chúng ta bảo tồn việc chia sẻ kiến thức khi việc tạo mã được tự động hóa? Làm thế nào chúng ta đảm bảo phán đoán của con người vẫn là trung tâm của phát triển phần mềm?

Đối với vấn đề này, vui lòng tham khảo bài viết bao quát phương pháp luận hợp tác trong kỷ nguyên AI.

Chà, những câu hỏi này chưa có câu trả lời, nhưng tôi tin rằng InnerSource—với sự nhấn mạnh vào tính mở, minh bạch, cố vấn được ưu tiên, và đóng góp mã tự nguyện—được định vị độc đáo để khám phá chúng.

InnerSource có nhiều hương vị. Bạn có thể thêm của riêng mình. Bạn có thể đặt tên cho các mẫu tồn tại nhưng chưa được diễn đạt. Đây là lý do tại sao InnerSource thú vị: nó là một lá cờ dưới đó một cộng đồng phát triển, tiến hóa, và lan truyền đổi mới.

Quỹ InnerSource Commons chào đón những cuộc thảo luận này. Các thành viên cộng đồng của chúng tôi đang khám phá những câu hỏi này hàng ngày, chia sẻ kinh nghiệm, và xây dựng tương lai của hợp tác nội bộ.

Vì vậy tôi hỏi bạn: InnerSource của bạn là gì? Bạn sẽ định nghĩa nó như thế nào cho tổ chức của mình? Bạn sẽ khám phá và chia sẻ những mẫu nào?

Hãy khám phá những câu hỏi này cùng nhau. Hành trình mới chỉ bắt đầu. Tôi mong được chào đón bạn vào cuộc trò chuyện tại innersourcecommons.org.

Yuki Hattori

Yuki Hattori

President of the InnerSource Commons Foundation
Sr. Architect at GitHub
Open Source Technical Advisor at IPA (Japanese government administration)
Author of two books on AI and GitHub
O’Reilly books translator for Prompt Enginnering for LLMs and two InnerSource books[1][2]
 
Opinions expressed here are my own and do not represent any organization I am affiliated with.