Internal Open Source (โอเพนซอร์สภายในองค์กร)

องค์กรจำนวนมากตัดสินใจนำโอเพนซอร์สภายในองค์กรมาใช้ในรูปแบบใดรูปแบบหนึ่ง ทั้งเพื่อช่วยจัดการปัญหาของ codebase ที่ใช้ร่วมกัน และเพื่อให้คนนอกทีมสามารถส่งการเปลี่ยนแปลงเข้ามาในไมโครเซอร์วิสที่พวกเขาอาจใช้งานอยู่ได้ง่ายขึ้น

ด้วย โอเพนซอร์สแบบปกติ กลุ่มคนเล็กๆ กลุ่มหนึ่งจะถูกถือว่าเป็น core committer พวกเขาเป็นผู้ดูแลโค้ด ถ้าคุณต้องการเปลี่ยนแปลงโปรเจกต์โอเพนซอร์ส คุณก็ต้องขอให้ committer คนใดคนหนึ่งทำการเปลี่ยนแปลงให้ หรือไม่ก็ทำการเปลี่ยนแปลงเองแล้วส่ง pull request ไปให้พวกเขา core committer ยังคงเป็นผู้รับผิดชอบ codebase อยู่ พวกเขาคือเจ้าของ

ภายในองค์กร รูปแบบนี้ก็ใช้ได้ดีเช่นกัน บางทีคนที่เคยทำงานกับเซอร์วิสนั้นตั้งแต่แรกอาจไม่ได้อยู่ในทีมเดียวกันแล้ว บางทีตอนนี้พวกเขาอาจกระจายอยู่ทั่วองค์กร ถ้าพวกเขายังมีสิทธิ์ commit อยู่ คุณก็สามารถหาพวกเขาและขอความช่วยเหลือ อาจจะ pair กับพวกเขา หรือถ้าคุณมีเครื่องมือที่เหมาะสม คุณก็สามารถส่ง pull request ให้พวกเขาได้

Role of the Core Committers (บทบาทของ Core Committer)

เราก็ยังอยากให้เซอร์วิสของเรามีเหตุมีผล เราต้องการให้โค้ดมีคุณภาพดี และตัวไมโครเซอร์วิสเองก็แสดงความสอดคล้องบางอย่างในการประกอบขึ้นมา เรายังต้องการมั่นใจด้วยว่าการเปลี่ยนแปลงที่ทำในตอนนี้จะไม่ทำให้การเปลี่ยนแปลงที่วางแผนไว้ในอนาคตยากขึ้นกว่าที่จำเป็น นั่นหมายความว่าเราต้องใช้รูปแบบเดียวกับที่ใช้ในโอเพนซอร์สแบบปกติภายในองค์กรด้วย ซึ่งหมายถึงการแยก committer ที่เชื่อถือได้ (core team) ออกจาก committer ที่ยังไม่ได้รับความเชื่อถือ (คนนอกทีมที่ส่งการเปลี่ยนแปลงเข้ามา)

ทีม core ownership ต้องมีวิธีการตรวจสอบและอนุมัติการเปลี่ยนแปลง ต้องมั่นใจว่าการเปลี่ยนแปลงมีความสอดคล้องเชิงรูปแบบ (idiomatically consistent)—นั่นคือปฏิบัติตามแนวทางการเขียนโค้ดทั่วไปของ codebase ที่เหลือ ดังนั้นคนที่ทำการตรวจสอบจะต้องใช้เวลาทำงานร่วมกับผู้ส่งการเปลี่ยนแปลงเพื่อให้แน่ใจว่าการเปลี่ยนแปลงแต่ละครั้งมีคุณภาพเพียงพอ

