InnerSource là một lời dối trá - Phản hồi về những hiểu lầm phổ biến
Khi bạn tìm kiếm “InnerSource” trên YouTube, một trong những kết quả đầu tiên mà bạn có thể gặp phải là một video tuyên bố rằng “InnerSource là một lời dối trá.”
(link: https://youtube.com/shorts/53jEP3mPP3E)
Quan điểm này đại diện cho một cạm bẫy điển hình mà nhiều người rơi vào khi họ lần đầu tìm hiểu về InnerSource.
Tôi muốn sử dụng video này như một nghiên cứu tình huống để giải thích loại kết luận sai lệch nào mà nó thúc đẩy. Đây là một sai lầm mà tôi cũng đã mắc phải trong quá khứ, và đó là một cạm bẫy mà nhiều người chưa khám phá sâu lĩnh vực này có thể dễ dàng rơi vào. Đó là lý do tại sao tôi muốn xem xét điều này với sự tự phản tỉnh và giúp những người khác tìm ra con đường đúng bằng cách làm sáng tỏ những cạm bẫy này.
Hiểu lầm đầu tiên: “Sử dụng React để người khác có thể đóng góp” #
Hãy để tôi phân tích lập luận trong trường hợp này trước. Video gợi ý sử dụng React cho các ứng dụng nội bộ “Sử dụng React vì những người khác có thể đóng góp cho nó.” Loại lý luận này hiếm khi được nghe thấy trong các cuộc thảo luận InnerSource thực tế.
should you use react HTMX or solid or something for your company’s internal application now a lot of people what you’re going to hear is use react so other people can contribute to this
Lập luận này có thể được phân tích thành ba vấn đề chính:
- Hiểu lầm cơ bản về InnerSource thực sự có nghĩa là gì
- Chọn sai lĩnh vực để áp dụng InnerSource
- Nhầm lẫn giữa quan điểm cá nhân và nhóm
InnerSource thực sự có nghĩa là gì #
InnerSource là về việc thực hành các nguyên tắc mã nguồn mở trong một công ty. Nó không chỉ đơn giản là về “đóng góp” hoặc “nhận đóng góp.”
Hầu hết những người tương tác với mã nguồn mở chỉ đơn giản là “người dùng.” Một số chỉ là người tiêu dùng, những người khác báo cáo lỗi, và chỉ một phần nhỏ thực sự gửi pull request. InnerSource áp dụng những học hỏi từ mã nguồn mở nội bộ để tạo ra các tổ chức mở, có thể tiếp cận rộng rãi, với việc ra quyết định minh bạch, và các mối quan hệ nhóm được xây dựng trên niềm tin thông qua quyền sở hữu và cố vấn. Điều này tạo ra một văn hóa minh bạch và hợp tác.
Đây là ý nghĩa của “thực hành mã nguồn mở nội bộ” - nó không chỉ về “nhận pull request.” Pull request chỉ là một kết quả của văn hóa này, không phải mục tiêu chính.
Một lĩnh vực ít tối ưu cho việc áp dụng InnerSource #
Vấn đề thứ hai là lập luận này diễn ra trong một lĩnh vực mà InnerSource và mã nguồn mở gặp phải những thách thức đặc biệt.
Nếu bạn muốn “nhận pull request” hoặc “có nhiều người sử dụng mã của bạn để cải thiện chất lượng,” điều đó có thể bị giới hạn bởi bản chất của sản phẩm của bạn. Rõ ràng là việc chia sẻ “các thành phần có độ phụ thuộc cao” hoặc các công cụ cấp nền tảng sẽ tạo ra nhiều giá trị hơn so với các ứng dụng người dùng cuối. Trong khi các nhóm stream-aligned vẫn nên áp dụng các thực hành mã nguồn mở khi có lợi, động lực hợp tác khác nhau đáng kể.
Theo kinh nghiệm của tôi khi làm việc với các công ty doanh nghiệp, việc sử dụng InnerSource cho các sáng kiến cấp dự án nơi người dùng cuối là “những người không phải kỹ sư” đặt ra những thách thức độc đáo. Tại sao? Bởi vì cuối cùng, những sản phẩm này cần phục vụ nhu cầu của “người dùng cuối” hoặc “người dùng doanh nghiệp” có thể thiếu kỹ năng phát triển và kênh giao tiếp trực tiếp với các nhóm phát triển. Điều này tạo ra các yêu cầu phức tạp, cá nhân hóa và thời gian dẫn đầu giao tiếp dài hơn.
Các triển khai InnerSource có xu hướng hoạt động tương đối tốt khi được áp dụng cho các thư viện chia sẻ, thành phần nền tảng, công cụ phát triển và mã cơ sở hạ tầng—những lĩnh vực mà “người dùng” chủ yếu là các nhà phát triển khác có thể đóng góp có ý nghĩa và hưởng lợi từ các thực hành phát triển hợp tác.
Trong khi việc áp dụng các thực hành InnerSource cho các ứng dụng hướng người dùng có thể mang lại những lợi ích có giá trị như minh bạch và cải thiện theo dõi vấn đề (điều này một mình đã làm cho nó đáng giá).
Quan điểm cá nhân vs. nhóm #
Vấn đề thứ ba liên quan đến việc “bạn” đề cập đến một cá nhân hay một nhóm.
Điều quan trọng cần lưu ý là InnerSource không nhất thiết phải về việc chờ đợi ai đó đóng góp cho “dự án cá nhân của bạn” trong một công ty. Khi InnerSource được áp dụng, có thể có những trường hợp mà mọi người đóng góp cho các dự án được phát triển trong thời gian 20%, như các công ty công nghệ lớn, nhưng đó không nhất thiết là cách tiếp cận chính thống.
InnerSource chủ yếu được giới thiệu và duy trì vì nó tạo ra ROI thông qua giảm chi phí, tránh phát minh lại bánh xe, tạo ra hiệp lực, đảm bảo chất lượng, và loại bỏ chi phí giao tiếp từ việc ra quyết định theo thứ bậc. Điều này thường liên quan đến các thư viện nội bộ chia sẻ, các thành phần lợi thế cạnh tranh độc quyền, hoặc những thứ có độ phụ thuộc cao mà là thích hợp trong doanh nghiệp. Và những “lợi ích kinh doanh” này thường chảy ngược về “hoạt động nhóm” trong hầu hết các trường hợp. Cuối cùng, tất cả đều về ROI cho các nhóm và tổ chức. Nếu chúng ta không nghĩ về các nhóm, ai đó sẽ ngăn bạn đóng góp cho các dự án. Bạn cần biện minh ROI của mình cho dù đó là ngắn hạn hay dài hạn.
Điều độc đáo về InnerSource là nó về cơ bản là về hợp tác nhóm với nhóm. Đây là nơi mà hầu hết các triển khai cuối cùng kết thúc. Nó không nhất thiết là các cá nhân ngẫu nhiên đóng góp cho các dự án cá nhân thuận tiện. Nó thường được triển khai thông qua các mối quan hệ nhóm chủ và nhóm khách, nơi các nhóm khách đi cùng với các phần được duy trì bởi các nhóm chủ. Hầu hết các doanh nghiệp có nhân viên với vai trò và trách nhiệm được xác định, và sự hợp tác có xu hướng xảy ra trong những cấu trúc này.
Do đó, InnerSource đặc biệt hiệu quả khi các mối quan hệ giữa các nhóm nền tảng và các nhóm stream-aligned (nhóm khách và nhóm chủ) được thiết lập. Sự đồng sáng tạo tích cực giữa các nhóm stream-aligned hoặc cá nhân có tính không chắc chắn cao hơn để thành công một cách tự nhiên.
Việc chỉ trích toàn bộ InnerSource dựa trên các kịch bản không có khả năng hoạt động không có ý nghĩa logic.
Hiểu lầm thứ hai: “Điều đó không bao giờ xảy ra trong các công ty thực tế” #
because we want people doing that the reality is that’s not what’s going to happen ever at any company ever inner source
Thực tế, điều này đang xảy ra. Các nghiên cứu tình huống chứng minh điều đó. Hết.
Hiểu lầm thứ ba: “99.69% các dự án InnerSource sẽ thất bại” #
99.69% a lie you’re going to build the entire project by yourself when it goes down people are going to look to you
Điều này có thể đúng tùy thuộc vào cách bạn định nghĩa “InnerSource.” Như đã đề cập trước đó, InnerSource không phải về “nhận đóng góp PR.”
Tuy nhiên, có ba điểm quan trọng cần xem xét:
- InnerSource đặc biệt áp dụng cho các thành phần chiến lược - nó không bắt buộc cho tất cả các thành phần
- Lợi ích mở rộng ra ngoài các đóng góp tích cực
- Mã nguồn mở có cùng vấn đề “tỷ lệ thất bại”
InnerSource là một chiến lược doanh nghiệp #
Khi mọi người nghĩ về InnerSource, đôi khi họ tưởng tượng những ý tưởng cực đoan như “chia sẻ tất cả mã trong doanh nghiệp” hoặc “mọi người đóng góp cho mọi thứ.” Họ có thể hình dung hàng trăm kho lưu trữ chia sẻ trong một công ty với mọi người tích cực trao đổi đóng góp. Giống như mã nguồn mở là một chiến lược cho các công ty, InnerSource cũng là một chiến lược doanh nghiệp với các ưu tiên. Các công ty chia sẻ “những gì đáng chia sẻ” trước.
Do đó, số lượng thực tế của các codebase nơi mã tích cực chảy giữa các nhóm và sự hợp tác sôi nổi giữa các nhóm xảy ra là tương đối nhỏ. Điều này thực sự có thể là tỷ lệ phần trăm một chữ số. Tuy nhiên, ngay cả khi không có sự hợp tác tích cực giữa các nhóm, nhiều dự án có thể hưởng lợi từ việc mở và minh bạch. Theo nghĩa InnerSource này, các doanh nghiệp thường có thể chia sẻ giá trị qua nhiều trường hợp hơn.
Trong khi InnerSource bao gồm các đóng góp cá nhân, nó chủ yếu tập trung vào hợp tác nhóm với nhóm. Do đó, những gì được chia sẻ thông qua InnerSource có xu hướng tương đối thích hợp trong các doanh nghiệp, hoặc các mục đích cụ thể như các bản phân phối Linux được fork cho các nhu cầu cụ thể. Hoặc nó có thể đơn giản là văn hóa phát triển giống như mã nguồn mở, như khi GitHub chia sẻ mã Ruby on Rails qua tất cả nhân viên.
Khi chúng ta điều kiện hóa cuộc thảo luận tỷ lệ phần trăm này trên InnerSource mà tích cực hợp tác và được duy trì như các yêu cầu chung, tỷ lệ phần trăm thực sự có thể tương đối thấp. Tuy nhiên, các hợp tác nhỏ như pull request tài liệu hoặc thay đổi cấu hình nhỏ (gửi các bản vá nhỏ) giữa các nhóm khách và các nhóm nền tảng/chủ xảy ra tương đối thường xuyên. Khi bạn bao gồm những hợp tác vi mô này và lợi ích minh bạch ngăn ngừa nỗ lực trùng lặp, những con số này tăng đáng kể.
Mã nguồn mở có cùng “vấn đề” #
Mặt khác, nếu chúng ta định nghĩa theo cách đó, mã nguồn mở cũng sẽ là một “lời dối trá.” Bởi vì “99.69% các dự án mã nguồn mở sẽ thất bại.” Hầu hết mã được xuất bản như mã nguồn mở không nhận được đóng góp. Nhưng không ai nói “mã nguồn mở là một lời dối trá” vì điều đó. Mọi người theo đuổi mã nguồn mở vì có những lợi ích ngoài việc nhận đóng góp.
Một lần nữa, “được đóng góp” không phải là giá trị duy nhất của InnerSource. Và điều tương tự cũng đúng cho giá trị mã nguồn mở.
Lợi ích thực sự của minh bạch #
Giữ mã nội bộ mở thay vì ẩn - tại GitHub, các kiến trúc sư hoặc kỹ sư giải pháp trong nhóm doanh thu có thể kiểm tra mã nguồn để tìm thông tin liên quan, có khả năng tìm thấy chi tiết rất gần với yêu cầu của khách hàng, tạo điều kiện cho các cuộc trò chuyện hỗ trợ mượt mà hơn, và trích xuất thông tin chính xác hơn từ các vấn đề. Tôi sống ở Tokyo, và đôi khi việc chỉ nhìn vào mã Ruby để kiểm tra triển khai, hoặc đi đến các vấn đề để kiểm tra bối cảnh của các thay đổi, nhanh hơn so với việc chờ nhóm sản phẩm có trụ sở tại SF thức dậy để hỏi các câu hỏi triển khai về các thay đổi và bối cảnh của chúng.
Sử dụng lệnh git blame, bạn có thể xác định các “bên liên quan thực sự” của mã và đặt câu hỏi về bối cảnh của các quyết định.
Không cần phải nói, điều tương tự cũng áp dụng cho các nhóm phát triển khác. Có thông tin sẵn có về các thành phần có thể tạo ra các phụ thuộc rõ ràng giảm chi phí giao tiếp.
InnerSource là về việc thực hành các nguyên tắc mã nguồn mở nội bộ. InnerSource không chỉ về việc gửi pull request qua lại - nó về việc đảm bảo minh bạch và đạt được lợi ích thông qua hợp tác kiểu mã nguồn mở. Những lợi ích này mở rộng xa hơn vài phần trăm của các kho lưu trữ được duy trì tích cực đến lợi ích triển khai văn hóa rộng lớn hơn.
Hiểu lầm thứ tư: “Bạn sẽ bị gọi lại khi bạn rời đi” #
“when you leave the company they’re going to send you a message 6 months later asking you questions or seeing if you would like to contract with them to upgrade your application there is no such thing as innersourcing”
Tài nguyên đôi khi không được duy trì, nhưng đây không phải là một lời chỉ trích phù hợp về InnerSource - đó là lời chỉ trích về việc thất bại trong việc triển khai InnerSource đúng cách. Đây không phải là lời chỉ trích về InnerSource, mà là lời chỉ trích về việc thiếu văn hóa duy trì nơi không ai duy trì mã. Điều này là kết quả của việc thất bại trong việc triển khai InnerSource đúng cách hoặc không xem xét nó chút nào - kết quả của việc thiếu quyền sở hữu.
Sự tương tự với DevOps #
Đây là lời chỉ trích về việc thất bại trong việc thực hiện InnerSource, không phải lời chỉ trích về InnerSource. Đôi khi điều này làm rối loạn logic. Để đặt điều này trong thuật ngữ DevOps: nó giống như nói “các công ty cuối cùng áp dụng các chu kỳ đánh giá chậm của vài tháng hoặc kiểm toán, hoặc thêm quy trình cho các quyết định phát hành, vì vậy các bản phát hành trở thành hàng quý hoặc chỉ hai lần một năm. Do đó DevOps, tuyên bố cho phép phát hành nhanh, không tốt.” Đó không phải vì phương pháp DevOps tệ, mà đơn giản vì “có những trường hợp mà DevOps không thể được triển khai.”
Phá vỡ các quy trình kinh doanh cực kỳ khó khăn, và nhiều công ty nói DevOps là không thể. Nhưng ngay cả khi mọi người nghĩ nó không thể, có những người tiên phong dũng cảm đã làm việc chăm chỉ để thay đổi văn hóa và đạt được DevOps. Điều tương tự có thể xảy ra với InnerSource.
Hiểu lầm thứ năm: “Bạn phải sở hữu mọi thứ 100%” #
you own it 100% (which implies: InnerSource where you don’t own 100% is impossible)
“InnerSource có nghĩa là từ bỏ quyền sở hữu mã” là sai. InnerSource thực sự yêu cầu các nhóm sở hữu mã. Đây là một sai lầm phổ biến. Điều này giống như những người muốn từ bỏ trách nhiệm duy trì và nói “hãy làm cho nó mã nguồn mở.” Điều đó không hoạt động.
Quyền sở hữu cá nhân vs. nhóm - InnerSource có phải là quyền sở hữu mã mạnh? #
Đầu tiên, “Bạn” này là cá nhân hay số nhiều? Mặc dù các cá nhân có thể được liệt kê như tệp CODEOWNERS trong các tổ chức, các nhóm cuối cùng giữ trách nhiệm cho mã. Theo ngữ cảnh, có khả năng nói về Strong Code Ownership. Nhưng điều này không tốt khi xem xét duy trì tổ chức. Bởi vì nhân viên có thể nghỉ việc.
InnerSource không phải là Strong Code Ownership. Ít nhất, nhiều người cần chia sẻ trách nhiệm. Nói như vậy, tôi thừa nhận rằng Strong Code Ownership có thể xuất hiện trong ngắn hạn, và trong giai đoạn đầu của một dự án, ý chí cá nhân mạnh mẽ có thể tự nhiên dẫn đến những sắp xếp như vậy, nhưng nếu bạn muốn đạt được thành công dài hạn, cần thiết phải ủy quyền để tổ chức có thể xử lý duy trì một cách tập thể.
Các loại quyền sở hữu nhóm - InnerSource có phải là quyền sở hữu mã tập thể? #
Loại lập luận này đôi khi có thể đề cập đến Collective Ownership. Trong trường hợp này, lập luận cũng dường như gợi ý rằng InnerSource có nghĩa là quyền sở hữu tập thể, nhưng điều đó thực sự khác. InnerSource không phải là Collective Code Ownership InnerSource liên quan đến các nhóm chủ cuối cùng xử lý duy trì. InnerSource là Weak Code Ownership. Vì vậy, trong khi trách nhiệm duy trì là 100% đúng, việc nói “bạn phải sở hữu 100% và InnerSource khác” hoàn toàn không logic. Đây thực sự là một ý kiến không chính xác.
Như Martin Fowler đã lập luận nổi tiếng về quyền sở hữu mã, việc để mọi người sở hữu mã 100% (quyền sở hữu tập thể) đôi khi tạo ra các tình huống mà không ai chịu trách nhiệm. Điều đó rất có vấn đề - trách nhiệm trở nên không rõ ràng và các dự án cuối cùng thất bại.
Mô hình Weak Code Ownership #
Trong Weak Code Ownership, người duy trì tồn tại, các nhóm chủ duy trì dự án, và các phần cụ thể có thể mang vào những người cam kết/duy trì đáng tin cậy từ các nhóm khác. Ai đó có thể đóng góp, ai đó có thể duy trì, nhưng không 100% bởi “bạn” hoặc “nhóm của bạn” - nó có thể khá khác. Ví dụ, 98% mã có thể được sở hữu bởi nhóm của bạn, trong khi 2% có thể được sở hữu bởi các nhóm khác.
Trong trường hợp này, hãy nhớ rằng ngay cả khi các cá nhân được chỉ định làm chủ sở hữu mã trong các tổ chức, các nhóm cuối cùng giữ trách nhiệm cho mã. Các nhóm nên sở hữu nó, và đừng quên điểm quan trọng này.
Hiểu lầm thứ sáu: “Ai đó sẽ thả 7000 dòng lên bạn” #
Every now and then there will be a sufficiently motivated coworker who’s really great and do like a 7,000 line update no explanation but don’t ever fall into this idea that choosing anything for an internal app that you are going to be working on
Việc có pull request 7000 dòng đột nhiên xuất hiện bản thân là một thất bại trong việc giới thiệu văn hóa InnerSource - đó không phải là điều xảy ra bằng cách thực hiện InnerSource. Trường hợp này có thể lo lắng rằng việc giới thiệu InnerSource làm cho sự hợp tác như vậy xảy ra, nhưng điều đó hoàn toàn sai.
Vấn đề thực sự #
Lập luận này đại diện cho việc thất bại trong việc triển khai văn hóa InnerSource và các thực hành hợp tác, không phải InnerSource. Các triển khai 7000 dòng là những trường hợp rất hạn chế. Điều này đại diện cho thất bại của văn hóa hợp tác nơi 7000 dòng được gửi như pull request đột nhiên mà không có thông báo nào - tổ chức nên sửa chữa vấn đề văn hóa cơ bản này, đó là tiền InnerSource.
Nếu bạn muốn ngăn chặn điều này, có một giải pháp. Nuôi dưỡng văn hóa InnerSource trong tổ chức của bạn:)
Thực tế: InnerSource thực sự là gì #
InnerSource là triển khai văn hóa - sử dụng các thực hành hợp tác mã nguồn mở để tận hưởng các lợi ích khác nhau mà mã nguồn mở nhận được thông qua hợp tác. Mục đích cuối cùng của InnerSource không chỉ nhận đóng góp (pull request), mà bao gồm yêu cầu tính năng thông qua vấn đề, phối hợp hỗ trợ, và các lợi ích khác nhau khác, cộng với minh bạch trong việc ra quyết định và thúc đẩy văn hóa thực tế.
Do đó, tôi hoàn toàn từ chối tuyên bố rằng “triển khai các thực hành tốt nhất InnerSource để nhận pull request là một lời dối trá.”
Hiểu thực tế đóng góp #
“Nobody ever is going to contribute”
Trong hợp tác mã nguồn mở, những người đóng góp thực sự là một phần nhỏ. Trong số 1000 người dùng, có thể đại đa số chỉ là người dùng, 20 có thể gửi vấn đề hoặc yêu cầu tính năng, 5 có thể gửi pull request, và có thể chỉ một người trở thành người duy trì.
Một lần nữa, các thực hành tốt nhất InnerSource sẽ không làm cho tất cả 1000 người đóng góp. InnerSource giúp tạo ra sự hợp tác như vậy, nhưng cuối cùng nhằm phá vỡ các silo doanh nghiệp, cải thiện hợp tác bị cản trở bởi các ràng buộc tổ chức truyền thống, giảm thời gian dẫn đầu từ các silo thông tin, và tối ưu hóa phân bổ tài nguyên tổ chức bằng cách sử dụng các thực hành mã nguồn mở.
Kết luận #
Trong khi các lập luận trong trường hợp này chạm vào một số thách thức thực sự, chúng dựa trên những hiểu lầm phổ biến mà nhiều người gặp phải khi lần đầu tìm hiểu về InnerSource. Đây là những cạm bẫy nổi tiếng trong cộng đồng, và có thể hiểu được cách ai đó có thể đạt đến những kết luận này mà không khám phá sâu hơn lĩnh vực này.
Hiểu biết chính là InnerSource không phải về việc ép buộc các thực hành mã nguồn mở vào một khung cứng nhắc. Thay vào đó, nó về việc quay trở lại câu hỏi cơ bản: chúng ta có thể học gì từ mã nguồn mở? Bằng cách xem xét mã nguồn mở thông qua một lăng kính rộng hơn, chúng ta có thể thích ứng tốt hơn những nguyên tắc này nội bộ.
Bạn có thể tham gia cuộc trò chuyện này và mang đến những quan điểm mới mẻ. Cho dù bạn muốn xây dựng trên cuộc thảo luận này, khám phá chi tiết triển khai cụ thể hơn, hoặc thậm chí thách thức hoàn toàn những lập luận này - tất cả các cách tiếp cận đều được chào đón. Điều quan trọng nhất là duy trì quan điểm rộng về những học hỏi từ mã nguồn mở và cách chúng dịch sang bối cảnh tổ chức nội bộ.
Để có thông tin toàn diện về InnerSource, tôi khuyên bạn nên kiểm tra InnerSource Commons Foundation. Họ chào đón các quan điểm đa dạng và đối t화 liên tục về cách các nguyên tắc mã nguồn mở có thể tạo ra giá trị trong các tổ chức.
