7 คะแนน โดย GN⁺ 2025-10-27 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ครั้งหนึ่งโมเดล SaaS เคยโน้มน้าวอุตสาหกรรม IT ด้วยคำสัญญา "จ่ายเท่าที่ใช้ และโฟกัสกับธุรกิจแทนเทคโนโลยี" แต่ในความเป็นจริงกลับกลายพันธุ์เป็นโครงสร้างที่ ผูกลูกค้าไว้ (lock-in)
  • ผู้ให้บริการรายใหญ่ให้ความสำคัญกับ การรักษาการชำระเงินต่อเนื่องและการเก็บข้อมูล มากกว่าความพึงพอใจของลูกค้า และแม้แต่ ‘ผู้จัดการความสำเร็จของลูกค้า’ ก็ยังเป็นเพียง บทบาทเพื่อป้องกันการยกเลิกใช้งาน
  • ทั้งอุตสาหกรรมหลีกเลี่ยงการเปลี่ยนแปลงและนวัตกรรมภายใต้ชื่อของ ‘best practice’ จนสุดท้ายผลิต ระบบนิเวศซอฟต์แวร์ที่เป็นสูตรสำเร็จและธรรมดาเหมือนกันหมด
  • ตลาด SaaS เปลี่ยนไปเป็นโครงสร้างที่ถูกควบคุมและคาดเดาได้มากเกินไปเหมือน ห้างสรรพสินค้าอเมริกันยุค 1980 ที่แพลตฟอร์มขนาดใหญ่ทำหน้าที่เป็นทั้ง เจ้าของพื้นที่และร้านค้า ไปพร้อมกัน
  • ทางออกที่แท้จริงไม่ใช่การใช้ระบบเดียวกันกับทุกคน แต่คือการสร้าง ระบบสารสนเทศที่เหมาะกับองค์กรของตนเอง ซึ่งสามารถทำได้ผ่านแนวทางทางเลือกอย่างการโฮสต์เอง

คำสัญญาและความเป็นจริงของโมเดล SaaS

  • ในช่วงแรก SaaS ชูอุดมคติอย่าง "จ่ายเท่าที่ใช้ (pay as you go)" และ "โฟกัสกับธุรกิจมากกว่าเทคโนโลยี" พร้อมสัญญาว่าจะทำให้การดำเนินงาน IT มีประสิทธิภาพขึ้น
    • ผู้ใช้ถูกโน้มน้าวด้วยข้อความว่า สามารถประหยัดเงินทุนและเวลา และ ลดภาระการจัดการเทคโนโลยีได้
  • แต่ในความเป็นจริง ผู้ให้บริการหลักอย่าง Microsoft, Google และ Intuit กลับพัฒนาไปสู่โครงสร้างที่ให้ความสำคัญกับ การทำให้ลูกค้าต้องพึ่งพา มากกว่าการยึดลูกค้าเป็นศูนย์กลาง
    • แม้จะมีการสำรวจความพึงพอใจหลังทุกปฏิสัมพันธ์กับลูกค้า แต่นั่นก็เป็นเพียงอีกวิธีหนึ่งในการ เก็บ big data
    • ผลสำรวจเป็นเรื่องรอง และสิ่งที่ต้องการจริง ๆ คือ ให้ลูกค้าอยู่ต่อและจ่ายเงินต่อเนื่อง
    • ข้อมูลที่เก็บมาได้ถูกนำไปใช้เพียงเพื่อ การปรับปรุงเล็กน้อยในส่วนปลายทาง เท่านั้น

ความย้อนแย้งของผู้จัดการความสำเร็จของลูกค้า

  • แทบทุกบริษัท SaaS สร้างบทบาท Customer Success Manager ขึ้นมา
  • คนเหล่านี้ถูกมอบหมายให้ดูแลบัญชีเพื่อ ช่วย onboarding และป้องกันการเลิกใช้
  • คำว่า 'ความสำเร็จ' ในที่นี้ไม่ได้หมายถึงความสำเร็จที่แท้จริงขององค์กร แต่หมายถึงการทำให้ ใช้งานผลิตภัณฑ์มากพอ เท่านั้น
  • การสร้างผลิตภัณฑ์ที่ลูกค้ารู้สึกว่ามีประโยชน์ไม่ใช่เรื่องผิด แต่เมื่อเวลาผ่านไป โมเดลธุรกิจ SaaS กลับบิดเบือนไปเป็นโครงสร้างที่ตั้งอยู่บน การยอมจำนน (submission) และ ความเฉื่อย (inertia) ไม่ใช่ความสำเร็จของลูกค้า
  • เมื่อถึงจุดหนึ่ง ฐานลูกค้าและผลิตภัณฑ์จะใหญ่เกินกว่าจะเปลี่ยนแปลงได้

