Nha Trang ICT 2015

I came to Nha Trang this year to bring Fedora back there after the successful event last year. This year, the event was held in another university in Nha Trang, TCU with more participants from other universities in Nha Trang and nearby cities.

There was a academy/science conference in the morning with some talks from open source enterprises who sponsor the whole event. The afternoon was reserved for FOSS communities and I had a session to introduce about the Fedora project to all students and lectures. There were about 200 attendees join into a big classroom.

During the session, I talked to them about the benefit of contributing to FOSS and Fedora. I told participants what the employers need in general when they recruit new employees, especially young students. Basically, they need candidates to have critical thinking, group working, English speaking and technical skills. Students can study those skills during participating in a FOSS project like Fedora.

I also had got a table to put some Feodra 23 DVD and small pins there. People were really interested in those gifts and grabbed them all in less than half an hour. People asked a lot of questions about Fedora and FOSS and I tried my best to answer most of them.

The last session in the afternoon was for Q&A. I was appointed to answer most community-related questions.

Hope students and lectures in the university and nearby would be more interested in Fedora and FOSS after this event.

See some more pictures here.

The first OpenDay 2015 – key statistics

Chào các anh, các chị và các bạn,

OpenDay, sự kiện đầu tiên được VFOSSA tổ chức riêng cho các dự án, nhóm cộng đồng nguồn mở, đã diễn ra được hơn một tuần với rất nhiều cung bậc cảm xúc từ nhiều phía.

Trước hết, thay mặt BTC, xin gửi lời chân thành cảm ơn tới các cá nhân, nhóm cộng đồng, các công ty đã quan tâm tham dự. Không có sự tham dự này, dù là sự kiện dành riêng cho chính các bạn, OpenDay cũng khó có được bất kỳ kết quả gì, chứ đừng nói đến thành công hay không. Cảm ơn Trường đại học Thăng Long đã đứng ra hỗ trợ đang cai tổ chức. Cảm ơn các DN thành viên VFOSSA đã tích cực hưởng ứng sự kiện trong vai trò nhà tài trợ: D&L, Netnam, HaproInfo, eXoPlatform, VDC-IT, Geekpolis, EcoIT, DTT đã tài trợ cho sự kiện. Cảm ơn ITPlus, Vinades, iWay đã hỗ trợ công tác tổ chức và tư vấn về nội dung. Và đặc biệt cảm ơn Open Development Cambodia, nhóm cộng đồng quốc tế duy nhất, đã mang đến cho OpenDay một chủ đề rất mới mẻ và đầy hứa hẹn, OpenData.

Báo cáo này chủ yếu liệt kê một số dữ liệu cơ bản, không (hoặc ít) kèm theo các bình luận cảm tính cá nhân. Sau kỳ nghỉ lễ 30/4, chúng tôi sẽ dành thêm thời gian phân tích sâu hơn, đặc biệt là về mặt được và chưa được của sự kiện vừa qua để rút kinh nghiệm và tổ chức các sự kiện OpenDay tới được tốt hơn.

Đầu tiên, về tài chính, với sự hỗ trợ của các nhà tài trợ và công tác tổ chức, tổng thu – tổng chi sau sự kiện đã dương. Chi tiết thu/chi tài chính sẽ được thông báo cho các nhà tài trợ và BTC. Phần tiền dư sẽ được chuyển vào quĩ chung của VFOSSA để hỗ trợ tổ chức các sự kiện OpenDay sau cũng như các hoạt động khác của cộng đồng.

Khoảng 40 người (lúc đông nhất là gần 50, chưa kể đội ngũ các tình nguyện viên) đã tham dự tại hội trường trường ĐH Thăng Long và khoảng hơn 20 người đã tham dự online từ xa, qua dịch vụ TrueConf được hỗ trợ bởi HaproInfo.

Trong phiên buổi sáng, sau phát biểu khai mạc của ông Nguyễn Hồng Quang, Chủ tịch VFOSSA, 3 cộng đồng đã có dịp giới thiệu về dự án và các công việc đang thực hiện của mình, bao gồm: NukeViet (Mr. Hùng, NukeViet – Vinades), OpenData (Mr. Lê Trung Nghĩa và Mrs. Terry Parnell, OpenDevCam)  và OpenEC (Mr. Tuấn, OpenEC – iWay)

Khoảng 30 người đã tham dự ăn trưa và tiếp tục trao đổi các chủ đề cùng quan tâm.

