ตามอ่านบล็อกของ Jeff Walcot ที่ Acquia (Confessions of a Drupal Convert) ไปยังบทความของ Kurt Cagle บน O’Reilly (Drupal as Open Architecture) แล้วน่าสนใจมาก

Cagle อ้างสไลด์ของ Roy Fielding ที่งาน OSCON 2008 (Open Architectures at REST (PDF))

Fielding เป็นคนคิดคำว่า REST โดยพัฒนาแนวคิดนี้ลงในวิทยานิพนธ์ปริญญาเอกของเขา ในสไลด์อันนี้ Fielding กำลังไปพัฒนาโครงการ Apache Sling สไลด์อันนี้จึงเป็นการโฆษณา Sling เป็นหลัก

แต่จุดน่าสนใจอยู่ในครึ่งแรกของสไลด์ ซึ่งเป็นแนวคิดที่ Fielding นำมาเป็นโมเดลให้กับสถาปัตยกรรมของ Sling นั่นคือแนวคิด Open Architecture ซึ่งในที่นี้มีความหมายในเชิง software engineering

ในทางทฤษฎีนั้น Fielding พูดถึง Conway Law และหลักด้าน software engineering อื่นๆ ด้วย ผมยังอ่านไม่แตกฉานนักขอข้ามไปยังหลักการสำเร็จของ Open Architecture ที่ Fielding อ้างงานของคนอื่นมาอีกต่อหนึ่ง

หลักพื้นฐานของ Open Architecture (เสนอโดย Peyman Oreizy)

1. เปิดสถาปัตยกรรมของซอฟต์แวร์ให้กับคนทั่วไปได้เห็น
2. เปิดโอกาสให้ third party สามารถเปลี่ยนแปลงตัวซอฟต์แวร์ โดยแก้ที่ตัวสถาปัตยกรรมได้ (เช่น ผ่านระบบ Adds-on)
3. การเปลี่ยนแปลงที่เข้าท่า จะถูกดึงกลับมารวมกับตัวสถาปัตยกรรมหลักในรุ่นหน้าๆ (เป็นเรื่องของ change management ไป)

Peyman ยกตัวอย่างจริงแบบ closed source คือ ระบบปลั๊กอินของ Photoshop และโปรแกรมต่างๆ ของ Adobe ส่วนอีกอันคือ iPhone ecosystem

ส่วนตัวอย่างที่เป็นโอเพนซอร์สนั้นมีเยอะมาก และเรียกได้ว่าโครงการโอเพนซอร์สใหญ่ๆ มาแนวทางนี้กันหมด ไม่ว่าจะเป็น

• Emacs (สร้างปลั๊กอินด้วยสคริปต์ elisp)
• Apache (modules)
• Kernel (modules + API)
• Firefox (plugins + extentions)
• Eclipse (plugins)

โครงการอื่นๆ ผมรู้ไม่ละเอียดนัก แต่ของ Firefox มี extension หลายตัวที่ถูกรวมเข้าไปใน Firefox ตัวหลัก ที่นึกออกตอนนี้ก็มี tab กับ session saver

กลับมาที่บทความของ Kurt Cagle ใจความหลักคือเขาบอกว่า Drupal นั้นก็เข้าระบบ Open Architecture นี้ด้วย อันนี้ไม่น่าแปลกใจนักเพราะโครงการอื่นๆ มันก็เป็น

แต่จุดที่คิดว่าน่าสนใจคือ Cagle บอกว่าการแบ่งรุ่นของ Drupal และโมดูลที่อัพเดตไม่พร้อมกันในแต่ละรุ่น (ซึ่งผู้ใช้อย่างเรามองว่าเป็นปัญหา) นั้นเป็นเรื่องธรรมชาติ และเป็นใจความสำคัญของหลัก “agile development” ซึ่งไม่มี development branch/phase ที่แท้จริง ทุก branch ถือว่าเป็น development branch หมด แค่ว่าเป็นอันเล็กอันใหญ่เท่านั้น

ปัจจุบัน ณ​ เวลาที่เขียน โมดูลหรือ ecosystem ของ Drupal มี 4 branch คือ