Safety in Numbers - ภาพลวงของความปลอดภัยจากการทำตามคนหมู่มาก

  • หลายบริษัทเลือกใช้ SaaS เพราะจิตวิทยาแบบ "คนอื่นก็ทำกันทั้งหมด" และเพราะ network effect
    • ถ้าทุกคนกำลังทำอยู่ มันก็ดูเหมือนจะดี หรืออย่างน้อยก็เป็น เส้นทางที่แรงต้านต่ำที่สุดและดีพอ
    • network effect มีคุณค่าอยู่จริง แต่ ความปลอดภัยจากจำนวนคนนั้นมีขีดจำกัด
  • จำนวนผู้ใช้จำนวนมากปกปิดความเสี่ยงที่มองไม่เห็น โดยเฉพาะ ความเสี่ยงแบบ black swan
    • ความเสี่ยงที่เกิดไม่บ่อยแต่สร้างหายนะนั้นทั้งหายากและร้ายแรงจนแทบไม่มีใครคิดถึงจริงจัง
  • ระบบสำรองข้อมูล การกู้คืนจากภัยพิบัติ และระบบความต่อเนื่องทางธุรกิจ สามารถ ป้องกันความล้มเหลวของระบบเดี่ยว ได้ แต่ ป้องกันการสูญเสียบริบทและองค์ความรู้ไม่ได้
  • ปัญหาที่แท้จริงไม่ใช่การสูญเสีย แต่คือ การสะสม
    • มีโปรแกรม, API, การเชื่อมต่อ และ ความซับซ้อนเกินจำเป็น มากเกินไปที่ปลอมตัวมาเป็นระบบอันซับซ้อนล้ำสมัย
    • ไม่มีระบบกู้คืนบริบท แต่ องค์กรที่ประสบความสำเร็จนั้น พึ่งพาบริบท ไม่ใช่แค่ข้อมูล
    • ข้อมูลระดับเทราไบต์ไม่มีความหมายเลย หากไม่รู้ว่า เก็บไว้ทำไม มันหมายถึงอะไร และควรใช้มันอย่างไร

กับดักของข้อมูลล้นเกินและการตัดสินใจ

  • ข้อมูลและคอนเทนต์นั้น ไร้ขีดจำกัดและเป็นเชิงความน่าจะเป็น จึงไม่ได้คาดเดาได้เสมอไป
  • ข้อมูลที่มากขึ้นไม่ได้แปลว่าจะนำไปสู่การตัดสินใจที่ดีขึ้น แต่เพียงนำไปสู่ ข้อมูลที่มากขึ้นเท่านั้น
  • สิ่งนี้หล่อเลี้ยง ความกลัวและความเสี่ยงต่อสิ่งที่เราไม่รู้
  • เราไม่มีทางรู้ข้อมูลทั้งหมดก่อนตัดสินใจได้ แต่เมื่อเผชิญกับ สิ่งที่ไม่รู้และความไม่แน่นอน การยึดใช้ 'best practice' ก็ให้ความรู้สึกเหมือนผ้าห่มนิรภัยอันอบอุ่น

Undifferentiated Best Practices — แนวปฏิบัติที่เป็นสูตรเดียวไร้ความแตกต่าง

  • ทั่วทั้งอุตสาหกรรมมีความเชื่อแบบไม่ลืมหูลืมตาต่อเทมเพลต 'best practice'
  • ปัญหาของ best practice คือมัน ตั้งสมมติฐานว่าโลกหยุดเปลี่ยนแปลงแล้ว
    • แต่ในความเป็นจริง โลกไม่ได้หยุดนิ่ง มันเปลี่ยนแปลงต่อเนื่องและต้องการ การปรับปรุงและวิวัฒนาการอย่างสม่ำเสมอ
  • การนำ best practice แบบสำเร็จรูปมาใช้โดยไม่ตั้งคำถาม ไม่ใช่เส้นทางสู่ความเป็นเลิศ แต่เป็น เส้นทางสู่ค่าเฉลี่ยอันแสนธรรมดา
  • ตรรกะว่า "อย่าเสียเวลาประดิษฐ์ล้อขึ้นใหม่" ถูกนำไปใช้ในทางที่ผิด
    • มีการอ้างว่าไม่จำเป็นต้องเสียเวลาและแรงไปกับการแก้ปัญหาที่ถูกแก้ไปแล้ว
  • แต่ในความเป็นจริง มันทำให้เก่งได้แค่ การทำให้เทียบเท่าคู่แข่ง (parity)
  • แนวทางนี้ผลิต ความธรรมดาจืดชืด (bland mediocrity) และทำงานเป็นโครงสร้างที่ขัดขวางความแตกต่างและความก้าวหน้าที่แท้จริง