Phiên buổi chiều tổ chức theo hình thức Birds of a Feather với chủ đề trọng tâm về OpenData, một khái niệm còn tương đối mới mẻ ở Việt Nam. Sau hơn 3h thảo luận, nhóm làm việc (đến cuối buổi còn khoảng 15 người) đã thống nhất chính thức khởi động thành lập cộng đồng OpenData Việt Nam, kết nối ngay với Campuchia, Thái Lan; chuẩn bị mời thêm Myanmar, Lào để hình thành OpenDevMekong, tiến tới kết nối toàn khối, hình thành cộng đồng OpenData ASEAN. Một mailing list OpenData mới và một Facebook page OpenData ASEAN đã nhanh chóng được lập ra để kết nối ngay cộng đồng, bắt đầu từ những người đã tham dự phiên buổi chiều, và ngay lập tức đã thu hút thêm nhiều người quan tâm.

Cộng đồng OpenData sẽ sớm tổ chức một số hoạt động như dịch sách OpenData Handbook, công cụ quản trị CKAN, tổ chức Video conference với một số nhóm cộng đồng đã và đang làm hoặc quan tâm đến OpenData để chia sẻ kinh nghiệm. Các bạn quan tâm có thể tham gia vào mailing list và/hoặc Facebook page để nhận được các thông tin mới nhất và cùng tham gia thảo luận.

Một số số liệu ngoài lề khác:

  • 85 lượt likes trên OpenDay Fan page trên Facebook tính tới thời điểm hiện tại.
  • Post Reach 1,641, Engagement 233 People Engaged, 15 Comments, 14 Shares, 2,632 post clicks.

Một số bài đã đăng:

P.S. cá nhân tôi xin chân thành gửi lời xin lỗi vì sự chậm trễ công bố báo cáo về sự kiện, phần vì muốn chờ thu thập tương đối đủ dữ liệu, phần vì công việc hàng ngày trước kỳ nghỉ lễ 30/4 quá bận.

Rgds,
Truong Anh Tuan

MHST 2014 – vẫn lối mòn cũ

Nhân sự kiện cuộc thi MHST 2014 khép lại và các giải được công bố chính thức, xin được có vài lời nhận xét với hy vọng BTC sẽ lắng nghe, điều chỉnh và hoàn thiện qui chế cũng như cách thức tổ chức để có được những mùa thi hiệu quả, đúng với mục tiêu chung đặt ra ban đầu, đáp ứng mong đợi của cộng đồng xã hội.

Điểm qua cả 5 dự án lọt vào chung khảo, có thể dễ dàng nhận thấy những lỗi sơ đẳng đối với 1 dự án muốn được gọi là PMTDNM:

  • Các vấn đề về giấy phép phát hành như: không thông báo giấy phép phát hành, không kèm theo bản sao toàn văn giấy phép…
  • Vấn đề về tổ thức cộng đồng (dù là sơ khai): không thấy các dự án tổ chức kênh liên lạc tối thiểu (hoặc ít nhất là không thấy thông báo công khai trên kho mã nguồn chính).
    Không rõ các dự án này giao tiếp công khai với các thành viên trong cộng đồng cũng như end-user như thế nào?
  • Vấn đề về phát hành: 4/5 dự án chưa thấy phát hành phiên bản nào?! (sử dụng tagged trên git)
    Không lẽ BGK chấm trên phiên bản zero?
  • … và còn nhiều nữa nếu đem xem xét kỹ & chấm điểm PoF cẩn thận.

Trong ba mặt cơ bản bắt buộc của một dự án PMTDNM (theo thông lệ quốc tế): i. mã nguồn sẵn sàng và có thể tải về trên Internet, ii. phát hành theo giấy phép được OSI approved (căn cứ theo giấy phép được thông báo trên kho mã nguồn) và iii. tổ chức cộng đồng (dù chỉ sơ khai, đủ thể hiện mong muốn thực hiện tổ chức), các dự án trên mới chỉ đạt được một. Nếu xem xét kỹ các tiêu chí và tổ chức chấm điểm PoF, nhiều vấn đề khác sẽ xuất hiện và đòi hỏi dự án cần được hoàn thiện để có thể chính thức được cộng đồng nhìn nhận là một PMTDNM.

Có thể thấy, những nền tảng nguyên lý cơ bản của nhất của mô hình phát triển PMTDNM đều không được quan tâm đầy đủ và trên thực tế bị break hoàn toàn. Ở đây, lỗi xuất phát từ phía đội phát triển, là các bạn SV. Tuy nhiên, nguyên nhân sâu xa phải kể đến sự thiếu kinh nghiệm và/hoặc sâu sát của mentors và đặc biệt là BGK cũng như BTC.

Chúng ta đang từng bước hoàn thiện mình, nhưng những vẫn đề cơ bản mang tính nguyên lý cần phải được tuân thủ sớm từ đầu. Việc một cuộc thi “SV viết PMNM” như MHST, được tổ chức bởi một tổ chức mang tính đại diện cho cộng đồng PMTDNM VN như VFOSSA lại không lấy tiêu chí phát triển đúng mô hình PMTDNM lên hàng đầu có thể coi là một bước “cải lùi”, khiến cho những nỗ lực khuyến khích tham gia đóng góp phát triển PMTDNM trong toàn thể cộng đồng, đặc biệt là giới trẻ, các bạn SV, có nguy cơ bị ảnh hưởng ít nhiều.

