Interview with the Dolphin

วันเดียวกับที่เล่าเรื่องเนคเทค มีรุ่นพี่ท่านหนึ่งในวงการ OpenSource แวะมาคุยด้วย
ว่าทำอย่างไร OpenSource ถึงจะได้รับการยอมรับในองค์กรใหญ่ๆ เช่น องค์กรรัฐ
เพราะ พอเป็นหน่วยงานรัฐ ก็จะเจอคำพูดทำนอง "ไปซื้อ Enterprise Software มาดีกว่า"
...

นอกจากนี้ คุณพี่ยังกรุณา เอางานวิจัย จากสองมหาลัยมาให้ผมอ่าน
ทั้งสองงาน วิจัยไปสองเรื่อง แต่สรุปออกมาว่า อย่าใช้เลย OpenSource
ซื้อ Package เอาเหอะ ...

เอาล่ะ ก่อนจะอ่านบรรทัดต่อไป ขอให้ท่านผู้อ่านหลับตาพิจารณาก่อน
ว่าไอ้ที่อยู่ข้างบ้านโน่น มีอะไรผิดๆ แปลกๆ อยู่สักอย่าง มันคืออะไร ?


.
.
.
.
.
.
.
.

ว่ากันต่อเลยละกัน

ท้าวความเรื่องที่สอง ...

เมื่อชาติปางก่อน นานมากแล้ว จำวันเวลาที่แน่นอนไม่ได้
ได้นั่งคุยกับเพื่อนสมัยประถมที่ตอนนี้รับงานทำซอฟแวร์ ให้องค์กร ขนาดเล็ก
คุยกันเรื่องต้นทุน การบริหารงาน และการพัฒนาระบบ

ท่อนหนึ่งที่เพื่อนเล่าให้ฟังคือ

" ... เห้ย ไม่มีอะไรมาก งานก็ไม่ยาก ลูกค้าอยากได้อะไร ก็ไป search จากเนทเอา
แล้วเอามา config ติดตั้งให้เขา แล้วเก็บค่าบริการไปเรื่อยๆ ต้นทุนก็ต่ำ"

ฟังดูก็เหมือนการนำ OpenSource ไปใช้ในงานทั่วไปแต่มันต้องมีอะไรผิดแน่ๆ อ่านแล้ว
มันทะแม่งๆ ใช่ไหมครับ

เชิญหลับตานึกว่ามันผิดยังไง อีกรอบครับ  ลืมตามาคราวหน้า ตาผมแล้ว



..
.
.
.
.
.


โอเค จะบ่นล่ะนะ

OpenSource มันจะประสบปัญหาไม่ได้รับการยอมรับอยู่เสมอๆ ขนาดภาษาที่ไม่คุ้นเคย
ยังมีปัญหาในการ introduce แม้แต่ธนาคารที่ผมทำงานอยู่ กว่าจะเข็น Python เข้าไปใช้ได้ นี่รากเลือดเลยทีเดียว

เรื่องที่ผมเล่าสองเรื่องข้างต้น ดูเหมือนไม่เกี่ยวกัน แต่จริงๆแล้ว
ต้นตอของการไม่ได้รับการยอมรับ จริงๆ มาจากคนอย่างเพื่อนผมนี่เอง

คือ OpenSource มันมีเหลือบไรเกาะกินอยู่มากเกินไปครับ
และมันนำไปสู่ความเข้าใจผิดว่า OpenSource นั้นไม่มีทางสนอง need ของ
องค์กรระดับใหญ่ๆได้ ทำให้ผู้ใหญ่เข้าใจผิดหนักเข้าไปใหญ่
ว่าถ้าจะทำ software ขนาด enterprise ยังไงก็ต้องซื้อ package
เพราะ OpenSource ไม่ได้ตอบโจทย์

จริงๆแล้ว OpenSource ไม่ได้หมายถึงซอฟแวร์ขนาดเล็กเลย
จะทำซอฟแวร์ใหญ่ๆ ก็ได้ เพราะ OpenSource ไม่เคยกำหนดขนาดของซอฟแวร์ซะหน่อย
แต่ถ้าถามผมในวันนี้ ผมก็ว่า OpenSource ก็ยังไม่พร้อมจะตอบโจทย์อยู่ดี