Bland and Generic Applications — ระบบนิเวศซอฟต์แวร์ที่เป็นสูตรสำเร็จเหมือนกันหมด

  • หากมองไปที่สภาพแวดล้อมของซอฟต์แวร์เชิงพาณิชย์ จะเห็นว่ามีแอปพลิเคชันนับพันในหมวดหมู่นับพัน แต่สุดท้ายก็ยังวนเวียนอยู่กับ แอปจดบันทึกหรือแอปปฏิทิน ในรูปแบบต่าง ๆ
    • บางโปรแกรมอาจสวยกว่า หรือดูใช้งานง่ายกว่า แต่ นิยามของปัญหาและวิธีเข้าหามีความคล้ายกัน
  • เหตุที่ซอฟต์แวร์ยังคง แก้ปัญหาเดิมที่แก้ได้ซ้ำแล้วซ้ำเล่า ก็เพราะโจทย์ที่เหลืออยู่เป็นสิ่งที่ ยากมากจริง ๆ หากจะใช้เทคโนโลยีเข้าไปแก้
    • การสื่อสารและการทำงานร่วมกันเต็มไปด้วย นัยยะและความละเอียดอ่อนที่ไม่ยอมถูกทำให้เป็นดิจิทัล
  • เรื่องนี้ไม่ได้จำกัดอยู่แค่ผู้ให้บริการ SaaS เพราะบริษัทซอฟต์แวร์ส่วนใหญ่ต่างก็ กระโจนขึ้นขบวน SaaS เพื่อการตลาดและการขายผลิตภัณฑ์
    • มี เวอร์ชันฟรี ที่ให้ฟีเจอร์มาเพียงพอให้ล่อเข้าสู่การสมัครสมาชิกแบบเสียเงิน
    • จากนั้นผู้ใช้ก็ต้องเจอกับ ตัวเลือกสมัครสมาชิกมาตรฐาน 3 ระดับ แบบ good, better, best
  • การเพิ่มเครื่องมือสื่อสารไม่ได้ทำให้ คุณภาพของการสื่อสารดีขึ้น มีแต่ทำให้ปริมาณการสื่อสารเพิ่มขึ้นอย่างมาก จนเกิด สัญญาณรบกวนและความเหนื่อยล้า