Kiến nghị chung: đưa vào tiêu chí một dự án tham gia MHST bắt buộc phải được phát triển theo mô hình PMTDNM (nếu không, sẽ buộc phải loại bỏ tại thời điểm chấm giải).

P.S. bài viết thể hiện quan điểm cá nhân của tác giả, không phải quan điểm chính thức của VFOSSA cũng như bất cứ tổ chức, cá nhân nào khác.

Tại sao ra quyết định đồng thuận tốt hơn cho các dự án PMTDNM

Nhiều người trong chúng ta sử dụng mô hình ra quyết định đồng thuận (Consensus-based decision making) trong các dự án PMTDNM như Apache’s lazy consensus model, nhưng phần lớn chúng ta thực hiện hay thậm chí đặt thành qui định cuối cùng theo qui trình biểu quyết theo đa số (Majority-based decision making).

Trong mô hình biểu quyết theo đa số, những người bất đồng quan điểm bị gạt sang một bên — nhóm đa số buộc phải đặt nhóm bất đồng thiểu số vào vị trí những kẻ thua trong cuộc biểu quyết. Trong mô hình ra quyết định đồng thuận, trách nhiệm của cả nhóm là luôn lưu tâm đến các mối lo ngại của những người bất đồng quan điểm.

Nhìn chung, các quyết định đồng thuận bắt buộc nhóm phải tập trung dàn xếp một giải pháp tốt nhất có thể. Khi mọi người bị đặt vào vị trí thắng/thua, họ có xu hướng suy nghĩ cứng nhắc vào một hoặc hai đầu, thứ mà chưa chắc đã đại điện cho giải pháp tốt nhất có thể (rất có thể nằm đâu đó ở giữa).

Thông thường, để đạt được sự đồng thuận, chỉ cần làm rõ một số ý hiểu nhầm hoặc thực hiện một số điều chỉnh nhỏ so với đề xuất ban đầu. Tuy nhiên, sự xuất hiện phiếu trắng (-0) , kể cả khi không có phiếu chống (-1) nào, cũng cho thấy, đề xuất ban đầu nên được suy nghĩ thêm. Phiếu trắng từ những người lãnh đạo nhóm càng khuyến khích những người khác cân nhắc khả năng cần phải bổ sung thêm để đề xuất nhận được sự ủng hộ hoàn toàn.

Hiện tại, những dự án, cộng đồng PMTDNM lớn như CentOS, Fedora đã và đang áp dụng mô hình ra quyết định đồng thuận này.

Đánh giá khả năng phát triển của một dự án PMTDNM

Tính đến thời điểm này, có tới trên dưới 400,000 dự án phần mềm tự do nguồn mở trên toàn thế giới, và nhiều dự án mới được phát sinh mỗi ngày; từ những dự án thu hút hàng ngàn, hàng chục ngàn, thậm chí hàng trăm ngàn lập trình viên, tới những dự án chỉ với duy nhất 1 người phát triển. Câu hỏi đặt ra là làm thế nào để xác định được tiềm năng phát triển, hướng tới thành công của một dự án PMTDNM (không phân biệt dự án lớn/nhỏ, dự án mới/lâu năm…). Một trong các phương pháp được sử dụng nhiều nhất là phương pháp “Tính chỉ số khả năng một dự án PMTDNM đang trên con đường dẫn tới Thất bại – Points of FAIL”.

Bài viết này đề cập đến phương pháp này cùng chi tiết về cách tính điểm PoF (Points of FAIL) cho một dự án PMTDNM. PoF càng lớn nghĩa là dự án càng đang tiến gần đến điểm “Chết”.Trên thực tế, mục đích chính của hệ thống tính điểm PoF là chỉ ra các điểm chưa tốt của dự án PMTDNM, khuyến khích mỗi dự án tự điều chỉnh nhằm đi đến mục tiêu thành công cuối cùng. Các thuộc tính được xem xét cho một dự án cùng PoF cho mỗi thuộc tính bao gồm:

Tổng độ lớn mã nguồn (Size):

  • Nếu độ lớn mã nguồn của dự án >100MB: +5 PoF
  • Nếu mã nguồn nén lại vẫn có độ lớn >100MB: +5 PoF

Hệ thống quản lý mã nguồn (Source Control):

  • Không có hệ thống quản lý mã nguồn công khai (VD: cvs, svn, bzr, git, hg…): +10 PoF
  • Có hệ thống quản lý mã nguồn công khai, nhưng:
    • không có web viewer: +5 PoF
    • không có tài liệu hướng dẫn sử dụng cho người mới: +5 PoF
    • hệ thống quản lý mã nguồn tự tạo: +30 PoF
    • trên thực tế, không được sử dụng: +50 PoF

