Kháng chiến nguồn mở: hãy bảo vệ nguồn mở trong giờ làm việc

 (ossresistance.com)
6 điểm bởi GN⁺ 2026-05-15 | 2 bình luận | Chia sẻ qua WhatsApp
  • Open Source Resistance là một tuyên ngôn hành động trực tiếp kêu gọi các doanh nghiệp âm thầm, chuyên nghiệp bảo trì phần mềm nguồn mở mà họ đang phụ thuộc ngay trong giờ làm việc
  • Dù mọi doanh nghiệp đều không thể vận hành nếu thiếu nguồn mở, tuyên ngôn này phản đối cấu trúc buộc các maintainer phải van xin giấy phép riêng, nút quyên góp, hay vài giờ chiều thứ Sáu
  • Trước đây đã có các lựa chọn thay thế như Open Source Pledge (đề nghị trả US$2.000 mỗi năm cho mỗi lập trình viên) hay Open Source Friday (đóng góp tối thiểu 2 giờ mỗi chiều thứ Sáu hằng tuần), nhưng tuyên ngôn này nhấn mạnh việc hành động trực tiếp hơn
  • Trước phản biện rằng đây là “ăn cắp thời gian”, có thể đáp rằng công ty từ lâu đã nhận trợ cấp OSS miễn phí, và việc bảo trì OSS mà doanh nghiệp phụ thuộc là công việc hạ tầng dùng chung
  • Cần обязательно kiểm tra điều khoản chuyển nhượng IP trong hợp đồng lao động và thương lượng ngoại lệ cho nguồn mở bằng văn bản

Tuyên ngôn: đừng xin phép để sửa thứ vốn đã cần thiết

  • Open Source Resistance đề xuất hành động trực tiếp: đừng đẩy việc bảo trì phần mềm nguồn mở (OSS) mà công ty đang phụ thuộc sang buổi tối hay cuối tuần như một sở thích, mà hãy âm thầm và chuyên nghiệp thực hiện nó trong giờ làm việc
  • Phần mềm nguồn mở không phải “sở thích” lúc rảnh rỗi; các doanh nghiệp liên tục rút giá trị từ nguồn mở từng giờ, nhưng với maintainer thì chỉ đưa ra một buổi chiều thứ Sáu, một nút quyên góp, hay một lời cảm ơn trong cuộc họp toàn công ty
  • Maintainer nên thực hiện công việc với mã OSS mà công ty đã phụ thuộc ngay trong giờ làm việc, không cần giấy tờ, chương trình nội bộ hay phê duyệt của quản lý
  • Đây không phải ý tưởng mới, mà là nói công khai về cách phần lớn nguồn mở vốn luôn được duy trì
  • Các maintainer đã giữ cho Internet vận hành mà không chờ họp, sprint hay sự cho phép của product manager

Các nguyên tắc hành động cốt lõi

  • Tự bảo vệ mình

    • Hãy kiểm tra hợp đồng lao động, giữ thông tin mật ở lại trong công ty, và đảm bảo bạn nắm quyền sở hữu IP của phần nguồn mở mình phát hành

  • Hãy làm việc đó

    • Thực hiện review PR, cập nhật dependency, và sửa lỗi ở những phần vốn đã là OSS

  • Đừng liều lĩnh

    • Đừng dành 100% giờ làm cho OSS rồi bị sa thải xong đổ lỗi cho người khác; cân bằng mới là điều cốt lõi

Những lựa chọn thay thế hiện có

  • Open Source Pledge: kêu gọi doanh nghiệp trả tiền cho maintainer (US$2.000/năm cho mỗi lập trình viên)
  • Open Source Friday: kêu gọi doanh nghiệp đóng góp thời gian (ít nhất 2 giờ mỗi chiều thứ Sáu hằng tuần)
  • Cũng có con đường ôn hòa là thuyết phục nhà tuyển dụng trước, và tất cả các cách này đều tích cực, đáng được ủng hộ
  • Open Source Resistance là bước tiếp theo của xu hướng đó, khẳng định rằng việc bảo trì chuỗi dependency vốn đã là một phần công việc, dù quản lý có gọi tên nó hay không
  • Bạn không kiểm soát được cách công ty phân bổ ngân sách, nhưng có thể kiểm soát cách mình dùng thời gian làm việc