Let’s Go to the Mall — ความคล้ายกันระหว่าง SaaS กับห้างสรรพสินค้ายุค 1980

  • SaaS ได้กลายเป็นเทคโนโลยีแบบเดียวกับ ห้างสรรพสินค้าอเมริกันยุค 1980
    • ราคาแพงเกินจริง คาดเดาได้ และในทุกห้างก็มี สินค้าที่แทบไม่ต่างกัน
  • นี่ไม่ใช่ตลาดที่มีพลวัต แต่เป็น ตลาดที่ถูกควบคุมอย่างหนัก
    • เจ้าของพื้นที่เป็นคนตั้งแพลตฟอร์ม แล้วผู้ค้าปลีกก็แห่กันเข้ามายังทำเลทองนี้เพื่อคว้า กำไรมหาศาลและข้อได้เปรียบจากขนาด
    • ผู้ค้าปลีกที่สามารถจ่ายค่าเช่าในห้างได้ก็จะมอบ ประสบการณ์ที่ถูกควบคุมอย่างมาก
  • ห้างสรรพสินค้ายุค 1980 ไม่ใช่สถานที่ของการทดลองที่กล้าหาญหรือการรับความเสี่ยง โดยความเสี่ยงอยู่ที่การเซ็นสัญญาเช่าเท่านั้น
  • Google และ Microsoft เป็นทั้งร้านค้าในห้างและเป็น เจ้าของพื้นที่ที่ควบคุมประสบการณ์ของห้าง ไปพร้อมกัน
  • Apple ดำเนินการห้างของตัวเอง ซึ่ง ดูเงางามกว่า แต่ไม่ได้ต่างออกไป
    • ทุกวันนี้ห้างจริง ๆ หลายแห่งคงกลายเป็นเมืองร้าง ถ้าไม่มี Apple Store ช่วยดึงทราฟฟิกเข้าไป
  • ณ จุดหนึ่ง วัฒนธรรมก็ เริ่มเหนื่อยล้ากับประสบการณ์แบบห้าง และทั่วอเมริกาจึงเต็มไปด้วย ห้างร้าง
    • โมเดลนี้ใช้ได้ถึงระดับหนึ่ง แต่ กระแสนิยมย่อมเปลี่ยนไป
  • จากนั้น ร้านเล็ก ๆ ที่คัดสรรสินค้ามาอย่างตั้งใจจึงเริ่มเกิดขึ้นและดึงดูดผู้คนได้
  • อนาคตของเทคโนโลยีสารสนเทศก็ น่าจะคล้ายกันมาก
    • สิ่งสำคัญไม่ใช่การมีระบบเดียวกับที่คนอื่นมี
    • สิ่งสำคัญคือการมี ระบบสารสนเทศที่เหมาะกับตัวคุณเอง