Dịch từ mã nguồn (Building From Source):

  • Không có tài liệu hướng dẫn dịch từ mà nguồn: +20 PoF
  • Có tài liệu nhưng không chính xác: +10 PoF
  • Mã nguồn được cấu hình bằng một shell script tự viết bằng tay: +10 PoF
  • Mã nguồn được cấu hình bằng cách sửa trực tiếp vào tệp cấu hình: +20 PoF
  • Mã nguồn được cấu hình bằng cách sửa thủ công vào các tệp header: +30 PoF
  • Mã nguồn không cấu hình được trước khi dịch: +50 PoF
  • Mã nguồn được dịch bằng công cụ khác, không phải GNU Make: +10 PoF
  • Mã nguồn được dịch bằng công cụ nguồn đóng: +50 PoF
  • Mã nguồn được dịch bằng công cụ tự tạo: +100 PoF

Gói kèm (Bundling):

  • Mã nguồn chỉ phát hành với các dự án khác mà nó phụ thuộc vào: +20 PoF
  • Mã nguồn không thể dịch riêng nếu không dịch mã gói kèm trước: +10 PoF
  • Mã gói kèm đã bị chỉnh sửa: +40 PoF

Thư viện (Libraries):

  • Chương trình chỉ dịch ra thư viện tĩnh (static libraries): +20 PoF
  • Chương trình có thể dịch ra thư viện chia sẻ (shared libraries) nhưng không đánh phiên bản: +20 PoF
  • Không cố gắng sử dụng các thư viện hệ thống (system libraries) sẵn có: +20 PoF

Cài đặt hệ thống (System Install):

  • Chương trình cố gắng cài đặt vào thư mục /opt hoặc /usr/local: +10 PoF
  • Không có “make install”: +20 PoF
  • Chương trình không hoạt động ngoài thư mục mã nguồn: +30 PoF

Các “dị điểm” trong mã nguồn (Code Oddities):

  • Mã nguồn sử dụng dấu xuống dòng kiểu Windows (“DOS format” files): +5 PoF
  • Mã nguồn phụ thuộc vào một tính năng cụ thể của chương trình dịch: +20 PoF
  • Mã nguồn phụ thuộc vào một lỗi cụ thể của chương trình dịch: +50 PoF
  • Mã nguồn phụ thuộc vào bất cứ thứ gì trong bộ Microsoft Visual Studio: +100 PoF

Giao tiếp (Communication):

  • Dự án không có thông báo phát hành trên nhóm thư (mailing list): +5 PoF
  • Dự án không có nhóm thư: +10 PoF
  • Dự án không có trình quản lý lỗi (bug tracker): +20 PoF
  • Dự án không có website: +50 PoF
  • Là một dự án ảo (vaporware) trên Sourceforge: +100 PoF

Phát hành (Releases):

  • Dự án không thực hiện phát hành theo phiên bản tuần tự (Major, Minor): +10 PoF
  • Dự án không thực hiện phát hành theo phiên bản: +20 PoF
  • Dự án không có phát hành: +50 PoF
  • Dự án chỉ phát hành dưới dạng một file gắn kèm một bài viết trên diễn đàn/website: +100 PoF
  • Bản phát hành chỉ dưới khuôn dạng .zip: +5 PoF
  • Bản phát hành chỉ dưới khuôn dạng OSX .zip: +10 PoF
  • Bản phát hành chỉ dưới khuôn dạng .rar: +20 PoF
  • Bản phát hành chỉ dưới khuôn dạng .arj: +50 PoF
  • Bản phát hành chỉ dưới khuôn dạng nén tự tạo: +100 PoF
  • Bản phát hành giải nén không vào thư mục riêng chứa số hiệu phiên bản (e.g. glibc-2.4.2/): +10 PoF
  • Bản phát hành giải nén không vào thư mục riêng (e.g. glibc/): +25 PoF
  • Bản phát hành giải nén vào một thư mục con mức sâu (e.g. home/johndoe/glibc-svn/tarball/glibc/src/): +50 PoF

Lịch sử (History):

  • Chương trình được rẽ nhánh từ một dự án khác: +10 PoF
  • Các lập trình viên chính không tham gia dự án cha (trong trường hợp rẽ nhánh): +50 PoF
  • Là phần mềm nguồn đóng trước khi nguồn mở hóa:
    • 1-2 năm: +10 PoF
    • 3-5 năm: +20 PoF
    • 6-10 năm: +30 PoF
    • trên 10 năm: +50 PoF

Giấy phép (Licensing):

  • Giấy phép không được ghi trong từng tệp mã: +10 PoF
  • Mã nguồn tự thân chứa sự không tương thích của các giấy phép: +20 PoF
  • Mã nguồn không có thông báo về mục đích của giấy phép: +30 PoF
  • Mã nguồn không bao gồm một bản sao toàn văn giấy phép: +50 PoF
  • Mã nguồn không nêu rõ giấy phép: +100 PoF