• 4.x - เริ่มหยุดพัฒนาแล้ว
• 5.x - ยังพัฒนาอย่างแข็งขัน
• 6.x - กำลังเริ่มจุดติด มีโมดูลใหม่ๆ มากขึ้น
• 7.x - กำลังเริ่มทดสอบ

Cagle บอกว่าแต่ละ branch ไม่จำเป็นต้องมีโมดูลที่เหมือนกัน และโมดูลมีลักษณะที่ติดตามไปกับ branch (ซึ่งมันสามารถอธิบายได้ว่าทำไมเรายังไม่เห็นโมดูลหลายๆ ตัวใน 5.x อัพเกรดไปเป็น 6.x เสียที) และมีโอกาสสูงกว่าที่จะเห็นโมดูลใหม่สำหรับ branch ใหม่ ซึ่งทำหน้าที่แบบเดียวกับโมดูลเดิมใน branch เก่า แต่มาจากนักพัฒนาคนละทีมกัน

ที่น่าสนใจคือ Cagle มองว่า CMS มีลักษณะพิเศษที่ต่างออกไปจากซอฟต์แวร์แบบอื่นๆ เพราะการสร้างเว็บไซต์นั้นไม่จำเป็นต้องอัพเกรดข้าม branch (เช่น จาก Drupal 5.x ไปเป็น 6.x) ถ้าเว็บไซต์นั้นอยู่ตัวแล้ว ขอเพียงว่าตามอัพเดตเล็กภายใน branch เดียวกันก็พอ

ผมยังงงๆ กับเหตุผลของ Cagle เล็กน้อย เขาบอกว่าปรากฎการณ์นี้เกิดขึ้นได้เพราะ Drupal พัฒนามาถึงจุดที่สามารถนำไปสร้างเว็บไซต์แบบซับซ้อนโดยไม่ต้องเขียนโค้ดแล้ว ตรงนี้ไม่เก็ตนักว่าเขียนโค้ดกับไม่เขียนโค้ดนั้นต่างกันอย่างไร

ในย่อหน้าท้ายๆ Cagle พูดถึงจุดด้อยของโมเดล Open Architecture ที่ปล่อยให้ความสร้างสรรค์เกิดจากชุมชนว่า ระดับคุณภาพของโมดูลภายนอกอาจไม่ดีนัก (เช่น ไม่อัพเดต กินแรมเยอะ มีปัญหาความปลอดภัย​ ฯลฯ) แต่ถ้าให้พิจารณาระหว่าง optimized dedicated code (efficiency) กับ modular community code (general flexibility) แล้ว อย่างหลังจะชนะในระยะยาว เพราะว่า computing resource มีราคาถูกมาก และมีแนวโน้มถูกลงเรื่อยๆ

Drupal เองก็มีลักษณะของ Open Architecture เช่นกัน ตัวอย่างคือ CCK เข้าไปใน 6.x ครึ่งนึงแล้ว ส่วน Views ก็เป็นหนึ่งในฟีเจอร์ยอดนิยมที่คนต้องการใน Drupal 7.x

สุดท้าย Cagle ยกตัวอย่าง Open Architecture แบบย้อนกลับ คือ แทนที่โมดูลภายนอกจะเข้าไปรวมกับ core แบบโครงการทั่วไป ถ้าโมดูลภายนอกนั้นมีความสำคัญและมีชุมชนนักพัฒนามากๆ เราอาจเห็นปรากฎการณ์ที่ core แยกตัว (fork หรือ spin off) ออกมา และปรับตัวให้เข้ากับความต้องการของโมดูลเหล่านั้นได้เช่นกัน ตัวอย่างคือ Songbird และ Flock ที่ดึงเอา Firefox core (XULRunner) ออกมาทำเอง

ช่วงหลังผมเชื่อในแนวทางของการสร้าง ecosystem เพื่อความยั่งยืนในการพัฒนา เผอิญความรู้ด้าน software engineering มีน้อย มาเจอบทความนี้เลยตื่นเต้นเป็นพิเศษ

ป.ล. Cagle ยังพูดถึงระบบ URL ของ Drupal ที่ไปเข้ากับแนวคิดของ REST อีก แต่คิดว่านอกประเด็นไปคงไม่ขอพูดถึง