Các phản đối dự kiến và câu trả lời

  • “Đó là ăn cắp thời gian / ăn cắp của cổ đông”

    • Doanh nghiệp vốn đã rút giá trị từ maintainer nguồn mở mỗi ngày, và cổ đông đã nhận trợ cấp nguồn mở miễn phí suốt hàng chục năm
    • Nếu nhà tuyển dụng phụ thuộc vào OSS, thì bảo trì nó là công việc hạ tầng phục vụ lợi ích chung, không phải trộm cắp

  • “Phải xin phép”

    • Việc xin phép là cách duy trì bất cân xứng quyền lực
    • Bạn không cần sự ban phước của quản lý để bảo trì hạ tầng mà công ty đã phụ thuộc

  • “Chuyện này giống quiet quitting”

    • Quiet quitting là giảm khối lượng công việc, còn đây là sản xuất hạ tầng OSS đã tạo nên Internet
    • Vấn đề không nằm ở bản thân công việc, mà ở việc doanh nghiệp từ chối xem đó là công việc

  • “Ngay cả nhà tuyển dụng tốt cũng bị ảnh hưởng”

    • Nhà tuyển dụng tốt có thể tránh vấn đề này bằng cách cho phép bảo trì nguồn mở trong giờ làm, hỗ trợ tài chính cho maintainer hoặc tham gia Open Source Pledge

Kinh nghiệm của Mike McQuaid

  • Đồng sáng lập Open Source Friday và GitHub Sponsors, đồng thời là trưởng dự án Homebrew (maintainer từ năm 2009)
  • Ở bất kỳ nơi làm việc nào, công việc trên dự án nguồn mở như Homebrew chưa từng được trả lương như nhiệm vụ chính thức
  • Dù vậy, ông vẫn làm việc đó ở mọi công ty, thương lượng hợp đồng IP để hợp pháp hóa và vẫn hoàn thành các cam kết công việc
  • Sau khi có con, hơn 90% công việc nguồn mở của ông được thực hiện trong giờ làm
  • Như trong Open Source Maintainers Owe You Nothing, ông cho rằng không ai có quyền yêu cầu maintainer hy sinh buổi tối, cuối tuần hay thời gian cho gia đình chỉ vì mô hình kinh doanh của một công ty phụ thuộc vào mã của họ