Tài liệu (Documentation):

  • Chương trình không có lịch sử thay đổi (changelog): +10 PoF
  • Chương trình không kèm theo bất cứ tài liệu nào: +20 PoF
  • Không công bố bất cứ tài liệu nào trên website: +30 PoF

Chỉ số tổng hợp (FAIL METER):

  • 0 PoF: Hoàn hảo! Các chỉ số đều hướng tới thành công!
  • 5-25 PoF: Bạn đang làm tốt, nhưng hoàn toàn có thể tốt hơn.
  • 30-60 PoF: Bạn làm chưa tốt. Cần cải tiến.
  • 65-90 PoF: Bạn làm rất không tốt. Cần thay đổi sớm (theo các chỉ số bị cộng điểm cao ở trên).
  • 95-130 PoF: Con tàu sắp chìm rồi!
  • 135+ PoF: Dự án đã hoàn toàn thất bại.

Còn chần chờ gì nữa, hãy thử nhẩm tính PoF của dự án PMTDNM của bạn! 🙂

Nguồn: http://www.theopensourceway.org/

Thanksgiving, Merry Chistmas and Happy New Year 2013

Dear my family, friends and colleagues,

I would like to thank you for all your endless supports to free and open source software movement as well as for myself.

Thank you for your trusting to elect me as the new member of Fedora Ambassadors Steering Committee in the term of two Fedora releases 18 and 19 in 2013. Also many thanks to all other FOSS communities/groups in Vietnam as well as all over the world, including (but not limited to) LUGs, VFOSSA, Mozilla, Community Space for all your trusting and supporting.

With all your trusts and supports, I believe that next year, 2013, would be one of the best ever years for all of us.

MERRY CHRISTMAS and HAPPY NEW YEAR 2013.

Tuan TRUONG

10 hiểu lầm về phần mềm tự do nguồn mở

Trong một thời gian dài, đề cập đến phần mềm tự do nguồn mở trong một môi trường kinh doanh là không thể tưởng tượng nổi. May mắn thay, thời gian đã thay đổi, phần mềm tự do nguồn mở ngày nay thường được cân nhắc đầu tiên. Nhưng những tiến bộ đáng kể đó không hoàn toàn loại bỏ một số quan niệm sai lầm trong tâm trí của người sử dụng. Vì vậy, sẽ rất hữu ích khi liệt kê một vài nhận thức hoàn toàn sai về phần mềm tự do nguồn mở:

1. Phần mềm tự do nguồn mở chỉ dành cho Linux

Hầu hết người sử dụng cùng chung điểm này. Khi nói về phần mềm tự do nguồn mở, cuộc nói chuyện, không sớm thì muộn, hầu như chắc chắn xoay sang Linux. Công chúng dường như luôn luôn giả định các phần mềm tự do nguồn mở chỉ dành cho Linux. Trong thực tế có rất nhiều dự án phần mềm tự do nguồn mở hoạt động đa nền tảng hoặc thậm chí chỉ chạy trên Windows. Trang web phần mềm tự do nguồn mở cho Windows liệt kê danh sách một loạt các phần mềm tự do nguồn mở dành cho hệ điều hành của Microsoft. Tuy nhiên, trang web không bao gồm danh sách các dự án cực lớn như Apache, MySQLDrupal.

2. Phần mềm tự do nguồn mở luôn luôn miễn phí

Để được coi là phần mềm tự do nguồn mở, điều kiện cần là mã nguồn phải được chia sẻ tự do. Điều đó không đồng nghĩa rằng bản thân các ứng dụng chắc chắn miễn phí. Thực tế, có nhiều công ty kiếm tiền từ các dự án phần mềm tự do nguồn mở của họ. Thông thường, các nhà cung cấp có xu hướng cung cấp kèm theo các dịch vụ như hỗ trợ, bổ sung tính năng hoặc tạo ra một phiên bản cộng đồng miễn phí.

Khi một công ty bán một phiên bản cộng đồng, nó thường là một biến thể rút gọn của sản phẩm thương mại nguồn mở. Một ví dụ tuyệt vời của phương pháp này là Zimbra, một phần mềm máy chủ thư điện tử và công cụ cộng tác mạnh mẽ, cung cấp cả phiên bản nguồn mở miễn phí, kèm theo mã nguồn đầy đủ và phiên bản thương mại với nhiều tính năng hơn và khả năng tiếp cận mã nguồn hạn chế hơn.

3. Phần mềm tự do nguồn mở không được hỗ trợ