Gatekeeper ที่ดีจะทุ่มเทความพยายามอย่างมากในเรื่องนี้ สื่อสารอย่างชัดเจนกับผู้ส่งการเปลี่ยนแปลงและสนับสนุนพฤติกรรมที่ดี ส่วน gatekeeper ที่ไม่ดีอาจใช้สิ่งนี้เป็นข้ออ้างในการใช้อำนาจเหนือคนอื่น หรือทะเลาะกันแบบยึดติดความเชื่อเกี่ยวกับการตัดสินใจทางเทคนิคที่ไม่มีเหตุผลชัดเจน จากที่ได้เห็นพฤติกรรมทั้งสองแบบ ผมบอกได้เลยว่าสิ่งหนึ่งชัดเจน: ไม่ว่าแบบไหนก็ต้องใช้เวลา เมื่อพิจารณาว่าจะอนุญาตให้ committer ที่ยังไม่น่าเชื่อถือส่งการเปลี่ยนแปลงเข้ามาใน codebase ของคุณหรือไม่ คุณต้องตัดสินใจว่า overhead ของการเป็น gatekeeper คุ้มค่ากับความยุ่งยากหรือไม่: core team จะสามารถทำสิ่งที่ดีกว่าด้วยเวลาที่ใช้ไปกับการตรวจสอบ patch ได้หรือไม่?

Maturity (ความเป็นผู้ใหญ่ของเซอร์วิส)

ยิ่งเซอร์วิสหนึ่งมีความเสถียรหรือเป็นผู้ใหญ่น้อยเท่าไร ก็ยิ่งยากที่จะอนุญาตให้คนนอก core team ส่ง patch เข้ามา ก่อนที่โครงสร้างหลักของเซอร์วิสจะลงตัว ทีมอาจยังไม่รู้ว่า "ดี" หน้าตาเป็นอย่างไร จึงอาจลำบากที่จะรู้ว่าการส่งงานที่ดีหน้าตาเป็นอย่างไร ในช่วงนี้ ตัวเซอร์วิสเองก็กำลังเผชิญกับการเปลี่ยนแปลงในระดับสูง

โปรเจกต์โอเพนซอร์สส่วนใหญ่มักไม่รับการส่งงานจากกลุ่ม committer ที่ยังไม่น่าเชื่อถือในวงกว้าง จนกว่าแกนหลักของเวอร์ชันแรกจะเสร็จสมบูรณ์ การทำตามโมเดลคล้ายๆ กันในองค์กรของคุณเองก็สมเหตุสมผล ถ้าเซอร์วิสหนึ่งค่อนข้างเป็นผู้ใหญ่แล้วและแทบไม่เปลี่ยนแปลง—เช่น cart service ของเรา—บางทีนั่นก็อาจเป็นเวลาที่จะเปิดให้คนอื่นเข้ามาช่วยส่งงานได้

Tooling (เครื่องมือ)

เพื่อสนับสนุนโมเดลโอเพนซอร์สภายในองค์กรได้ดีที่สุด คุณจะต้องมีเครื่องมือบางอย่างพร้อมใช้งาน การใช้เครื่องมือ version control แบบกระจาย (distributed) ที่ให้คนส่ง pull request ได้ (หรืออะไรที่คล้ายกัน) เป็นสิ่งสำคัญ ขึ้นอยู่กับขนาดองค์กร คุณอาจต้องการเครื่องมือที่รองรับการพูดคุยและพัฒนาคำขอ patch ด้วย ซึ่งอาจหมายถึงระบบ code review เต็มรูปแบบหรือไม่ก็ได้ แต่ความสามารถในการคอมเมนต์แบบ inline บน patch นั้นมีประโยชน์มาก สุดท้าย คุณต้องทำให้ committer สามารถ build และ deploy ซอฟต์แวร์ของคุณได้ง่ายมาก และทำให้คนอื่นใช้งานได้ ปกติแล้วสิ่งนี้เกี่ยวข้องกับการมี build และ deployment pipeline ที่กำหนดไว้อย่างชัดเจน และ centralized artifact repository ยิ่ง tech stack ของคุณเป็นมาตรฐานมากเท่าไร คนในทีมอื่นก็ยิ่งแก้ไขและส่ง patch ให้ไมโครเซอร์วิสได้ง่ายขึ้นเท่านั้น