Lưu ý và thông báo pháp lý

  • Đây không phải tư vấn pháp lý

    • Nội dung này không phải tư vấn pháp lý, và không phải lời khuyên về hợp đồng, nhà tuyển dụng, tình trạng nhập cư, nghĩa vụ giấy phép hay từng hoàn cảnh cá nhân
    • Nếu rủi ro lớn, bạn nên tham khảo người có chuyên môn trước khi hành động
    • Giống như phần lớn giấy phép nguồn mở, nội dung này được cung cấp “nguyên trạng”, không có bất kỳ bảo đảm nào

  • Hợp đồng, chính sách, quyền sở hữu

    • Hợp đồng lao động, chính sách trong handbook, và điều khoản chuyển nhượng sáng chế có thể cho phép nhà tuyển dụng đòi quyền đối với công việc được tạo ra trong thời gian làm việc, trên thiết bị của công ty, hoặc trong phạm vi nhiệm vụ được giao
    • Ở một số bang, các đòi hỏi như vậy bị hạn chế với công việc làm bằng thời gian riêng và thiết bị riêng, nhưng chi tiết rất quan trọng
    • Trước khi thực hiện, hãy đọc hợp đồng lao động và xác nhận rằng nhà tuyển dụng không sở hữu IP nguồn mở mà bạn định công bố
    • Nếu thiết bị, mạng hay tài khoản có thể làm thay đổi rủi ro về quyền sở hữu, hãy dùng đồ của riêng bạn

  • Thương lượng hợp đồng IP

    • Việc chuyển nhượng IP thường có thể thương lượng; khi nhận được offer, nên yêu cầu bằng văn bản điều khoản ngoại lệ cho nguồn mở trước khi ký
    • Trước tiên, hãy đọc hợp đồng IP của nhân viên để biết mình cần phản đối điều gì
    • Mike McQuaid cho biết ông đã thương lượng thay đổi ngoài hợp đồng tiêu chuẩn với gần như mọi nhà tuyển dụng, và đa số phản đối ít hơn nhiều so với dự đoán
    • Bạn có thể đưa cho nhà tuyển dụng tiềm năng xem Balanced Employee IP Agreement của GitHub
    • Hợp đồng này đã được mở nguồn theo CC0, từng được các công ty đại chúng lớn sử dụng thực tế, và được thiết kế để nhà tuyển dụng giữ những gì họ đã trả tiền, còn nhân viên giữ các công việc nguồn mở không cạnh tranh với hoạt động kinh doanh

  • Bảo mật và an toàn

    • Không được công khai repository riêng tư, thông tin xác thực, sự cố, dữ liệu khách hàng, roadmap, lỗ hổng chưa công bố, hay các thảo luận nội bộ
    • Không được vượt qua kiểm soát bảo mật hay sử dụng quyền truy cập không được cho phép
    • Hành động trực tiếp không phải cái cớ để tiết lộ thông tin mật của công ty; mục tiêu là giữ việc công khai ở trạng thái công khai và tách biệt rõ với bí mật thương mại

  • Im lặng không có nghĩa là bất cẩn

    • Khi chính sách, hợp đồng, nghĩa vụ với khách hàng hay quy tắc an toàn làm thay đổi rủi ro, bạn cần tự đưa ra phán đoán
    • Có thể bạn phải làm việc bằng thiết bị, tài khoản và mạng của riêng mình
    • Đây không phải là “ăn cắp” từ công ty, mà là tái cân bằng giữa những gì công ty lấy từ nguồn mở và những gì bạn có thể đóng góp
    • Bạn có thể nhận đánh giá hiệu suất thấp hơn đồng nghiệp, nhưng mức B bền vững vẫn lành mạnh hơn việc đốt cạn cuộc sống để lấy điểm A ở một công ty mà ngày mai có thể sa thải bạn

  • Giới hạn áp dụng

    • Lập luận này yếu nhất khi thời gian làm việc được tính trực tiếp cho khách hàng cụ thể, khoản tài trợ, cơ quan nhà nước, dự án quốc phòng, hay môi trường có quy định chặt chẽ
    • Nó cũng yếu nhất với kỹ sư junior hoặc ở vị thế bấp bênh không có đủ ảnh hưởng để chịu hậu quả bất lợi
    • Nó mạnh nhất với maintainer cấp senior đang sửa các dependency công khai mà nhà tuyển dụng đã dùng
    • Hình thức rõ ràng nhất không phải là “hãy làm bất cứ điều gì bạn muốn trong giờ làm”, mà là xem bảo trì nguồn mở như một phần của công việc kỹ thuật
    • Hãy duy trì những dự án bạn vốn đã duy trì, cải thiện các công cụ dùng chung mà công việc của bạn chạm tới, và tránh những việc không liên quan, mã độc quyền, hay bất kỳ thứ gì khiến bạn bỏ lỡ cam kết thực tế

Nguồn và dự án

Bài viết liên quan

2 bình luận

 
roxie 24 ngày trước

Xét tổng thể thì có lẽ cách diễn đạt là “resistance” là phù hợp.
 