Vấn đề hỗ trợ thường rất quan trọng đối với các công ty lớn. Một số phần mềm tự do nguồn mở cung cấp hỗ trợ, một số kèm theo phụ phí, một số miễn phí. Đôi khi, có những diễn đàn hoặc danh sách thư hỗ trợ. Một vài trường hợp khác, có thể liên lạc với các nhà phát triển đã tạo ra hoặc đang làm việc trong dự án. Thậm chí một vài phần mềm tự do nguồn mở không có một công ty với đường dây nóng hỗ trợ 24/7, điều đó không có nghĩa là không có hỗ trợ. Phương án hỗ trợ chắc chắn có sẵn, cho dù hỗ trợ đó có thể không tương đồng với những suy nghĩ, tính toán của công ty.

4. Bạn cần truy cập toàn bộ vào mã nguồn

Mặc dù việc này thường không phải là vấn đề quan tâm của người dùng bình thường, tuy nhiên, nó cũng vẫn khá quan trọng trong hoàn cảnh vẫn còn một số quan niệm sai lầm đáng kể. Phần mềm tự do nguồn mở cho bạn khả năng truy cập toàn bộ vào mã nguồn, nhưng không có nghĩa là bạn bắt buộc phải quyền truy cập nếu chỉ muốn sử dụng phần mềm.

Đây là một điều huyễn hoặc đã kéo dài trong một thời gian dài. Chỉ vì mã nguồn được phát hành và có sẵn không có nghĩa là nó luôn cần thiết. Trong thực tế, người dùng có thể không bao giờ phải động tới mã nguồn trong toàn bộ quãng thời gian sử dụng phần mềm tự do nguồn mở. Nhưng mỗi khi bạn hoặc công ty của bạn muốn thay đổi một ứng dụng, mã nguồn sẽ luôn sẵn sàng.

5. Phần mềm tự do nguồn mở chỉ dành cho lập trình viên

Rất nhiều công chúng dường như nghĩ rằng bởi vì bản chất của phần mềm tự do nguồn mở, chỉ có các lập trình mới sử dụng. Sự nhầm lẫn có thể phát sinh từ sự sẵn có của mã nguồn và kèm theo giả định rằng sự sẵn có của mã nguồn có nghĩa rằng chỉ có những người biết làm thế nào để đọc, chỉnh sửa, và xây dựng lại mã nguồn đó mới có thể và nên sử dụng nó.

Trong thực tế, bất cứ ai cũng có thể sử dụng phần mềm tự do nguồn mở mà không đòi hỏi phải có các kỹ năng để sửa đổi và xây dựng lại phần mềm.

6. Bạn đang vi phạm luật pháp với việc ứng dụng phần mềm tự do nguồn mở

Trước hết phải cảm ơn SCO. Mọi người đã từng nghĩ ứng dụng phần mềm tự do nguồn mở có thể là bất hợp pháp. Nhưng may mắn thay, tất cả đã thay đổi kể từ sau khi SCO bị thua kiện tại tòa án. Sử dụng phần mềm tự do nguồn mở không vi phạm pháp luật sở hữu trí tuệ. Và đó không phải là một trường hợp duy nhất thất bại khi cố gắng chứng minh phần mềm tự do nguồn mở đã vi phạm về sở hữu. Vì vậy, hoàn toàn có thể khẳng định rằng nếu bạn đang sử dụng phần mềm tự do nguồn mở, bạn không bị coi là một kẻ nổi loạn vi phạm pháp luật.

7. Bạn phải là một chuyên gia nếu muốn sử dụng phần mềm tự do nguồn mở

Điểm này liên quan đến các điểm trước. Vẫn còn nghe thấy câu hỏi cũ, “Bạn có phải tự viết các trình điều khiển để sử dụng?” Câu trả lời đã rõ một thời gian dài, không. Nhiều người vẫn tin rằng phần mềm mã nguồn mở chỉ dành cho chuyên gia, những người có thể biên dịch phần mềm ngay trong giấc ngủ. Không phải như vậy.

Trong thực tế, hầu hết các dự án phần mềm tự do nguồn mở hiện tại không yêu cầu phải biên dịch, cài đặt từ mã nguồn. Hầu hết các nền tảng đều hỗ trợ các phần mềm dưới dạng đóng gói sẵn, giúp cho việc cài thêm phần mềm vào máy tính dễ dàng như cài đặt phần mềm thương mại, trong một vài trường hợp, thậm chí còn dễ dàng hơn. Và quá trình sử dụng hầu hết các phần mềm tự do nguồn mở là như nhau. Giống như tất cả những điều để làm với máy tính, khi trí thông minh của người sử dụng máy tính trung bình giảm, tính dễ sử dụng phần mềm tự do nguồn mở tăng lên.

8. Thật khó để tìm thấy phần mềm tự do nguồn mở cần thiết

Phần mềm nguồn mở ở khắp mọi nơi, có sẵn trên Download.com, trong kho phần mềm Android, trong tiện ích thêm/bớt phần mềm trên các bản phân phối Linux, và từ các trang web trên toàn cầu. Chỉ cần một phép tìm kiếm trên Google là bạn có thể tìm thấy phần mềm tự do nguồn mở.