สาเหตุ ?

ก็ดูที่เพื่อนผมพูดออกมาสิครับ
เอา OpenSource ไป config หาเงินใช้
แล้ว contribute อะไรกลับมาบ้าง ? อย่างน้อยที่สุดก็ควรจะ
contribute กลับมาว่า เอาไปทำอะไร พบปัญหาอะไรบ้าง และ พัฒนาส่วนไหน
เพื่อตอบโจทย์อะไร เพื่อให้มีองค์ความรู้แบบ บูรณาการ

ลองคิดดูถ้าใครๆ ก็ทำแบบ เพื่อนผม องค์ความรู้ ต่างๆ ก็เจอทางตัน
module ที่เป็น opensource มันก็กองอยู่ที่เดิม ใครคิดว่าหยิบอะไรไปประกอบกันได้ ก็ทำ
ประกอบเสร็จก็เงียบ ไอ้คนมาทีหลัง ก็คลำ ต่อ หยิบโน่นหยิบนี่ไปประกอบต่อ แล้วก็กองทิ้งไว้
ชาติไหนมันจะพัฒนา ถ้าเจอแต่คนแบบนี้

แต่มันก็เป็นเรื่องปกติ เพราะมนุษย์มันเห็นแก่ตัวอยู่แล้ว
แล้วเราจะทำอย่างไร เพื่อขับเคลื่อนสังคมที่มีคนเห็นแก่ตัว ไปสู่เป้าหมายของเรา
เป้าหมายที่ OpenSource สามารถตอบโจทย์องค์กรใหญ่ๆได้ และเป็นที่ยอมรับ

... พักไว้ตรงนี้ก่อน ผมมีเรื่องจะเล่าให้ฟัง คั่นเวลา ...



วันนี้ผมจะเล่าส่วนหนึ่งของ ระบบ baht-net ให้ฟัง
ระบบนี้ เป็นระบบที่ธนาคารต่างๆ ใช้เคลียร์เงินกันผ่านธนาคารแห่งประเทศไทย
เอาในแง่ logic นะ มันจะมีอะไรได้นักหนา ก็แค่ว่า ...

สมมติ วันนี้ กสิกร ต้องจ่าย แบงค์กรุงเทพ หมื่นล้าน
กรุงเทพ จ่าย กสิกร หมื่นสองพันล้าน

งั้นเบ็ดเสร็จ ก็เอาเงิน กรุงเทพ ให้กสิกร สองพันล้าน

โหย โคตรง่าย ให้เด็ก ม.6 เขียนก็ได้มั้ง โปรแกรมแบบนี้
รันด้วย notebook ที่บ้านก็พอหนิ

ถ้าเอาแค่ logic ที่ว่ามันก็ได้แหละครับ แต่คำถามคือ
คุณจะพิสูจน์ได้ยังไงว่า ไอ้ offset สองพันล้านนั่น คำนวนมาถูก
และที่ตัวเลขเยอะๆ transaction ย่อย มากๆ รายละเอียดปลีกย่อย บางอย่าง
จะสร้าง error ขึ้นได้ การเคลียร์เรื่อง precision  นั้นต้องทำโดยคิดเสมอว่า
ไอ้บรรทัดก่อนหน้าเรา มันเขียนมาผิด เราจะล้าง error นั้นอย่างไร

และนอกจากนี้ การ gaurantee delivery ของข้อมูลที่ส่งไปมาในระบบ
คุณจะควบคุมอย่างไร

ถ้าระบบล่ม จะเชื่อได้ยังไงว่า restart กลับมา ข้อมูลไม่หาย
และทำงานต่อจากเดิมได้ทันที

บลาๆๆ อื่นๆอีกมากมาย

เหล่านี้ต่างหากที่ทำให้มันใหญ่ และ หนา หนัก จนต้องใช้เครื่อง server โตๆ ทำการประมวลผล