GN⁺ 2026-05-15
Ý kiến trên Hacker News

  • Phần lớn các công ty thường cấp phép khá rộng để đóng góp cho một số dự án mã nguồn mở nhất định.
    Cách diễn đạt rất quan trọng. Không phải là: “Tôi có thể làm từ thiện cho vui được không?”, mà là: “Tôi có thể nhận review nghiêm ngặt miễn phí từ các chuyên gia trong lĩnh vực này, đồng thời đưa các chỉnh sửa trở lại dự án mã nguồn mở upstream để loại bỏ chi phí bảo trì về sau cho công ty không?”
    Thực chất vấn đề là như vậy, và khi nói theo cách đó thì chưa từng có chủ lao động nào từ chối. Điều này hoàn toàn phù hợp với lợi ích của công ty, nên chỉ cần giúp họ nhìn ra điều đó

    • Có nhiều điều khiến tôi tiếc vì đã bị sa thải ở chỗ làm cũ, và một lý do lớn là khi đó chúng tôi đang bàn xem có nên công bố ra mã nguồn mở một thay đổi khá lớn mà tôi đã thực hiện cho thư viện Kafka Streams hay không.
      Tôi đã viết lại nhiều phần trong khi vẫn giữ API phần lớn tương thích, theo hướng nhấn mạnh I/O không chặn để có thể dùng ngữ nghĩa backpressure khi cần. Nó cho phép làm nhiều thứ thú vị vì vẫn giữ hiệu năng khá tốt ngay cả khi trộn state store với I/O chặn/không chặn, và tôi đặc biệt tự hào vì đây là một dự án đã moi ra hiệu năng ở nhiều điểm ít ai để ý.
      Tôi đã cố thúc đẩy việc đưa nó lên GitHub hoặc gửi PR lên dự án Kafka Streams upstream, nhưng trước đó đã có đợt sa thải, và sau đó không còn người bảo trợ nào để đẩy việc này nữa nên nó bị khóa lại thành mã độc quyền.
      Tôi vẫn nghĩ tới chuyện làm lại từ đầu rồi phát hành thành mã nguồn mở tự do. Cũng đã khá lâu rồi nên có lẽ viết lại và công bố sẽ không có vấn đề gì, cũng không có bằng sáng chế gì liên quan, và tôi còn có vài thứ muốn thay đổi như bỏ phụ thuộc vào Vert.x. Biết đâu lúc nào đó có được khoảng một tuần nghỉ thì tôi sẽ làm
    • Tôi nhớ quãng thời gian từng làm ở nơi cho phép những việc như thế này.
      Có những công ty chỉ riêng quy trình rà soát pháp lý thôi cũng đủ làm mọi thứ rối tung lên.
      Có lần tôi xin phép xem có thể gửi một bản vá cho một dự án nào đó không, và rồi xuất hiện một chuỗi email khá thú vị. Cuối cùng câu hỏi chỉ còn là: nếu đây là bản vá được viết trong thời gian tính phí cho khách hàng để sửa lỗi trong sản phẩm giao cho họ, và thư viện đã vá sẽ được biên dịch lại rồi giao cùng mã nguồn, trong khi hợp đồng quy định toàn bộ sản phẩm công việc và quyền sở hữu trí tuệ liên quan đến sản phẩm đều được chuyển cho khách hàng, thì chúng tôi có quyền phát hành bản vá đó vào phạm vi công cộng hay không?
      Đội pháp lý không muốn trả lời
    • Nhìn chung đây là cách tiếp cận tốt, và cũng là ví dụ rất hay về việc định khung công việc một cách chuyên nghiệp. Nhưng nó không giải quyết được cốt lõi vấn đề. Đặc biệt nếu là ban lãnh đạo ở một công ty thiên về kỹ thuật thì họ lẽ ra phải hiểu ngay các lợi ích này; nếu không thì đó đã là vấn đề rồi.
      Việc bạn có thể tiếp cận theo cách nào cũng còn phụ thuộc rất nhiều vào may mắn với chủ lao động
    • “Được thôi, để tôi chuyển việc này sang đội compliance xem qua một chút. Chỉ để đảm bảo không có vi phạm sở hữu trí tuệ. Cụ thể là repo và issue nào vậy?”

  • Về câu “hãy chắc chắn bạn thực sự sở hữu tài sản trí tuệ mã nguồn mở mà mình phát hành”, ở những khu vực pháp lý nơi tôi từng làm việc, mã được viết và phát hành trong giờ làm là tài sản của chủ lao động chứ không phải của tôi.
    Tôi không thể tự quyết việc đóng góp trong giờ làm, và muốn làm việc với mã nguồn mở thì phải có thỏa thuận chính thức. Mỗi lần xin đều mất hàng tháng đi qua bộ phận pháp lý, nên cuối cùng tôi либо bỏ cuộc, либо trong lúc đó đã có người đóng góp khác gửi PR rồi nên tôi không còn muốn xin nữa

    • Có lẽ ý ở đây là “đừng tự tiện đem tặng những thứ không phải của mình”. Bên dưới có hẳn một mục riêng về chuyện này, nhưng nếu chỉ nhìn các gạch đầu dòng phía trên thì khá dễ gây nhầm.
      Với các lập trình viên nhiều kinh nghiệm thì điều này là hiển nhiên, nhưng với một số lập trình viên junior ở vài công ty thì đây đã từng là vấn đề thật. Khi công ty đang làm thứ gì đó hay ho trong dự án nội bộ, họ có thể nghĩ rằng sẽ tuyệt nếu đóng góp nó cho một dự án mã nguồn mở nào đó, mà không để ý rằng họ đang dùng kiến thức từ mã riêng tư để nộp lên đoạn mã về bản chất là tương tự, hoặc đôi khi là copy-paste luôn
    • Tôi chưa tự nghiên cứu kỹ, nhưng tôi hiểu rằng ở Đức, mặc định mọi mã nguồn tạo ra trong giờ làm đều thuộc về chủ lao động.
      Phần lớn các chủ lao động không lấy IT làm trọng tâm có lẽ còn không hiểu mã nguồn mở là gì và hoạt động ra sao. Vì vậy xin phép từ nhiều người có thể là việc tuyệt vọng.
      Trang được liên kết nên tập trung trước hết vào việc giải thích lợi ích của mã nguồn mở cho chủ lao động, đồng thời thúc đẩy hướng dẫn pháp lý cho chủ lao động
    • Nếu một công ty không công bố mã theo giấy phép cho phép, ngoại trừ những phần đi vào production, thì chắc tôi sẽ không làm ở đó. Với tôi đó là chuyện làm mất động lực và có lẽ sẽ đẩy tinh thần tôi tới giới hạn. Tôi thà nghèo còn hơn

  • Đây là một ý tưởng tốt, thậm chí là rất tốt, nhưng tôi không chắc việc định vị nó như một hình thức kháng cự có phải là cách hay hay không.
    Mục tiêu của công việc thường là đạt được một kết quả nào đó. Còn đạt được bằng cách nào thì các lập trình viên với tư cách chuyên gia phải có quyền quyết định. Nếu trong quyết định đó có bao gồm phần mềm mã nguồn mở, thì việc bảo trì nó cũng phải là một phần của quyết định đó.
    Đây không phải chuyện cấp tiến gì; chỉ đơn giản là làm công việc của mình trong khi bảo vệ sự ổn định tương lai và khả năng bảo trì của những thứ công việc đó đang phụ thuộc vào

    • Đây đơn giản cũng là tư duy kinh doanh tốt. Công ty khuyến khích hợp tác thông qua mã nguồn mở là đang nuôi dưỡng hệ sinh thái đang nuôi sống chính hoạt động kinh doanh của họ
    • Tôi đồng ý với mọi điều đã nói, nhưng thực tế ở đa số công ty công nghệ hiện nay, theo trải nghiệm của tôi, lại khác. Họ còn chẳng đầu tư thời gian vào việc bảo trì hạ tầng và thư viện của chính mình nếu không bị ép, huống hồ là mã nguồn mở.
      Những tính năng vô dụng để chơi trò chỉ số, enshittification, dark pattern, hay các tích hợp theo mốt gần như phần mềm độc hại đều được ưu tiên hơn đầu tư vào hạ tầng hoặc thư viện nền tảng
    • Đồng ý. Kiểu mô tả này khiến người ta có cảm giác ai đó đang cố câu thêm chú ý trên mạng xã hội. Thật đáng buồn khi mọi thứ đã đi tới mức đều phải bị cường điệu hóa

  • Về mặt nguyên tắc thì tôi hoàn toàn đồng ý, nhưng để thực sự làm được thì khá rắc rối. Tôi không phải luật sư, nhưng nhìn chung tôi hiểu rằng vì chủ lao động sở hữu quyền sở hữu trí tuệ nên muốn phát hành dưới dạng mã nguồn mở thì cần được cho phép rõ ràng.
    Và quá trình xin phép đó thường rất khó, phải qua vô số thủ tục và bộ phận pháp lý.
    “Tại Mỹ, Anh và nhiều khu vực pháp lý khác, khi nhân viên tạo ra tác phẩm như một phần công việc, chủ lao động được coi là tác giả hợp pháp hoặc chủ sở hữu bản quyền ban đầu.”
    https://en.wikipedia.org/wiki/Work_for_hire
    Dù vậy, tôi vẫn cho rằng công việc mã nguồn mở, tức bảo trì và phát triển, nên do các chuyên gia được trả lương thực hiện chứ không phải các tình nguyện viên đi xin tài trợ. Câu hỏi cốt lõi là làm sao biến điều đó thành hiện thực, và làm sao để các công ty chấp nhận đóng góp mã nguồn mở như một thông lệ tiêu chuẩn thay vì một ngoại lệ phải đàm phán riêng từng lần

    • Những vấn đề bạn mô tả gần như là vấn đề lý thuyết hơn là “vấn đề thực tế trong công việc”.
      Trong thực tế thì cứ làm thôi. Không có subroutine nào trong máy tính chặn git push cả. Ngoài đời, chủ lao động nhét đủ thứ vào hợp đồng lao động. Họ viết càng nhiều càng tốt để né trách nhiệm từ mọi hướng. Nếu họ có thể tùy ý viết như vậy, tại sao chúng ta không thể cứ làm luôn? Chẳng có gì là quan trọng cả.
      Trên thực tế, số dự án mã nguồn mở bị thách thức về sở hữu trí tuệ vì các lý do kỹ thuật kiểu này gần như bằng 0
    • Đúng là nếu công việc đó liên quan đến nhiệm vụ của bạn thì chủ lao động sẽ có quyền sở hữu trí tuệ.
      Còn nếu không liên quan đến nhiệm vụ thì còn tùy từng bang. Nhiều bang có giới hạn về phạm vi mà chủ lao động có thể tuyên bố là tài sản trí tuệ của mình. Hợp đồng thông thường hay dùng câu chữ rất rộng để đòi mọi thứ, nhưng pháp luật thường nói rằng công ty không thể lấy cả những dự án làm lúc rảnh hoàn toàn không liên quan đến họ.
      Nếu làm trong giờ làm hoặc dùng laptop công ty thì công ty sẽ có cơ sở để đòi quyền. Hầu hết công ty có thể sẽ không quan tâm, nhưng nếu có tranh chấp thì đừng chủ quan nếu muốn giữ mọi thứ sạch sẽ.
      Hãy làm bằng thời gian cá nhân, thiết bị cá nhân, và đừng để nó chồng lấn với công việc bạn được thuê làm hay những gì bạn tiếp cận trong công ty
    • Tôi không phải luật sư, nhưng nếu bạn đã đưa bản sao cho đồng nghiệp để họ chạy thử, thì chẳng phải như vậy tự thân đã là đang dùng giấy phép mã nguồn mở hay sao? Đồng nghiệp đó sẽ có các quyền pháp lý do giấy phép cấp, và cũng sẽ có quyền phân phối lại các thay đổi chứ?
      Đưa thay đổi lên upstream là cách tốt nhất để đảm bảo khả năng bảo trì, nên toàn bộ chuyện này trông rất buồn cười. Sự mập mờ pháp lý khi phải duy trì một fork nội bộ độc quyền cũng vậy
    • Có vẻ bài viết đang gợi ý đi theo con đường ít kháng cự nhất. Làm việc đó trong giờ công ty và đừng tạo sóng gió lớn. Nếu bị phát hiện thì xin tha thứ sau. Từ góc nhìn công ty, tha thứ là con đường dễ hơn. Nếu lôi luật sư vào thì chi phí sẽ rất lớn, thậm chí còn có thể thành thảm họa truyền thông
    • Nếu có điều gì mà tình trạng lập trình hiện nay cho thấy, thì đó là luật sở hữu trí tuệ và bản quyền thực chất đã không còn tồn tại nữa

  • Tôi làm ở một công ty khá lớn. Chính sách mã nguồn mở của công ty tôi đại khái có thể tóm gọn là: “Hãy hỏi quản lý trước, đừng làm dưới danh nghĩa công ty, và đừng tiết lộ thông tin mật.”
    Chưa từng có vấn đề gì, và về tổng thể tôi thấy điều đó hoàn toàn hợp lý

  • Tôi thấy đóng góp như sửa lỗi cho một dự án mã nguồn mở bên thứ ba trong giờ làm thì không sao, nhưng với mã nguồn mở của chính mình thì tôi không biết nên xử lý thế nào.
    Ví dụ bạn có một thư viện nhỏ tự làm, công ty cũng dùng nó, rồi trong giờ làm bạn phát hiện ra lỗi. Nếu đóng góp trong chính giờ làm đó thì có vẻ là vùng xám.
    Có ai từng đàm phán chuyện này ngay từ vòng phỏng vấn chưa? Tôi muốn biết mọi người đã làm thế nào

    • Tôi chưa từng làm ở công ty nào thực sự quan tâm chuyện này. Tôi chỉ làm những gì cần làm thôi. Ngay cả khi tôi hỏi phải làm thế nào cho “đúng quy trình” thì cũng chưa từng nhận được câu trả lời nào

  • Khi còn làm ở tập đoàn lớn, nhìn chung mỗi khi tôi yêu cầu được làm thứ gì ngoài việc trực tiếp viết mã cho codebase của công ty, dù có đưa ra lý do, quản lý trực tiếp vẫn sẽ trả lời là “làm vào thời gian rảnh đi”.
    Trong môi trường định hướng lợi nhuận, người ta thường coi chỉ những gì mang lại giá trị tức thì mới đáng theo đuổi. Thái độ đó khá ký sinh, và hiệu quả bị đẩy lên cao cùng cuộc đua chỉ số từ tầng trên chính là thứ tạo ra nó

  • Tôi chắc chắn đã từng fork rồi sửa để giải quyết vấn đề công việc, sau đó gửi kết quả ngược lại upstream bằng PR.
    Đây là một trong những điểm hay của việc dùng và có quyền truy cập mã nguồn mở. Đó cũng là lý do trong package.json và cargo.toml, git gần như là một lựa chọn hạng nhất. Bạn có thể trỏ thẳng sang fork của mình cho đến khi thay đổi được đưa upstream

  • Khi đã ở cấp senior, đến bước “Bạn có câu hỏi nào cho chúng tôi không?” trong quá trình phỏng vấn, tôi sẽ hỏi: “Công ty có quan điểm thế nào về việc tôi dành một phần thời gian của mình để đóng góp cho các dự án mã nguồn mở mà công ty đang phụ thuộc vào?”
    Nhìn câu trả lời là bạn có thể quyết định có muốn tiếp tục ở lại hay không