Có các trang web được dành riêng cho phần mềm tự do nguồn mở trên các nền tảng cụ thể, và thậm chí cả Microsoft cũng có một trang web phần mềm tự do nguồn mở riêng. Phần mềm tự do nguồn mở đã đi qua một chặng đường dài từ cội nguồn trong con đường tìm về bản ngã, cạnh tranh với phần mềm thương mại độc quyền giống như trong câu phương ngôn tìm kim trong đống cỏ.

9. Phần mềm miễn phí và phần mềm chia sẻ cũng là phần mềm tự do nguồn mở

Hầu hết các người dùng đã quen thuộc với phần mềm miễn phí và phần mềm chia sẻ. Hai loại phần mềm là không giống như phần mềm tự do nguồn mở. Nếu mã nguồn phần mềm không được cung cấp, thì các phần mềm đó chắc chắn là không phải là phần mềm tự do nguồn mở.

 

 

10. Không nhiều người sử dụng phần mềm tự do nguồn mở

Trong thực tế, bạn có thể đang sử dụng phần mềm tự do nguồn mở. Bạn có đang sử dụng trình duyệt Firefox? Nếu vậy, bạn đang sử dụng phần mềm tự do nguồn mở. Nhiều người sử dụng phần mềm tự do nguồn mở mà không biết. OpenOffice, ThunderbirdPidgin, Drupal, WordPressGnuCash, Notepad++, và nhiều sản phẩm nữa hiện đang được sử dụng rộng rãi. Và đó thậm chí còn chưa tính các đoạn mã nguồn tự do được đưa vào phần mềm thương mại.

Xu hướng phát triển

Phần mềm tự do nguồn mở giờ đây không còn phải chịu sự kỳ thị. Nhiều ứng dụng phần mềm tự do nguồn mở được xem như  tương đương hoặc tốt hơn với các phần mềm thương mại. Xu hướng này đang tiếp tục, đặc biệt là khi nhiều người dùng chuyển từ máy tính để bàn truyền thống sang các ứng dụng dựa trên đám mây hoặc ảo hóa.

Nếu bạn đang xem xét việc chuyển từ phần mềm đóng sang phần mềm tự do nguồn mở, có nhữngđiều bạn nên biết, nhưng rất ít thứ bạn phải biết. Tự trang bị thông tin đúng đắn, quá trình chuyển đổi của bạn sang phần mềm tự do nguồn mở sẽ trôi trảy. Ngoài ra, nếu bạn đã có kinh nghiệm trong phần mềm tự do nguồn mở, có lẽ bạn đã gặp phải quan niệm sai lầm phổ biến khác mà bạn muốn chia sẻ.

source: zdnet.com

Software Freedom Day Hanoi 2011

SFD (Software Freedom Day), một trong những ngày hội lớn nhất trong năm của cộng đồng nguồn mở, là ngày cả thế giới tôn vinh Phần mềm tự do và Mã nguồn mở (FOSS). Đây là sự kiện thường niên và được tổ chức vào ngày thứ bảy thứ ba của tháng chín hằng năm. Sự kiện nhằm quảng bá về lợi ích, tính tiện dụng cũng như các tính năng của các phần mềm tự do tới người dùng. SFD cũng là dịp để những nguời yêu thích công nghệ, yêu mến FOSS gặp gỡ và trao đổi bàn luận về các vấn đề FOSS yêu thích.

Năm nay sự kiện này được tổ chức theo hình thức mới: Các diễn giả đăng ký chủ đề trước trên diễn đàn sau đó những chủ đề nào được quan tâm bình chọn nhiều nhất sẽ được thuyết trình tại buổi gặp mặt. Như thường lệ, SFD 2011 được nhóm người dùng GNU/Linux (gọi tắt là Hanoilug) với Trung tâm CNF của Tổ chức hợp tác đại học Pháp ngữ (AUF) cùng với các cá nhân và doanh nghiệp FOSS phối hợp đồng tổ chức. Thông tin chi tiết như sau:

SFD Hà nội 2011

  • Thời gian: 8:30 – 17:00, Thứ 7 ngày 17/09/2011
  • Địa điểm: AUF/CNF, Viện Tin học Pháp ngữ (IFI) – Nhà D, Ngõ 42 Tạ Quang Bửu, Sơ đồ.
  • Hoạt động:
  • Dùng internet miễn phí cả ngày (có WiFi)
  • Khám phá các bản phân phối GNU/Linux phổ biến : Ubuntu, Fedora…
  • Nhận đĩa live CD GNU/Linux, Fedora…
  • Trao đổi và thảo luận phần mềm tự do nguồn mở
  • Ngoài ra, còn có “Lớp học cài đặt Ubuntu offline”