1 ความคิดเห็น

 
GN⁺ 2025-10-27
ความเห็นจาก Hacker News
  • พูดถึงปรากฏการณ์ที่ผู้บริโภคไม่อยากจ่าย “ราคาที่แท้จริง” ของซอฟต์แวร์ เช่นเดียวกับที่ไม่อยากจ่ายราคาจริงของอาหารหรือเสื้อผ้า
    แต่ก่อนเคยซื้อเครื่องมืออย่าง Postman ได้ครั้งเดียวในราคา $40 แต่ตอนนี้กลายเป็นโครงสร้างแบบสมัครสมาชิกที่ต้องจ่าย $30/เดือน
    SaaS มีข้อดีคือช่วยให้ใช้งานเวอร์ชันล่าสุดได้ตลอดเวลา
    แต่การพัฒนาซอฟต์แวร์นั้นโดยเนื้อแท้แล้วเป็นงานที่ มีต้นทุนทางเศรษฐกิจสูง และมูลค่าของมันถูกประเมินต่ำเกินไปเพราะอาศัยแรงงานที่ไม่ได้รับค่าตอบแทนจากผู้มีส่วนร่วมโอเพนซอร์ส

    • มีการโต้แย้งว่า “ถ้าเวอร์ชัน 4 ก็เพียงพอแล้ว จะอัปเกรดต่อไปทำไม”
      รู้สึกว่าแม้ตลอด 20 ปีที่ผ่านมา จะมีซอฟต์แวร์จำนวนมหาศาลถูกสร้างขึ้น แต่กลับแทบไม่มี นวัตกรรมที่เป็นจุดเปลี่ยน เกิดขึ้น
      ชี้ให้เห็นว่าคอมพิวเตอร์แรงขึ้น 10~20 เท่า แต่ซอฟต์แวร์กลับช้าลงและซับซ้อนขึ้น
    • เน้นว่าซอฟต์แวร์ไม่ใช่ ปัจจัยจำเป็นต่อการดำรงชีวิต เหมือนอาหาร
      วิจารณ์ว่าซอฟต์แวร์ทุกวันนี้มักถูกยัดเยียดให้ผู้บริโภค และทำหน้าที่เป็น ม้าโทรจัน สำหรับเก็บข้อมูลและสอดส่อง
      ผู้บริโภคยอมจ่ายเงินให้กับอาหาร น้ำ และที่อยู่อาศัย แต่ไม่อยากจ่ายให้ซอฟต์แวร์
    • อ้างว่า Postman ราคาแพงไม่ใช่เพราะต้นทุนการพัฒนา แต่เป็นเพราะ โครงสร้างการคืนทุนให้ VC
      ถ้าเป็นการลงทุนและทีมในขนาดที่สมเหตุสมผล ก็คงไม่จำเป็นต้องคิดค่าบริการระดับ Adobe สำหรับแค่ curl GUI
    • เตือนความจำว่าซอฟต์แวร์แบบแพ็กเกจในอดีตมี ส่วนลดอัปเกรด และยังขายต่อมือสองได้
      พร้อมชี้ว่า SaaS ก็ไม่ได้ทำให้ผู้มีส่วนร่วมโอเพนซอร์สได้รับค่าตอบแทนมากขึ้น
    • ปัญหาของ Postman ไม่ได้มีแค่เรื่องปากท้องของนักพัฒนา แต่คือการที่ผลิตภัณฑ์ค่อย ๆ ซับซ้อนขึ้นและสูญเสียความเรียบง่ายดั้งเดิมไปเพื่อ เพิ่มรายได้ของบริษัทให้สูงสุด
      ผู้แสดงความคิดเห็นบอกว่าบริษัทก็ย้ายผ่านไคลเอนต์มาหลายตัวแล้ว และ Postman ก็กำลังเดินไปตามเส้นทางเดียวกัน
  • อยากให้โพสต์แนวตื่นตูมว่า “AWS ล่มแล้ว” หายไป และกลับไปสู่ การถกเถียงอย่างปกติ
    ย้อนความว่าก่อนหน้านี้ก็สามารถรันระบบด้วยเซิร์ฟเวอร์ on-premises ได้ดีพอ และมีประสิทธิภาพกว่าปัจจุบันมาก
    ตอนนี้แม้แต่นักพัฒนาก็ต้องเข้าใจ AWS และต้องกังวลทั้ง ความเสี่ยงด้านความปลอดภัย และการรั่วไหลของความรู้ผ่าน LLM
    รู้สึกว่าความก้าวหน้าทางเทคโนโลยีกลับสร้าง สภาพแวดล้อมการพัฒนาแบบดิสโทเปีย และทำให้นึกถึง UX ที่เรียบง่ายและเข้าใจได้ทันที

  • มีความเห็นว่าบริษัทส่วนใหญ่ใช้ SaaS ที่ดีพอ สำหรับอีเมล ปฏิทิน VPN CRM ฯลฯ เป็นทางเลือกที่สมเหตุสมผล
    รู้สึกว่าเครื่องมืออย่าง Google Workspace, HubSpot หรือ Power BI ดีกว่าผลิตภัณฑ์ออฟไลน์ในอดีตมาก

    • แต่ก็มีคนโต้ว่า การต้องจ่าย ค่าเช่าต่อผู้ใช้ ให้กับซอฟต์แวร์ออฟฟิศที่เสร็จสมบูรณ์มาตั้งแต่ 30 ปีก่อนนั้นไม่ยุติธรรม
    • แชร์ประสบการณ์ส่วนตัวว่าแอปมือถือของ HubSpot มีบั๊กเยอะและใช้งานลำบาก
      แม้จะเข้าใจว่าการยัดข้อมูลจำนวนมากลงบนหน้าจอเล็กเป็นเรื่องยาก แต่ก็ยังรู้สึกว่ามันใช้งานได้ไม่ลื่นไหล
  • วิจารณ์โครงสร้างของ SaaS ที่ จับฟีเจอร์ความปลอดภัยมาแบ่งขายเป็นชั้น ๆ ราวกับจับเป็นตัวประกัน

    • ยกตัวอย่าง “SSO (Single Sign-On)” พร้อมบอกว่าการล็อกอินทั่วไปก็ปลอดภัยเพียงพอได้
      การโดนฟิชชิงเป็นปัญหาของบริษัท ไม่ใช่ความรับผิดชอบของผู้ขาย
  • หยิบยกประเด็น “การละเมิดลิขสิทธิ์ (piracy)” ซึ่งเป็นเรื่องที่ขาดไม่ได้ในการคุยเรื่อง SaaS

    • อธิบายว่า SaaS ทำให้บริษัทควบคุมผู้ใช้ได้อย่างสมบูรณ์ และช่วยให้ขยายการใช้งานจากระดับบุคคล → ทีม → องค์กรได้อย่างเป็นธรรมชาติ เหมือน กลยุทธ์การแพร่กระจายของ Salesforce
      การที่ไม่ต้องติดตั้งทำให้การนำไปใช้เกิดขึ้นได้ง่าย
    • อย่างน่าขัน โลกแบบที่ผู้สนับสนุน FOSS เคยพูดถึงว่า “หารายได้จากสัญญาบริการ” ได้กลายเป็นความจริง แต่ผลลัพธ์กลับเป็น สภาพแวดล้อมที่ปิดมากขึ้น
    • แชร์ประสบการณ์ว่าเคยทำระบบในสตาร์ตอัปแห่งหนึ่ง แล้วถูกบริษัท SaaS จีน คัดลอกไปทั้งซอร์สโค้ด
      พร้อมเสริมว่าการขโมยทรัพย์สินทางปัญญาเป็นเรื่องที่พบได้บ่อย แต่ท้ายที่สุดข้อมูลก็มี ธรรมชาติที่อยากเป็นอิสระ
    • วิเคราะห์ว่าในสภาพแวดล้อมองค์กร แทบไม่มีการละเมิดลิขสิทธิ์อยู่แล้ว ดังนั้น SaaS ไม่ได้ถูกสร้างขึ้นมาเพื่อแก้ปัญหานี้
    • กล่าวว่าระหว่างอ่าน 《Fundamentals of Data Engineering》 ก็เพิ่งตระหนักว่า เว็บสแครปปิงคือรูปแบบ “การคัดลอก” แบบใหม่ในยุค SaaS
  • อธิบายว่า SaaS เองไม่ใช่แนวคิดที่แย่ และถ้าเป็นโครงสร้างแบบ จ่ายเท่าที่ใช้จริง ก็ถือว่าสมเหตุสมผล
    ปัญหาคือโมเดลสมัครสมาชิกที่มากเกินพอดี และการที่ vendor lock-in ทำให้ย้ายข้อมูลไม่ได้
    เหมือนกับ กลยุทธ์ “moat” ของ AWS ที่ทำให้ผู้ใช้หนีออกไม่ได้เพราะการพึ่งพาที่ตัวเองสร้างขึ้น
    จึงแนะนำว่าอย่าพึ่งพา SaaS กับฟังก์ชันหลักของระบบ

    • วิจารณ์อย่างหนักว่า AWS Amplify คือ ตัวอย่าง lock-in ที่แย่ที่สุด
  • มีคนชี้ว่าการพูดถึงแต่ด้านลบของ SaaS เพียงอย่างเดียวเป็นมุมมองที่ไม่สมดุล
    B2B SaaS สามารถให้ประโยชน์มหาศาลกับลูกค้าได้ ตราบใดที่ยังมีการแข่งขันอยู่
    ผู้ขายมีแรงจูงใจที่จะปรับปรุงผลิตภัณฑ์อย่างต่อเนื่องและเพิ่มฟีเจอร์ใหม่ให้ฟรี เพื่อป้องกัน การเลิกใช้ (churn)
    ในทางกลับกัน ซอฟต์แวร์ on-premises รุ่นเก่า ๆ มักมีสัญญาบำรุงรักษาที่แพงและคุณภาพต่ำ
    ท้ายที่สุดแล้ว ผู้ซื้อก็ต้อง เลือกจุดประนีประนอม

  • มีความเห็นว่าผลิตภัณฑ์อย่าง Photoshop หรือ AutoCAD ถ้ามี ตัวเลือกสมัครสมาชิกระยะสั้น ก็น่าจะมีประโยชน์กับฟรีแลนซ์
    แต่ในความเป็นจริง การเปิด ๆ ปิด ๆ การสมัครสมาชิกอย่างอิสระทำได้ยาก

    • แชร์ว่าซื้อ Photoshop 6.0 เวอร์ชันปี 2000 มาใช้บนพีซีสมัยใหม่ และมัน ทำงานได้สมบูรณ์แบบโดยไม่มี DRM
      พร้อมย้ำว่าซื้อครั้งเดียวก็เพียงพอแล้ว
  • วิเคราะห์ว่าต้นตอของ lock-in ใน SaaS มาจากการรวมกันของสององค์ประกอบ

    1. อินเทอร์เฟซแบบประกาศเจตนาและมีเสถียรภาพ, 2) การสนับสนุนจากทีมปฏิบัติการมืออาชีพ
      จึงเสนอว่าควรแยกสองสิ่งนี้ออกจากกัน (unbundle) และอธิบายว่าอย่างแรกนั้น Nix อาจเป็นทางออกได้แล้ว
      โจทย์ที่เหลือคือการสร้าง โมเดลธุรกิจด้านซัพพอร์ตบนฐานการโฮสต์เอง
      เชื่อว่าแก้ได้ในทางเทคนิค แต่ยังไม่เคยมีใครทำสำเร็จจริง