ทีนี้ ถ้าสมมติวันนึง แบงค์ชาติ บอกว่า "เอาล่ะ โละระบบ แล้วซื้อใหม่กันเถอะ"
แน่นอน ว่าเหล่ามนุษย์ OpenSource ก็จะเห็นว่า ระบบแบบนี้ เราก็ให้บริการได้
จะให้ประเทศชาติเสียเงินมหาศาลไปซื้อ package มาทำไม
แน่นอนครับ ท่านคงนึกออก ถ้าสมมติว่าปล่อยให้ชาว OpenSource เข้าไปทำ
โอกาสสำเร็จมันก็มี แต่ต้องอยู่บนพื้นฐานว่าคนที่เข้าไป พัฒนานั้น ต้องมีความรู้
เกี่ยวกับสิ่งที่ต้องคำนึงถึงทั้งหมด อย่างที่ผม บลาๆๆ อยู่ข้างบน

แล้วผมถามหน่อยว่า ... มีไหม ? องค์ความรู้ ที่รวมรวมไว้ในโลก OpenSource
ว่าถ้าจะ implement ระบบด้านการเงิน มันต้องคำนึงถึงอะไรบ้าง ?
พอเจอโจทย์นี้ เราก็จะเริ่มถาม อาจารย์กู้ (google)
ก็จะเริ่มเจอ IFX ( financial xml standard แบบนึง)
เจอ 8583 (ATM message) และเจออื่นๆอีกมากมาย อ่านไปก็มึนไป
กว่าจะรวมรวมข้อมูล พร้อมจะลงมือพัฒนา เขาก็ซื้อ package ต่างชาติไปแล้วเรียบร้อย ...

หมดนี่ เริ่มจาก มีคนแบบเพื่อนผมข้างบนโน่นอยู่เยอะนี่เอง แค่นี้จริงๆ

.....

กลับมาเรื่อง OpenSource

ทางแก้ ?

เรามีทั้ง SIPA และ Nectec อยู่ กลัวอะไร
ก็สร้างโครงการในการ บูรณาการความรู้ของ OpenSource สิครับ

ผมถามว่า gaurantee message delivery ทำไมจะไม่มีใน OpenSource
ระบบ multi processing , grid , clustering ที่จะทำให้ระบบ scalable ก็มีหมด
การล้าง precision ในการคำนวนต่างๆ ก็มีคนทำไว้แล้วทั้งนั้น

จากที่มีหมดนี่ เราเริ่มจาก หยุดครับ
หยุดทำสงครามกับ software package ครับ
เราต้องหยุดยิงกันซะที แล้วหาทางอยู่ร่วมกันครับ

หรือใครคิดว่าวันนี้เราพัฒนาระบบไปแทน SAP ได้ครับ ณ วันนี้ ไม่มีทางจริงๆ
แต่ในทางกลับกัน บริษัทที่ขาย SAP คิดว่าจะพัฒนาระบบต่อขยายเพื่อเชื่อมงานต่างๆ
หรือให้บริการที่ sophicicate ได้ในราคาต่ำ และเวลาสั้น ได้ยังไง

เราเริ่มจากตรงนี้ก่อน  

ในฐานะที่ปรึกษา หรือ คนพัฒนาก็ตาม
ถ้าคุณเจอธนาคาร ที่ต้อง ประมวลผลไฟล์การเงินให้ลูกค้า เพื่อทำ settlement หรือ clearing ให้
แต่ลูกค้าของธนาคารใช้ SAP ...
คุณจะ

1> บอกให้ ลูกค้าเลิกใช้ SAP ?

2> บอกธนาคารให้ไปซื้อ SAP มา 1 ชุด เพื่อจะได้เชื่อมข้อมูลมา และเขียน อาบับ คำนวน ?

หรือคุณจะบอกว่า

3> ก็เอา open source module สำหรับเชื่อม RFC ของ SAP มาพัฒนา เป็น connector แล้วไปดึงข้อมูลมา
จะได้ประมวลผลต่อด้วยระบบอื่นของธนาคาร

จากตรงนี้ เราก็จะได้องค์ความรู้เกื่ยวกับการรับส่งข้อมูลกับ SAP module
และจากโครงการ เราก็จะเห็น business logic ใน SAP
และในขณะเดียวกัน เราก็จะเรียนรู้การออกแบบ ระบบรับส่ง message ที่ดี
ส่งแล้ว ข้อมูลไม่หาย เกิด error ระหว่างส่ง ก็ทำ correction ได้