Thay mặt BTC, tôi trân trọng kính mời anh/chị, các doanh nghiệp, tổ chức có quan tâm về FOSS tới tham dự và chia sẻ hoạt động đầy ý nghĩa này. Mọi chi tiết xin liên hệ: Ban Tổ chức SFD <btc-sfd-hanoi@hanoilug.org> hoặc Trung tâm CNF (04)38.68.48.85.

Trân trọng!

Bạn có thể xem thông tin thêm về sự kiện trên wiki.

GNOME 3, lịch sử và thay đổi

GNOME (GNU Network Object Model Environment), là một tập hợp các công cụ và môi trườngmàn hình nền có thể chạy trên hầu hết các hệ điều hành phổ biến hiện nay như Linux, BSD, MacOS X, Solaris cũng như Windows.

Đây là một dự án phần mềm mã mở, có liên hệ mật thiết và chia sẻ chung triết lý về phần mềm mãmở với dự án GNU (GNU is Not Unix), nó là một bộ phận cấu thành không thể thiếu của hệ điềuhành mở GNU/Linux từ những ngày đầu phát triển.

Phiên bản GNOME 1.0 ra đời năm 1999, được phát triển bởi Miguel de Icaza và Federico Menavới những thành phần cơ bản như: trình quản lý tệp, trình quản lý cửa sổ được xây dựng tự bộ thưviện GTK+ có giấy phép LGPL đảm bảo tính tự do của nó như là một đối trọng với Qt và KDE ởthời điểm năm 1999.

GNOME 2.0 tập trung vào tính dễ sử dụng của môi trường desktop. Ngôn ngữ lập trình đơn giản,thân thiện giúp cộng đồng phát triển dễ dàng xây dựng các ứng dụng của mình trên nền GTK+.

Thay đổi lớn nhất trong GNOME 3 là “Vỏ GNOME”. Đây là giao diện người dùng cốt lõi củaGNOME 3, là kết quả của ba năm hun đúc ý tưởng về việc cải tạo giao diện trong 2008 UserExperience Hackfest và thời gian thực thi các phát triển đó bởi William Jon McCann (Redhat).

Nói ngắn gọn, GNOME 3 sang trọng hơn so với các phiên bản trước và đẹp xứng tầm, sáng ngangvới Mac OS X Leopard hay Windows 7 ngay cả khi chưa sử dụng compiz (một trình quản lý cửa sổphức hợp).

Vào thời điểm ý tưởng “cải cách” GNOME 2 được hình thành, giao diện của GNOME còn khá sơkhai và khá giống Windows 98 trong khi Microsoft đã cho ra đời Windows Vista và Apple đã trìnhlàng Mac OS X Leopard. Thay thế, đuổi kịp giao diện “bắt mắt” của hai hệ điều này chỉ là mộttrong những mục tiêu của GNOME 3. Một trong những triết lý của GNOME 3 là KISS (Keep itsimple, stupid. Tạm dịch: Càng đơn giản càng tốt). Đây cũng là triết lý chung của các hệ điều hànhhọ Unix giúp cho nó luôn “sạch”, nhỏ ngọn, ổn định cùng thời sử dụng và không bị phình to(bloated) như một số hệ điều hành mã đóng khác.

Với GNOME 3 Shell, hệ thống sẽ có giao diện thoáng hơn,đơn giản hơn, giúp người dùng tậptrung vào công việc của mình với nhiều phiên làm việc dễ dàng tương tác với nhau.

Trong GNOME 3, “Activities” (họat động) và “System status erea” (khu vực trạng thái của hệthống) giúp người dùng theo dõi họat động của hệ thống dễ dàng hơn; “Dash” chứa danh sáchnhững phần mềm đang chạy; khả năng kéo thả các cửa sổ giữa các phiên làm việc; Tổ hợp phím Alt-Tab quản lý các chương trình đang chạy dễ hơn; Biểu tượng cũng như các phần tử của giao diệnđồ họa đều được thiết kế lại so với GNOME 2, thích hợp hơn với các thiết bị máy tính bảng và điệnthoại di động.

Thông tin về GNOME

Trang chủ: http://www.GNOME3.org/

Thử nghiệm: http://www.GNOME3.org/tryit.html

Đôi điều về thiết kế: http://live.GNOME.org/ThreePointZero/DesignHistory

Nhóm Việt hóa GNOME họat động tại: http://du-an-most.hanoilug.org/MostWiki

Nguyễn Vũ Hưng – HanoiLUG

P.S. Các bạn đừng quên tham dự GNOME 3 Release Party tại Hà Nội [1] và tại TpHCM [2].

[1] http://vn.fedoracommunity.org/2011/03/31/gnome-3-release-party/

[2] http://www.facebook.com/n/?event.php&eid=191915004183685&mid=403a92bG47dd8b91G508afb7G7&bcode=Qvvmi1Cb