หากมีการรวบรวมที่ดี เราก็จะเริ่มสร้าง module ที่ลุกลามไปทดแทนได้ลึกขึ้นเรื่อยๆ
จนวันนึงเราจะมีระบบ enterprise software ที่เป็น opensource ก็ได้

แน่นอนว่า ไอ้เรื่องพรรค์นี้ มันต้องมีหัวเรือใหญ่
SIPA กับ Nectec ก็รับไปทำหน่อยละกันนะครับ

ตั้งหัวเรือไป จะในโลก financial หรือ embeded system หรือ HR
อะไรก็ได้ ไปกันให้สุดโลกไปเลย แล้วรวบรวมองค์ความรู้ระหว่างพัฒนาโครงการ
สร้างเป็น ฐานข้อมูล ที่มันใช้งานได้หน่อย เริ่มจาก การเชื่อมต่อกับระบบ package แพงๆต่างๆ
ก่อนเมื่อได้ความรู้ ในการเชื่อมต่อ ก็ค่อยเริ่มดู business logic ของระบบนั้นๆ
แล้วค่อยๆ พัฒนาทดแทนเข้าไป จนกว่าจะได้ระบบเต็มใบออกมา

โครงการแรก อาจจะไม่รุ่งเท่าไหร่ แต่ก็ขอให้ทำต่อไป อีกสัก สองสาม โครงการ
อย่าเพิ่งหยุด ความสำเร็จเป็นกระบวนการไม่ใช่เหตุการณ์

เด็กมาอายุสามขวบ ก็ไม่เห็นมีประโยชน์อะไรหนิครับ แต่ถ้าเราให้โอกาสเขาเติบโต
เขาก็ทาสีบ้านได้ เขียนโปรแกรมได้ เป็นนักบินอวกาศได้ แล้วแต่โอกาสที่เราให้เขา

การยอมรับนั้นมันต้องใช้เวลา ระหว่างนี้ เราก็ค่อยๆเชื่อม ค่อยๆทำไป

แต่ก่อนอื่น เราต้องหยุดยิงกันก่อนครับ แล้วเริ่มยอมรับปรองดองกัน

เลิกพยายาม convert อีกฝ่าย แต่หาทางทำระบบให้อยู่ร่วมกันก่อน
เมื่อ OpenSource เริ่มมีที่อยู่ในระบบใหญ่ๆแล้ว จะค่อยๆลามไปให้บริการส่วนอื่นๆต่อไป
ย่อมดีกว่า พยายามให้เขาสร้างระบบใหญ่ๆ ด้วย OpenSource แต่แรกครับ
นอกจากเจอแรงต้านเยอะ และปัญหาด้านความเชื่อมั่นแล้ว
ถ้ามัน fail เพราะเราไม่มีความรู้เฉพาะทางในการ implement ระบบนั้นๆ
มันก็จะพาชื่อ OpenSource ลงเหวลงไปด้วย




ปล. ถึงพี่หมี ... ผมเขียนให้แล้วนะพี่ ผมอาจจะเข้าใจถูกมั่งผิดมั่ง แต่เท่าที่เขียนมา ก็เป็นความเห็นของผม
ว่าทำไม OpenSource ยังไม่ได้รับการยอมรับ และ หนทางที่จะพา OpenSource ไปสู่การยอมรับ


อนึ่ง ผมก็ไม่ใช่คนในวงการ OpenSource นะครับ เขียนไปนี่ก็จากมุมมองอันคับแคบของผม
ที่มองว่า หากระบบใหญ่ๆ ขององค์กรใหญ่ๆ จะยอมรับ OpenSource เข้าไป จะทำอย่างไร
หากพี่น้องในวงการ OpenSource ผ่านมาพบว่าผมเขียนผิด เข้าใจผิดที่ใด ทักท้วงได้ทันทีครับ
ผมยินดีแก้ไข และรับผิด สิ่งที่เขียนผิดไปทุกประการ







อัพ blog สามวันติด  ขอประกาศดอง สักระยะ หมดแรง ...