Phần mềm tự do nguồn mở cho Việt Nam: tháng 8 2014

Thứ Tư, 27 tháng 8, 2014

Các giáo sư đã nhúng sinh viên trực tiếp vào các cộng đồng nguồn mở

Professors embed students directly into open source communities

Posted 13 Aug 2014 by Bryan Behrenshausen

Theo: http://opensource.com/education/14/8/challenges-to-open-source-computer-science-education

Bài được đưa lên Internet ngày: 13/08/2014

Lời người dịch: Sẽ là tuyệt vời nếu các giáo viên và sinh viên các trường đại học ở Việt Nam được nhúng trong môi trường làm việc của các cộng đồng các dự án phần mềm tự do nguồn mở, vì điều này mang lại cho họ, cả các giáo viên và các sinh viên “những lợi ích tuyệt vời của việc liên kết các sinh viên với các dự án nguồn mở”. “Các giáo sư nên khuyến khích các sinh viên của họ đi sâu vào các kho mã nguồn mở và bắt đầu vá, tưởng tượng cách mà họ có thể đóng góp có ý nghĩa cho một dự án. Việc chơi với mã nguồn mở đối với các ứng dụng của thế giới thực là một hoạt động học tập với những lợi ích không song song... Bằng việc tham gia vào các dự án đó, các sinh viên không chỉ làm sắc nhọn cho các kỹ năng lập trình của họ, mà còn học cách làm việc với các đội nằm phân tán ở các địa điểm ở xa. Họ trở thành quen thuộc hơn với các vấn đề cấp phép phần mềm và sở hữu trí tuệ,...”.

Mặt trời có thể đã từng chiếu sáng không thể sáng hơn ở Philadelphia hôm 28/05/2014. Nhưng ở tầng hầm của tòa nhà Rush của Đại học Drexel, ngôi nhà của trường Cao đẳng Điện toán và Thông tin, các vấn đề từng hơi mù mờ một chút.

Bên trong, một đám gần 20 khoa từ các trường cao đẳng và đại học khắp đất nước đã tranh luận về giá trị của việc thiết kế các khóa học mà nhúng các sinh viên trực tiếp vào các cộng đồng phần mềm tự do nguồn mở (PMTDNM). Heidi J. C. Ellis, Phụ trách và Giáo sư ở Phòng Khoa học Máy tính và Công nghệ Thông tin ở Đại học Tây nước Anh Mới ở Springfield, MA, và Gregory W. Hislop, Trưởng khoa ở trường Cao đẳng Điện toán và Thông tin ở Drexel, đã triệu tập nhóm như một phần của Trải nghiệm Mùa hè Nguồn Mở của Giáo sư năm nay, một hội nghị dài 3 ngày cho khoa có mong muốn cải thiện các kinh nghiệm học tập của các sinh viên của họ bằng việc giới thiệu họ cho các công cụ, dự án và giá trị của nguồn mở.

Ellis và Hislop đã giải thích cho các đồng nghiệp của họ những lợi ích tuyệt vời của việc liên kết các sinh viên với các dự án nguồn mở. Nhưng quyết định dạy các sinh viên cách thức nguồn mở chưa bao giờ là rõ ràng, họ cảnh báo, vì sự giới thiệu một số thách thức độc nhất trong lớp học.

Ví dụ, các dự án nguồn mở là phức tạp - về cả các kho mã và các công cụ của chúng mà các cộng đồng sử dụng để cộng tác. Việc làm cho các sinh viên theo kịp có lẽ mất nhiều tuần - thậm chí nhiều tháng - để lại bọn họ ít thời gian theo nghĩa hàn lâm cho việc thực hiện các đóng góp cụ thể cho một dự án. Các cộng đồng cũng bao gồm những người đặc biệt: các chỉ tiêu, các giá trị và các phương pháp luận được ưu tiên mà một người có thể học chỉ qua sự tham gia tăng cường trong chúng. Các lịch trình phát hành tương ứng của các dự án có thể không gọn gàng chồng lên với các lịch hàng lâm của các lớp học, làm cho công việc chung thậm chí còn khó khăn hơn. Và, các sinh viên vào các lớp khoa học máy tính của họ sở hữu các mức độ hiểu biết khác nhau về các công cụ và các nền tảng, nên việc thiết lập ra một môi trường phát triển phù hợp cho mọi người có thể quả thực rắc rối.

Thú vui của việc vá

Jim Kiper từ Đại học Miami ở Oxford, Ohio, đã có một lo lắng thêm: Các hậu quả là gì - đối với các sinh viên của ông, phòng của ông, đại học của ông, và cộng đồng nguồn mở được ông chọn - nếu sự tham gia lớp học trong một dự án đem lại kết quả ngược với mong muốn, thì việc giới thiệu rắc rối cực kỳ hoặc thậm chí làm trệch hướng cả dự án chăng?

Các trường cao đẳng như Cam MacDonald của Đại học MacEwan, Canada, trường đã đưa các sinh viên vào với đám nguồn mở của phần mềm bản đồ và ảo hóa Ushahidi, từng nhanh chóng làm dịu bớt nỗi sợ hãi của Kiper. Sử dụng tăng cường kiểm soát phiên bản của các cộng đồng nguồn mở tạo nên một dự phòng để bảo đảm an toàn cho dạng tàn phá các sai lầm mà một sinh viên có thể chẳng may đưa vào trong mã của một dự án, họ nói.

“Trong bất kỳ dự án nào đáng giá, điều đó không thể xảy ra”, MacDonald giải thích. “Điều đó có lẽ giống như nhà máy điện hạt nhân để người trong cuộc quản lý nhà máy vào dịp cuối tuần”.

Vì thế các giáo sư nên khuyến khích các sinh viên của họ đi sâu vào các kho mã nguồn mở và bắt đầu vá, tưởng tượng cách mà họ có thể đóng góp có ý nghĩa cho một dự án. Việc chơi với mã nguồn mở đối với các ứng dụng của thế giới thực là một hoạt động học tập với những lợi ích không song song, các thành viên của POSSE nói.

Bằng việc tham gia vào các dự án đó, các sinh viên không chỉ làm sắc nhọn cho các kỹ năng lập trình của họ, mà còn học cách làm việc với các đội nằm phân tán ở các địa điểm ở xa. Họ trở thành quen thuộc hơn với các vấn đề cấp phép phần mềm và sở hữu trí tuệ, Ellis nói, và phải có được các lĩnh vực mới về tri thức làm việc - như mật mã, các qui định về y tế, hoặc môn sinh tin học - nếu họ có ý định nắm bắt mục tiêu của một dự án (không nói tới những ràng buộc của nó).

Đóng góp ngoài mã

Nhưng các sinh viên không đơn giản cần đệ trình mã cho các dự án nguồn mở. Họ có thể khẳng định các lỗi, cập nhật tài liệu, thiết kế các logo và các biểu tượng mới, kiểm thử các tính năng mới, hoặc đơn giản đánh giá các tính năng về khả năng truy cập của một ứng dụng mới.

Ellis, các sinh viên của ông đã đóng góp cho Caribou, một bàn phím trên màn hình mà là một phần của môi trường đồ họa GNOME, đã giải thích rằng các sinh viên thời vụ thường thích đệ trình các bản vá cho các dự án hơn, trong khi các sinh viên mức khởi đầu quan tâm hơn tới việc phỏng vấn những người đóng góp đang tồn tại, khai thác các công nghệ cộng tác như Git hoặc IRC, và lao vào những gì mà Ellis gọi là “các cuộc ngao du trên cánh đồng” nguồn mở - các cuộc đi chơi dạng nhúng ngón chân cái vào các cộng đồng khác nhau, nơi mà họ có thể lẩn đi một chút để có được cảm giác về cách mà sự phát triển nguồn mở thực sự xảy ra.

Qua tất cả điều này, Ellis và Hislop nhấn mạnh, các giáo sư phải nhớ rằng các cộng đồng nguồn mở sẵn sàng hỗ trợ các sinh viên của họ. Họ sẽ chỉ dẫn cho các sinh viên qua mã đối với các dự án của họ, trả lời các câu hỏi của sinh viên, hoặc gặp họ trên IRC. Nhưng để tận dụng đầy đủ những lợi ích của các cộng đồng đó, các giáo sư phải thấy thoải mái với triển vọng các học sinh của họ tương tác với các cá nhân bên ngoài mối quan hệ thầy - trò truyền thống.

Làm các khóa học khoa học máy tính theo cách nguồn mở mở ra cho một lớp học tới dạng chưa từng có và sự mềm dẻo mà nó là một phần và là mảnh đất của sự phát triển nguồn mở. Và vâng những người tham dự POSSE đồng ý: các giáo viên và học sinh có lợi tương tự từ việc tham gia với các cộng đồng nguồn mở.

Một số bài học chỉ không thể được phác thảo trong một chương trình đào tạo.

The sun could not have been shining any brighter in Philadelphia on May 28, 2014. But in the basement of Drexel University's Rush Building, home to the school's College of Computing and Informatics, matters were a bit more hazy.

Inside, a cohort of nearly 20 faculty from colleges and universities across the country debated the merits of designing courses that embed students directly in free and open source software communities. Heidi J. C. Ellis, Chair and Professor in the Department of Computer Science and Information Technology at Western New England University in Springfield, MA, and Gregory W. Hislop, Associate Dean in the College of Computing and Informatics at Drexel, convened the group as part of this year's Professors' Open Source Summer Experience, a three-day immersive conference for faculty wishing to enhance their students' learning experiences by introducing them to open source tools, projects, and values.

Ellis and Hislop explained to their colleagues the wonderful benefits of linking students with open source projects. But the decision to teach students the open source way is never clear-cut, they cautioned, for it introduces a number of unique challenges into the classroom.

For example, open source projects are complex—in terms of both their code bases and the tools their communities use to collaborate. Getting students up to speed might take weeks—even months—leaving them little time in an academic term for making concrete contributions to a project. Communities also embody particular characters: norms, values, and prefered methodologies that one can learn only through extensive participation in them. Projects' respective release schedules may not neatly overlap with the classes' academic calendars, making joint work even more difficult. And, students enter their computer science classes possessing varying degrees of familiarity with tools and platforms, so setting up a development environment suitable to everyone can be tricky indeed.

The joy of tinkering

Jim Kiper from Miami University in Oxford, Ohio, had an additional concern: What were the consequences—for his students, his department, his university, and his chosen open source community—if class participation in a project backfired, introducing frustrating complications or even derailing the project altogether?

Colleagues like Cam MacDonald of MacEwan University, Canada, who has involved students with open source crowd mapping and visualization software Ushahidi, were quick to allay Kiper's fears. Open source communities' extensive use of version control forms a failsafe for the kind of devastating mistakes a student might accidentally introduce into a project's code, they said.

"In any project worth its salt, that can't happen," MacDonald explained. "That'd be like the nuclear power plant letting the intern run the plant on the weekend."

So professors should encourage their students to dive into open source code repositories and begin to tinker, imagining how they might meaningfully contribute to a project. Toying with open source code for real-world applications is a learning activity with unparalleled benefits, POSSE members said.

By participating in these projects, students not only sharpen their coding skills, but also learn how to work with teams distributed in remote locations. They become more familiar with intellectual property and software licensing issues, Ellis said, and must acquire working knowledge new domains—like cryptography, health regulations, or bioinformatics—if they intend to to grasp a project's purpose (not to mention its constraints).

Contribution beyond code

But students needn't simply submit code to open source projects. They might confirm bugs, update documentation, design new logos or icons, test new features, or simply assess an application's accessibility features.

Ellis, whose students have contributed to Caribou, an on-screen keyboard that's part of the GNOME desktop, explained that seasoned students often prefer to submit patches to projects, while beginner-level students are more content to interview existing contributors, explore collaboration technologies like Git or IRC, and embark on what Ellis calls open source "field trips"—toe-dipping excursions into various communities, where they might lurk for a bit to get a sense of how open source development really occurs.

Through it all, Ellis and Hislop stressed, professors must remember that open source communities are available to assist their students. They'll guide students through the code for their projects, answer student questions, or meet with them on IRC. But to completely leverage the benefits of these communities, professors must get comfortable with the prospect of their pupils interacting with individuals outside the traditional teacher-student relationship.

"It's a different style," Hislop told the POSSE cohort. "And some people just aren't comfortable with that style."

Doing computer science coursework the open source way does expose a class to the kind of unpredictability and flexibility that's part and parcel of open source development. And yet POSSE attendees agreed: teachers and students alike benefit from engaging with open source communities. Some lessons just can't be outlined in a syllabus.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com

Thứ Ba, 26 tháng 8, 2014

Nâng cấp các thư viện cho hệ thống nguồn mở Koha

Upgrading libraries to open source Koha system

Posted 14 Aug 2014 by Nicole C. Engard

Theo: http://opensource.com/education/14/8/interview-melissa-lefebvre-koha-bywater-solutions

Bài được đưa lên Internet ngày: 14/08/2014

Lời người dịch: Một cuộc phỏng vấn với người đang là Quản lý các Hoạt động của dự án Hệ thống Thư viện Tích hợp - ILS Koha, với những câu hỏi đáp rất giản dị đời thường. Có lẽ ấn tượng nhất là câu trả lời cho câu hỏi “Các mẹo nào bạn có cho những người khác tìm kiếm công việc trong lĩnh vực nguồn mở?”, nó là: “Mẹo lớn nhất tôi có là hãy chắc chắn tư duy của bạn là nguồn mở“.

Đối với chương trình Sự nghiệp trong Tuần Nguồn Mở (Careers in Open Source Week) ở Opensource.com, tôi nghĩ tôi có thể biến những người mà tôi làm việc cùng hàng ngày để xem cách mà nguồn mở đã thay đổi quan điểm về mọi điều của họ như thế nào. Tôi đã phỏng vấn Melissa Lefebvre, người đã tham gia vào đội hỗ trợ Koha của chúng tôi gần 1 năm về trước sau khi làm việc về Evergreen, một hệ thống thư viện tích hợp (ILS) nguồn mở khác trong vòng 4 năm với tư cách là Quản lý Dự án tại Bibliomation, Inc., một nhóm các trường học và nhà nước lớn ở Connecticut.

Đọc thêm trong cuộc phỏng vấn của tôi với Melissa.

HỎI VÀ ĐÁP

Hãy nói cho chúng tôi về công việc của bạn trong nguồn mở

Tôi là Quản lý các Hoạt động ở ByWater Solutions, và vai trò của tôi ở công ty đó là chỉ dẫn cho việc chuyển đổi các thư viện từ hệ thống ILS hiện hành của họ (thường là một ILS sở hữu độc quyền) sang Koha. Mục tiêu của tôi là để tiến hành sự biến đổi sang nguồn mở càng yên ổn càng tốt. Sự chuyển đổi, bất kể sang hệ thống nào, nguồn mở hay sở hữu độc quyền, là căng thẳng. Khi mà yếu tố nguồn mở vẫn còn làm các nhân viên sợ ở vài điểm, được thêm vào trong nhiều thư viện pha trộn là bất an ltrong lời kêu gọi khởi động với chúng tôi. Tôi đưa họ qua toàn bộ qui trình chuyển đổi trong lời kêu gọi đó và sau đó kiểm tra với họ trong quá trình nhiều tháng chuyển đổi thực sự để xem họ đang làm như thế nào.

Bạn sử dụng các phần mềm/phần cứng/triết lý nguồn mở như thế nào trong thực tế hàng ngày?

Tôi luôn tìm các cách thức để làm cho cuộc sống của tôi dễ dàng hơn dù phải bám sát lịch hoạt động ở trường học của con tôi hay đánh mất danh sách đồ tạp phẩm của tôi. Về điều này, tôi thường tìm kiếm các giải pháp nguồn mở. Vì sao ư? Vì hầu hết các giải pháp nguồn mở là đơn giản và không có các cái chuông và tiếng huýt sáo không cần thiết mà tôi không cần, và thậm chí nếu tôi cần các cái chuông và tiếng huýt sáo dư thừa đó, thì tôi biết rằng ai đó khác ngoài đó cũng cần nó và có khả năng nhất đã viết mã cho nó rồi.

Sản phẩm nguồn mở cho thư viện ưa thích của bạn là gì (khác với Koha)? Vì sao nó là ưa thích đối với bạn, và bạn sử dụng nó như thế nào?

Các sản phẩm nguồn mở ưa thích của tôi là Gimp, nó là một chương trình soạn thảo ảnh tương tự như Photoshop, và còn cả LibreOffice nữa. Cả 2 thứ tôi sử dụng hàng ngày cho công việc của tôi. Tôi luôn ghi chép lại trong tất cả các cuộc gọi của tôi, nên tôi chọn sử dụng LibreOffice thay vì trả tiền cho Word và có những lần mà tôi cần phải thay đổi kích thước hoặc sửa các logo/hình ảnh thư viên cho việc chuyển đổi thư viện nên Gimp là chương trình tôi sử dụng cho điều đó.

Bạn thấy các kinh nghiệm nguồn mở của bạn ảnh hưởng tới cuộc sống hoặc triển vọng của bạn như thế nào khi nói về các phần mềm khác?

Kể từ khi làm việc với một hệ thống ILS nguồn mở (Koha and Evergreen) và có khả năng thay đổi từ ngữ của thứ gì đó hoặc cách thức nó hoạt động thật dễ dàng, tôi muốn điều đó có thể được làm cho mọi dạng phần mềm ngoài đó. Vì hầu hết các chương trình/công cụ trên thế giới này vẫn còn là nguồn đóng, tôi tự thấy mình không hay với việc không có khả năng làm thứ gì đó về những phiền hà mà tôi thấy trong phần mềm; mọi điều tôi biết hầu hết có khả năng có thể được thay đổi dễ dàng.

Các mẹo nào bạn có cho những người khác tìm kiếm công việc trong lĩnh vực nguồn mở?

Mẹo lớn nhất tôi có là hãy chắc chắn tư duy của bạn là nguồn mở. Điều tôi ngụ ý là rất thường xuyên chúng tôi bị chính trị, các băng đỏ và những thứ khác bao quanh, nơi mà tiếng nói của chúng tôi hiếm khi được nghe. Trong thế giới nguồn mở mọi điều đi nhanh hơn nhiều. Nếu bạn có một ý tưởng, bạn nói cho một lập trình viên, có thể trao cho anh/chị ta một ít tiền (hoặc cookies), họ viết mã cho nó, và nó sẵn sàng để được sử dụng. Dễ dàng như người nông dân vắt quả chanh vậy. Nên nếu bạn muốn thực sự tiến hành sự thay đổi, thì nguồn mở là cách để đi.

Bạn có cố làm cho những người khác trong cuộc sống của bạn sử dụng và hiểu nguồn mở hay không? Nếu có, thì làm thế nào?

Tôi có; tuy nhiên, tôi thường không thành công cho tới khi tôi nhắc họ sử dụng một sản phẩm nguồn mở hàng ngày và sản phẩm đó là Firefox. Một khi họ nhận thức được rằng họ đang sử dụng một sản phẩm nguồn mở rồi, thì nó có nhiều ý nghĩa hơn một chút đối với họ những gì tôi làm và cách mà họ có thể sử dụng nguồn mở cũng nhiều hơn.

For Careers in Open Source Week here at Opensource.com, I thought I would turn to the people I work with everyday to see how open source has changed their view on things. I interviewed Melissa Lefebvre who joined our Koha support team almost a year ago after working on Evergreen, another open source ILS system, for four years as Project Manager at Bibliomation, Inc., a large public and school consortium in Connecticut.

Sở hữu trí tuệ & bằng sáng chế phần mềm

Là bài trình bày cho đại diện các công ty phần mềm mới khởi nghiệp tham gia dự án Vietnam Silicon Valey của Bộ Khoa học & Công nghệ ngày 26/08/2014 trong không gian của dự án.

Link: http://www.slideshare.net/lnghia/ip-andsoftwarepatentsaugust2014

Blogger: Lê Trung Nghĩa

letrungnghia.foss@gmail.com

Thứ Hai, 25 tháng 8, 2014

Vì sao tất cả các phần mềm của chính phủ lại không phải là nguồn mở nhỉ?

Why isn't all government software open source?

Posted 14 Aug 2014 by Ben Balter

Theo: http://opensource.com/government/14/8/why-isnt-all-government-software-open-source

Bài được đưa lên Internet ngày: 14/08/2014

Lời người dịch: Trích đoạn kết: “Vì sao tất cả các phần mềm của chính phủ không phải là nguồn mở? Vì bạn có toàn bộ chuỗi giá trị được thiết kế để sản xuất ra phần mềm nguồn đóng, một hệ thống ở trạng thái cân bằng, với ít sự khuyến khích để tự nó nghĩ lại. Công nghệ đã làm cho việc cộng tác trong mở dễ dàng hơn trong những năm gần đây, và kết quả là, hệ sinh thái nguồn mở đã bùng nổ. Vâng, giống như tất cả công nghệ, chính phủ vẫn còn đi sau một ít năm so với những người áp dụng dòng chính thống”.

Chính phủ liên bang là người mua mã lớn duy nhất trên thế giới. Vì thế tại sao mã này - do người đóng thuế trả và là phần không thể thiếu trong công việc hàng ngày của nền dân chủ của chúng ta - là thường xuyên quá là bí ẩn khỏi tầm nhìn của công chúng nhỉ? Có 2 phía cho việc trả lời câu hỏi này: Vì sao chính phủ quá thường xuyên xây dựng trên các nền tảng đóng, và một khi đã được xây dựng, thì vì sao mã đó không được phát hành công khai?

Sử dụng nguồn mở

Dễ dàng hơn nhiều để đóng góp cho nguồn mở khi bạn đang xây dựng trên một nền tảng mở. Trong khi có khả năng mở nguồn một VBScript (Visual Basic for Applications), thì bạn có khả năng muốn có xung lượng nhiều hơn để nhận một sự chấp nhận ấm áp hơn từ một nền tảng với một cộng đồng trực tuyến lành mạnh hơn như Ruby hoặc Python. Vâng thường xuyên hơn là không, mặc định trong chính phủ là để nhìn vào “độ chuyên nghiệp”, các nền tảng sở hữu độc quyền ngay từ đầu, nó được gửi cho chính phủ theo một quỹ đạo nguồn đóng.

Yêu cầu về các giải pháp “chuyên nghiệp”

Có một sự việc về FUD - viết tắt tiếng Anh của các từ gây sợ hãi, không chắc chắn và nghi ngờ - trong các cửa hàng các CIO chính phủ rằng nguồn mửo là ít an ninh hơn, nhiều lỗi hơn, hoặc chi phí lớn hơn, và rằng bạn sẽ đau đớn cả đời nếu bạn không đầu tư vào “một giải pháp thực sự chuyên nghiệp”. Đối với nó, nếu một cơ quan viết một tờ séc cho một nhà bán hàng phần mềm, thì họ biết họ có được cái gì. Hợp đồng nêu ra các tính năng, các lịch trình nâng cấp, và phân bổ trách nhiệm giải trình trong trường hợp mà thứ gì đó đi sai. Quan trọng hơn, nhà bán hàng cung cấp một số điện thoại mà cơ quan có thể gọi nếu họ cần sự trợ giúp. “Bài viết trong các diễn đàn hỗ trợ và ai đó sẽ trả lời” có thể là một đề nghị gây sợ hãi đối với một CIO (Lãnh đạo Thông tin).

Có ít bộ com lê hơn đằng sau nguồn mở

Trước khi giao dịch đó thậm chí xảy ra, nền tảng nguồn đóng có khả năng có một trang và một cán bộ marketing hào nhoáng từ những người bán hàng liên bang gọi cơ quan đó và trải bàn ở các cuộc hội nghị, những điều mà các nền tảng nguồn mở không làm, như Red Hat và một vài hãng khác. Và khi văn phòng CIO yêu cầu các tính năng “chuyên nghiệp” như những cái đuôi kiểm toán hoặc cuộc gặp nhất định nào đó tuân thủ các yêu cầu, thì bạn có thể đánh cược rằng giải pháp nguồn đóng sẽ chắc chắn những tính năng đó làm cho nó nằm trong chu kỳ phát hành tiếp sau.

Các nhà thầu nguồn đóng

Cuối cùng, các nền tảng nguồn đóng là những gì các nhà thầu của chính phủ biết, vì nó là những gì được dạy trong các chương trình khoa học máy tính và những gì họ luôn được yêu cầu cung cấp. Nếu một hãng phát triển có kinh nghiệm có một đống các lập trình viên ColdFusion, thì khi họ đấu thầu trong một hợp đồng họ sẽ khuyến cáo rằng mọi điều sẽ được xây dựng trong ColdFusion. Không nhắc tới, RFP của chính phủ có thể nằm trong phạm vi có lợi cho công nghệ đã có trước đó mà họ đã biết rồi. Tất cả điều này có nghĩa là trước khi dòng mã đầu tiên bao giờ đó được viết ra, những điều kỳ dị được gói lại để chống lại dự án khỏi việc nhòm ngó từ bên ngoài bức tường lửa của cơ quan đó.

Nhưng thậm chí nếu việc sử dụng một nền tảng nguồn đóng của cơ quan đó như vậy, thì không có lý do nào mã tùy biến của họ vẫn không thể được mở mã nguồn.

Việc đóng góp cho nguồn mở

Với ngoại lệ của 18F (các dịch vụ số), Văn phòng Bảo vệ Tài chính Người tiêu dùng - CFPB (Consumer Financial Protection Bureau), và một ít những dịch vụ khác, chính phủ thực sự không viết mã. Trong thực tế, hiếm khi có người nào biết cách để làm thế nếu nó muốn. Thay vào đó, cơ quan thường đóng vai trò một người quản lý chương trình không am hiểu kỹ thuật, đưa ra các đặc tả cho các yêu cầu chức năng và lựa chọn một nhà thầu để phân phối chức năng cuối cùng. Các điểm mấu chốt của hợp đồng trong cơ quan giám sát hợp đồng hiếm khi tham gia vào với cộng đồng nguồn mở, để lại một mình say sưa về nguồn mở. Kết quả là, nguồn mở theo truyền thống thậm chí không là một phần của cuộc thảo luận. Vì sao nó lại như thế?

Tiến trình của nguồn đóng

Về cơ chế phát triển phần mềm thực sự, hợp đồng có khả năng kêu gọi một tiến trình ném qua hàng rào, nơi mà cơ quan thậm chí không thấy mã cho tới khi nó được làm xong, nếu có - khác với nguồn mở. Thậm chí nếu được yêu cầu, các nhà thầu có thể không có kinh nghiệm với các tiến trình nguồn mở, hiện đại hơn, hoặc với việc tham gia trong cộng đồng nguồn mở, tạo ra một kinh nghiệm xấu cho tất cả các bên tham gia và làm nhụt chí tiếp tục các nỗ lực nguồn mở khắp chính phủ.

Sáng chế lại chiếc bánh xe như một mô hình kinh doanh

Tôi cũng đồ rằng các nhà thầu liên bang có một sự thoái chí đối với công việc của họ về nguồn mở, cân nhắc rằng các yêu cầu kỹ thuật có khả năng không biến đổi nhiều từ cơ quan này tới cơ quan khác. Một đòi hỏi của Luật Tự do Thông tin - FOIA (Freedom of Information Act) là một yêu cầu FOIA và một thông cáo báo chí là một thông cáo báo chí, bất kể liệu nó là tờ giấy viết thư FAA hay FDA. Việc mở nguồn các giải pháp đó lần đầu có thể làm giảm đáng kể yêu cầu đối với mã y hệt đang được viết lần thứ 2 bằng tiền của người đóng thuế.

Văn hóa của “không”

Một khi được xây dựng, nó lấy những người mang mã đó với tốc độ thoát ra cần thiết để vượt qua sức ỳ được bảo vệ của cơ quan đó. An ninh sẽ có khả năng nói không. Pháp lý sẽ có khả năng nói không. Bạn sẽ phải có nền tảng đặt chỗ cho mã được phê chuẩn. Bạn sẽ phải mua hợp đồng duy trì liên tục để rà soát lại các yêu cầu thêm. Bạn sẽ phải tạo một chính sách tham gia của các lập trình viên cho cách mà bạn chấp nhận chúng. Nói theo cách các ưu tiên cạnh tranh, các nhân viên chính phủ có khả năng sẽ chọn đi tiếp sang dự án khác đối mặt với công dân, hơn là khả năng bỏ nhiều tháng đấu tranh với hệ thống miễn nhiễm quan liêu để thay đổi.

Đổ vỡ văn hóa

Thậm chí nếu cơ quan định mở mã nguồn, thì cộng đồng nguồn mở đi theo một tập hợp các chỉ tiêu đa phần khác với tôn ti trật tự cứng nhắc của chính phủ. Các cơ quan chính phủ luôn không biết cách tốt nhất tham gia vào cộng đồng nguồn mửo hoặc cách tích hợp một tiến trình nguồn mở vào trong văn hóa mệnh lệnh và kiểm soát của riêng họ. Việc hỗ trợ một cộng đồng nguồn mở là mất thời gian, thứ gì đó các nhân viên chính phủ thường không có. Và khi cơ quan không tuân theo các chỉ tiêu không được nói thành lời của cộng đồng nguồn mở, thì nỗi sợ hãi tồi tệ nhất của người hay nói không thể được sẽ trở thành một lời tiên đoán tự thực hiện.

Sự minh bạch như một trách nhiệm giải trình

Việc mở mã nguồn mở ra cho cơ quan tới tiềm năng cho bình luận từ hàng triệu con mắt có kỹ thuật cao, sống còn, với một chút sự đảo lộn từ triển vọng của cơ quan. Đội phi kỹ thuật của cơ quan có thể không có khả năng đánh giá được sự lành nghề của mã trong nội bộ, và thường thích quét mọi thứ dưới cái thảm, hơn là không khí tiềm tàng mà đồ giặt bẩn của họ cho một vài người trong số những quỷ lùn có kỹ năng nhất trên Internet. Không phải nhắc, những lợi ích của nguồn mở mà những người ủng hộ tán thành thường không được thừa nhận và vì thế không thể phục vụ như một sự làm ngang bằng nếu mã đó được xây dựng quá có mục đích tới nỗi trả nó về không sử dụng được bên ngoài chính phủ, vì thế không lôi cuốn được những người đóng góp từ bên ngoài, hoặc nếu dự án được quản lý quá kém, tới nỗi sợ những người đóng góp ra đi.

Trong khi chờ đợi, mã nguồn không được phát hành đặt ra trách nhiệm giải trình tuyệt đối bằng không (0) trong môi trường chính trị ngày nay. Thứ nào bạn muốn chọn?

Điều gì cần phải thay đổi

Lật bỏ sự mặc định, 3 điều cần thay đổi:

Trước hết, các nhân viên chính phủ cần phải được trang bị với một sự hiểu biết tốt hơn và đánh giá cao công dụng của nguồn mở. Các cơ quan nào mà đã mở mã nguồn rồi làm thế vì những người ủng hộ cá nhân đứng mũi chịu sào được. Các dự án thành công được đặt mục tiêu từ ngày đầu tiên với ý định sẽ mở nguồn và phục vụ để định hình lại yêu cầu thị trường. Các sáng kiến như 18F và chương trình PIF có thể tìm cách truyền cảm hứng và giáo dục cho thế hệ tiếp sau những người bảo vệ nguồn mở bên trong chính phủ.
Thứ 2, thậm chí khi cơ quan không hoàn toàn gọi nó, như các chuyên gia theo vấn đề chủ đề, thì các nhà thầu của chính phủ có trách nhiệm khai thác các lựa chọn thay thế là nguồn mở và giáo dục thị trường như đối với các thực tiễn phát triển tiêu chuẩn công nghiệp hiện đại. Bất kỳ nhà quan sát ngẫu nhiên nào cũng có thể thấy đường hướng dẫn dắt của thị trường, và các hãng khôn ngoan có một cơ hội vượt lên trước. Hãy tạo ra những năng lực nội bộ xung quanh các công nghệ nóng nhất ngày nay và làm gia tăng yêu cầu của chính phủ. Hãy làm cho thực tế hơn cho chính phủ để làm điều đúng, thay vì điều nó đã luôn làm.
Cuối cùng, cộng đồng nguồn mở cần bước tiếp trong cuộc chơi của nó, cả về những gì nó đưa ra - đi vượt qua nhận thức rằng nguồn mở được những người có thú vui riêng viết - và sự thừa nhận đối với mã chính phủ nhận. Ở phía cung, có một mô hình kinh doanh khổng lồ bên trong những bộ đồ đằng sau bất kỳ một trong những dự án nguồn mở phổ biến nhất nào trên Internet. Automattic, GitHub, và Red Hat đang là một ít những ví dụ - đấu tranh chống lại FUD và đưa ra sự hỗ trợ “chuyên nghiệp”. Ở phía cầu, cộng đồng cần làm cho nó thành trách nhiệm giải trình không phải phát hành mã (“bạn đang dấu điều gì?”), và làm cho sự hoàn vốn đầu tư của cơ quan là rõ ràng, bằng việc phân thành trí lực “của chúng ta so với của họ”, và việc hỗ trợ, chứ không phải chỉ trích, các nỗ lực của chính phủ để học nguồn mở.

Vì sao tất cả các phần mềm của chính phủ không phải là nguồn mở? Vì bạn có toàn bộ chuỗi giá trị được thiết kế để sản xuất ra phần mềm nguồn đóng, một hệ thống ở trạng thái cân bằng, với ít sự khuyến khích để tự nó nghĩ lại. Công nghệ đã làm cho việc cộng tác trong mở dễ dàng hơn trong những năm gần đây, và kết quả là, hệ sinh thái nguồn mở đã bùng nổ. Vâng, giống như tất cả công nghệ, chính phủ vẫn còn đi sau một ít năm so với những người áp dụng dòng chính thống.

Hy vọng, với sự giúp đỡ của bạn, điều đó có thể thay đổi.

The federal government is the single largest purchaser of code in the world. So why is this code—taxpayer-funded and integral to the day-to-day working of our democracy—so often hidden from public view? There are two sides to answering that question: Why does the government so often build on closed platforms, and once built, why isn't the code released to the public?

Using open source

It's a lot easier to contribute to open source when you're building on an open platform. While it's possible to open source a VBScript (Visual Basic for Applications), you'd likely have more momentum and receive a warmer reception from a platform with a more vibrant online community like Ruby or Python. Yet more often than not, the default in government is to look to "enterprise-grade," proprietary platforms from the onset, which send the government on a closed-source trajectory.

The demand for "enterprise" solutions

There's a good deal of FUD—fear, uncertainty, and doubt—in government CIO shops that open source is less secure, buggy, or more costly, and that you'll be in for a lifetime of pain if you don't invest in a real "enterprise solution." For one, if an agency writes a check to a software vendor, they know what they're getting. The contract spells out features, upgrade schedules, and allocates liability in the event that something goes wrong. More importantly, the vendor provides a phone number that the agency can call if they need help. "Post in the support forums and someone will reply" can be a scary proposition for a CIO (Chief Information Officer).

There are fewer suits behind open source

Before that transaction even occurs, the closed-source platform likely has a flashy marketing page and a cadre of federal salespeople calling up the agency and tabling at conferences, things open source platforms traditionally don't do, save Red Hat and a few others. And when the CIO's office asks for "enterprise" features like audit trails or meeting certain compliance requirements, you can bet that the closed-source solution will make sure those features make it into the next release cycle.

Closed source contractors

Last, these closed source platforms are what government contractors know, because it's what is taught in computer science programs and what they've always been asked to supply. If an experienced development firm has a bunch of ColdFusion developers, when they bid on a contract they're going to recommend that the thing be built in ColdFusion. Not to mention, the government's RFP may be scoped to favor the legacy technology they already know. All this means that before the first line of code is ever written, the odds are stacked against the project from ever seeing the outside of the agency's firewall.

But even if the agency's using a closed-source platform, there's no reason their custom code can't still be open sourced.

Contributing to open source

With the exception of 18F (digital services), the Consumer Financial Protection Bureau (CFPB), and a few others, government doesn't actually write code. In fact, it rarely has the human know how to do so if it wanted. Instead, the agency traditionally plays the role of a non-techincal program manager, providing specs for the functional requirements and selecting a contractor to deliver the end functionality. The points of contact at the agency overseeing the contract are rarely engaged with the open source community, let alone passionate about open source. As a result, open source traditionally isn't even part of the conversation. Why would it be?

Closed source workflows

In terms of the actual software development mechanics, the contract likely calls for a throw-it-over-the-fence workflow, where the agency doesn't even see the code until it's already in production, if at all—a long way from open source. Even if asked, the contractors may not have experience with more modern, open source workflows, or with participating in the open source community, creating a bad experience for all involved and further chilling open source efforts across government.

Reinventing the wheel as a business model

I also suspect that federal contractors have a disincentive to open source their work, considering that technical requirements likely don't vary much from agency to agency. A FOIA (Freedom of Information Act) request is a FOIA request and a press release is a press release, regardless of whether it's on FAA or FDA letterhead. Open sourcing these solutions the first time around could potentially decrease the demand for that same code being written a second time at the taxpayer's expense.

A culture of "no"

Once built, it takes humans to bring that code to the escape velocity necessary to overcome the agency's guarded inertia. Security is going to likely say no. Legal is going to likely say no. You'll have to get the code hosting platform approved. You'll have to procure an ongoing maintenance contract to review pull requests. You'll have to create a developer engagement policy for how you accept them. In a world of competing priorities, government employees will likely choose to move on to the next citizen-facing project, rather than spend potentially months combating the bureaucracy's immune system to change.

Clash of cultures

Even if the agency manages to open source the code, the open source community follows a set of norms vastly different than the rigid hierarchy of government. Government agencies don't always know how best to engage the open source community or how to integrate an open-source workflow within their own command-and-control culture. Supporting an open source community takes time, something government employees are traditionally short on. And when the agency doesn't follow the open source community's unspoken norms, the naysayer's worst fears become a self-fulfilling prophecy.

Transparency as a liability

Open sourcing code exposes the agency to the potential for criticism from millions of highly-technical, critical eyes, with little perceived upside from the agency's perspective. The non-technical agency team may not have the ability to evaluate the craftsmanship of the code internally, and it's often preferable to sweep things under the rug, rather than potentially air their dirty laundry to some of the Internet's most skilled trolls. Not to mention, the benefits of open source that advocates espouse are often not realized and thus cannot serve as a counterbalance if the code is so purpose built so as to render it unusable outside of government, thus attracting no outside contributors, or if the project is poorly managed, so as to scare those contributors away.

Meanwhile, unreleased source code poses absolutely zero liability in today's political climate. Which one would you choose?

What needs to change

To flip the default, three things needs to change:

First, government employees need to be empowered with a better understanding of and appreciation for the virtues of open source. Those agencies who have open sourced code do so because of individual cheerleaders spearheading the charge. Successful projects are scoped from day one with the intention of being open source and serve to reshape market demand. Initiatives like 18F and the PIF program can seek to inspire and educate the next generation of open source advocates within government.
Second, even when the agency doesn't explicitly call for it, as subject matter experts, government contractors have a duty to explore open source alternatives and to educate the market as to modern industry standard development practices. Any casual observer can see the direction the market's heading, and the smart firms have an opportunity to get in front of it. Create internal competencies around today's hottest technologies and grow government demand. Make it more practical for government to do the right thing, rather than the thing it's always done.
Last, the open source community needs to step up its game, both in terms of what it offers—moving past the perception that open source is written by hobbyists—and the reception government code receives. On the supply side, there's a tremendous business model in being the suits behind any one of the Internet's most popular open source projects—Automattic, GitHub, and Red Hat being a few examples—combating the FUD and providing "enterpise" support. On the demand side, the community needs to make it a liability not to release code ("what are you hiding?"), and make the agency's return on investment clear, by breaking down the "us vs. them" mentality, and supporting, not criticizing, government efforts to learn open source.

Why isn't all government software open source? Because you've got an entire value chain designed to produce closed source software, a system at equilibrium, with few incentives to rethink itself. Technology has made collaborating in the open easier in recent years, and as a result, the open source ecosystem has exploded. Yet, like all technology, government is still a few years behind mainstream adopters.

Hopefully, with your help, that can change.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com

Chúng ta không thể làm khoa học hiện đại trừ phi nó là mở

We cannot do modern science unless it's open

Posted 11 Aug 2014 by Peter Murray-Rust

Theo: http://opensource.com/education/14/8/open-source-deep-academia

Bài được đưa lên Internet ngày: 11/08/2014

Lời người dịch: Kinh nghiệm của một nhà khoa học với 5 công việc có được từ nguồn mở đã chỉ ra rằng sẽ không thể làm khoa học hiện đại được nếu nó không là mở.

Mở là về việc chia sẻ và cộng tác. Chính ý tưởng rằng “chúng ta” là mạnh mẽ hơn, đáng làm và đầy đủ hơn là cái “Tôi”. Tôi không thể hứa công việc, nhưng tôi biết rằng mở đang trở nên rất lớn. Các chính phủ và những người cấp vốn đang thúc đẩy chương trình nghị sự mở, thậm chí qua các viện sỹ thường không có quan tâm hoặc tự quan tâm nghiêm túc.

Một số chính phủ và một số công ty nhận thức được giá trị của các đội; các viện trường và các viện sỹ thường không. Các giá trị sai về yếu tố tác động và các giá trị sai về việc thúc đẩy hàn lâm ngụ ý rằng truy cập mở là một sự phản ánh nghèo nàn của mở, hoặc những gì bạn có thể nhận thức được như một cách thức nguồn mở.

Lần đầu tiên tôi đã bắt đầu nghĩ về sử dụng lại mã vào năm 1980 khi tôi đã phát triển một tiếp cận dữ liệu tinh thể học sử dụng lại được như một công cụ nghiên cứu. Các tinh thể đã được xuất bản như hàng chục ngàn các tài liệu độc lập; tầm nhìn của tôi từng là bằng việc sử dụng tất cả chúng cùng nhau thì chúng ta có thể phát hiện các mẫu mà có thể chỉ ra khoa học mới. Đặc biệt, bản thân tôi và các cộng tác viên của tôi đã chỉ ra rằng các hình chụp của một tinh thể trong các môi trường khác nhau có thể đưa ra thông tin về các dao động và thậm chí các phản ứng hóa học. Tôi đã viết nhiều về phần mềm trong FORTRAN IV. Nó xây dựng trên các gói CONNSER và GEOM lớn của Sam Motherwell. Tôi xây dựng trên toàn bộ một mảng lớn các công cụ thống kê và phân tích, và chúng tôi đã xuất bản các tài liệu cùng. Sau đó, tôi đã đi vào nền công nghiệp dược phẩm để sử dụng các ý tưởng đó trong phát hiện thuốc và quyên góp phần mềm cho một tổ chức, trên cơ sở là nếu họ muốn phát triển nó thì họ có thể liên hệ với tôi và chúng tôi có thể làm việc chung cùng nhau. Điều đó đã không xảy ra. Điều này xảy ra trước cả các giấy phép, trước cả Richard M. Stallman, trước khi mọi người lo lắng về quyền sở hữu. Phần mềm đã gộp vào hệ thống của chúng, và tên tôi đã bị loại bỏ. Tôi thậm chí ngồi qua một bài giảng nơi mà họ đã trình bày nó như là của riêng họ. Tôi đã bỏ qua nó bây giờ, nhưng tôi đã học được.

Mã từng rất phức tạp, và tôi nhận thức được rằng phải có cách tốt hơn, nơi mà chúng tôi viết các module sử dụng lại được. Tôi từng có ấn tượng với NAG và lấy tiếp cận theo module như là trọng tâm. Từng là khó để làm điều này trong hóa học khi còn ít rõ ràng những điều cơ bản là gì. Bạn có thể viết một trình đường chéo của mảng vì nó rõ những gì các đầu vào và đầu ra, nhưng ít rõ ràng hơn cách để tính toán một đống các module (khó khăn hơn so với nó dường như - bạn có nhớ về các chất đồng vị không!?) Vì thế tôi đã bắt đầu viết một tập hợp các thủ tục sử dụng lại được trong 1990 trên FORTRAN. Ở giai đoạn đó, tôi cũng từng dạy các lớp buổi tối ở Birkbeck College về sinh và hóa tin và lấy các module đó cho sinh viên. Vấn đề là các ngôn ngữ đã thay đổi, và vì thế tôi đã biến đổi chúng sang C bằng việc sử dụng f2c (nó làm việc, nhưng không giống như mã được sinh ra!). Sau đó, tôi đã phát hiện ra TCL/TK và đã yêu nó vì về đồ họa - ngay sau đó tôi được một người bán hàng từ Sun Microsystems phát hiện ra.

Họ đã tìm thấy tôi chỉ vì tôi từng nổi bật hơn nhiều so với những người khác.

Vào năm 1994 Henry Rzepa và tôi đã phát triển Chemical MIME - đây từng là một dự án mở (dù không được gắn nhãn chính thức) nơi mà chúng tôi đã tạo ra một ý tưởng hóa học mà quét web trong 6 tuần. Nó dựa vào các chương trình mở RasMol và Mage, chúng tôi có thể tự do phân phối nó để chạy trên các trình duyệt. Chemical MIME từng là một ý tưởng dự án mở: các đặc tả mở, phần mềm mở, và các phân tử mở đủ để trao cho nó một yếu tố WOW! Tính có thể nhìn thấy được đó đã trao cho tôi việc làm tư vấn (bán thời gian) đầu tiên của tôi và giữ cho tôi sống vài năm sau khi tôi rời Glaxo. Cùng lúc, Alan Mills và tôi đã quản lý khóa học đa phương tiện đầu tiên trên web (1995), Các nguyên tắc Cấu trúc Protein. Chúng tôi đã quản lý nó trong một biến thể của BioMOO và Viện Mạng Toàn cầu (Globewide Network Academy); chúng tất cả từng hoàn toàn là các dự án mở xuất phát từ LambdaMOO (Pavel Curtis, Xerox). PPS đã chỉ ra giá trị của cộng đồng, và chúng tôi đã có 250 tình nguyện viên/sinh viên (chúng tôi đã không phân biệt) trong khóa học. Và, PPS cho tôi việc làm thứ 2 của tôi, như một Giáo sư bán thời gian về Dược học ở Nottingham, thiết lập giáo dục ảo.

Chúng tôi tất cả từng là những người lạc quan và nghĩ rằng nó sẽ cất cánh nhanh, nhưng chúng tôi đã thất bại để nhận ra rằng giáo dục là siêu bảo thủ và phải ánh xạ vào các ràng buộc thế giới thực. Đối với tôi, vào năm 1993, world wide web từng biến đổi vì đã không có các rào cản. Nó đã sinh ra các hệ thống, các nguồn và giao thức mở. Chúng từng quá thịnh hành mà bạn đã không nghĩ về chúng. Chúng ta đã không nhận thức được một lực lượng mạnh như thế nào mà Tim Berners-Lee đã từng làm cho mở. Khi tôi từng xoay trong một sự nghiệp vác cặp về nghiên cứu, tư vấn, đột nhập, tôi từng có khả năng để sống và phát triển các ý tưởng của tôi. Nó đã làm tốt cho tôi khi một số các ý tưởng đó đã cần 20 năm để xây dựng và đối với cộng đồng để nhận ra chúng. (Đó không phải là sự ngạo mạn, nhiều giao thức web như MathML, SVG hoặc RDF đã có những khởi đầu chật vật nhưng bây giờ là dòng chính).

Tôi từng có liên quan nhiều trong XML và quản lý danh sách thư XML-DEV - nó đã có 10.000 thư điện tử một năm và từng là cơ sở nơi mà cộng đồng đã phát triển XML. Tôi tự hào nhất về giao thức SAX từng hoàn toàn được phát triển trong danh sách đó trong 4 tuần. Tất cả XML này không chỉ trao cho tôi cơ sở cho ngôn ngữ đánh dấu hóa học - CML (Chemical Markup Language), mà còn dẫn dắt tới một cuộc tư vấn với JB ở Luân Đôn, đưa ra sự huấn luyện trong XML. Việc quản lý các khóa học có thể là công việc khó khăn nhưng đủ đáng làm để sống từ nó. (Đây từng là công việc thứ 3 của tôi). Rồi, tôi đã thấy tai ương cho hạ tầng không gian mạng trong hóa học ở Cambridge (Trung tâm Unilever) nơi mà một trong những trụ cột từng huấn luyện. Vì kinh nghiệm của tôi mà tôi đã có khả năng tạo ra và phân phối các khóa huấn luyện và điều này đã dẫn tới cuộc gặp ở Bộ (Đây từng là công việc thứ 4 của tôi).

Cambridge đã trao cho tôi các tài nguyên lớn (đặc biệt qua chương trình eScience 250 triệu bảng do Tony Hey ở Southampton quản lý). Tôi đã định ra mục tiêu cho mình xây dựng một nhà hóa học trí tuệ nhân tạo (AI) (dù tôi đã không làm ồn ào về nó). Nó đã dựa vào tri thức và các module mã mà tôi đã và đang xây dựng trong 10 năm. Tôi đã bắt đầu xây dựng nó tất cả tự mình trong Java. Tôi đi tới một giai đoạn nơi mà tôi bổ sung thêm các hình đồ họa, sử dụng Java3D. Java3D từng là kinh sợ; một bộ đóng góp trong mã C và các tệp nhị phân đóng. Nó từng ngốn thời gian của tôi rất nhiều. Có lẽ tôi đã sử dụng sớm hơn XMol, nó là trình xem phân tử của Dan Gezelter mà chạy dưới X Windows. Ở giai đoạn đó, là khá cơ bản và Java từng là một tiếp cận tốt hơn. Tôi sau đó đã lưu ý tính cấp bách của Jmol, bản chuyển sang Java. Tôi đã bỗng nhiên nghĩ: “Nếu tôi không thử hoàn thiện với Jmol, tôi có thể làm mọi điều mà tôi thực sự muốn làm (ngữ nghĩa hóa học)”. Vì thế, tôi đã quyết định băm mã của tôi và liên kết vào Jmol ở giai đoạn đó.

Đó thực sự là một quyết định quan trọng trong sơ đồ của mọi điều. Dù tôi thường hành động cởi mở, tôi đã nhận thức được về nó ở thời điểm này và đã bắt đầu tìm kiếm các kho mã khác để liên kết. Việc hợp nhất kiến trúc từng là Ngôn ngữ Đánh dấu Hóa học - CML. CML được thiết kế để hỗ trợ hầu hết hóa học ở dạng ngữ nghĩa. Vì tôi từng cộng tác với các nhóm mã khác - CDK, Bioclipse, Jmol, JSpecview, OpenBabel, ... - chúng đã áp dụng CML. Đây từng là một cộng đồng lớn và nhiều hơn bất kỳ nhà sản xuất thương mại nào có thể đạt được.

Không ai sẽ viết mã cho một đối thủ nhưng nhiều người sẽ viết để tương hợp với một người cộng tác. Chúng tôi biết lẫn nhau, và trong năm 2005 hầu hết chúng tôi đã gặp nhau ở Xã hội Hóa học Mỹ - ACS (American Chemical Society) dưới tháp xanh ở San Diego. Tôi đã gợi ý chúng tôi thành lập một cộng đồng gần gũi, không chính thức dưới cái tên Blue Obelisk và rằng chúng tôi áp dụng câu thần chú: dữ liệu mở, các tiêu chuẩn mở, nguồn mở - ODOSOS. Chúng tôi có một danh sách thư và đôi lúc tôi coi Blue Obelisks như phần thưởng cho những đóng góp có giá trị một cách công khai. Có một thỏa thuận chung để tương hợp nhưng không kiểm soát trở xuống. Nó chỉ xảy ra theo cách riêng của nó và ở tốc độ riêng của nó. Chúng tôi đã rà soát lại 5 năm và đã có 20 nhóm taccs giả tài liệu, nó là một thành tích đáng ghi nhận cho một nguyên tắc rất bảo thủ (hóa học) nơi mà các công ty có tiếng tăm có giá trị nhiều hơn so với sự đổi mới.

Và nhà hóa học trí tuệ nhân tạo ư? Những gì tôi chưa biết là tôi không thể xây dựng trên tri thức vì các nhà đầu tư được phong có thể ném các luật sư để dừng nó. “Các ông chủ” của các dữ liệu chính đấu tranh để ngăn chặn sử dụng lại các dữ liệu. Khi Wikipedia muốn sử dụng các số đăng ký CAS họ có một bức thư hợp pháp từ ACS. Khi NIH đã phát triển một cơ sở dữ liệu tự do các thông tin hóa học (PubChem), ACS đã vận động hành lang Quốc hội nhờ nó đóng lại. Vì thế, tôi đã phát triển các công cụ để trích xuất các số liệu từ tư liệu khoa học; Các nhà xuất bản STM đang ném tiền và các nhà vận động hành lang ở Brussels sẽ dừng nó xảy ra. Không ngạc nhiên là tôi bây giờ được biết như là một nhà hoạt động xã hội (xem khoản Wikipedia của tôi).

Chúng ta không thể làm khoa học hiện đại trừ phi nó là mở. Và tôi đang tìm kiếm các đồng minh. Năm ngoái tôi đã áp dụng cho một học bổng của Quỹ Shuttleworth (Chúng tôi cấp vốn cho các nhà lãnh đạo năng động đang đứng ở tiền tiêu của sự thay đổi xã hội). Và, vào tháng 3/2014 tôi đã được thưởng một học bổng (đây là công việc thứ 5 của tôi trong nguồn mở). Chúng tôi sẽ trích 100 triệu số liệu từ tư liệu dù các nhà xuất bản có thích điều đó hay không, vì chúng tôi đã có luật được thay đổi.

Đối với các viện sĩ, câu hỏi là: Liệu nguồn mở có thể cho bạn một công việc hay không? Câu trả lời của tôi là: bản thân nó có lẽ sẽ không cho bạn một vị thế giảng bài, nhưng tất cả nhóm của tôi từng có khả năng có các công việc tốt trong nền công nghiệp công nghệ cao, hoặc khoa học. Tôi nghĩ sự mở ra công khai con đường nguồn mở đã giúp. Tôi rất tự hào về họ.

Open is about sharing and collaboration. It's the idea that "we" is more powerful, more rewarding and fulfilling than "I". I can't promise jobs, but I do know that open is becoming very big. Governments and funders are pushing the open agenda, even though academics are generally uninterested or seriously self-interested.

Some governments and some companies recognize the value of teams; academia and academics generally don't. The false values of impact factor and the false values of academic publishing mean that open access is a poor reflection of open, or what you may recognize as the open source way.

I first started thinking about code re-use in 1980 when I had developed an approach to re-using crystallographic data as a research tool. Crystals were published as tens of thousands of single papers; my vision was that by using all of these together we'd discover patterns that would show new science. In particular, myself and my collaborators showed that snapshots of a crystal in different environments could give information on vibrations and even chemical reactions. I wrote lots of software in FORTRAN IV. It built on Sam Motherwell's great CONNSER and GEOM packages. I built on a whole raft of statistical and analytical tools, and we published papers together.

Then, I went into pharmaceutical industry to use these ideas in drug discovery and donated the software to an organization, on the basis that if they wanted to develop it they would contact me and we would work jointly together. It didn't happen. This was before licences, before RMS, before people worried about ownership. The software got subsumed into their system, and my name got removed. I even sat through a lecture where they presented it as their own. I've gotten over it now, but I've learned.

The code was very complex, and I realised that there must be a better way, where we write re-usable modules. I'd been impressed with NAG and took the modular approach as central. It was difficult to do this in chemistry as it's less clear what the fundamentals are. You can write a matrix diagonalizer becasue it's clear what the inputs and outputs are, but it's less clear how to calculate a molecular mass (it's harder than it looks—remember isotopes!?) So I started writing a reusable set of routines in 1990 in FORTRAN. At that stage, I was also giving evening lectures at Birkbeck College on bio- and chemo-informatics and took these modules to the students. The problem was that languages were changing, and so I converted them to C using f2c (it works, but don't look at the generated code!). Then, I discovered tcl/tk and loved it because of the graphics—soon after which I was discovered by a salesmen from Sun Microsystems.

They found me only because I was much more visible than others.

In 1994 Henry Rzepa and I had developed Chemical MIME—this was an open project (though not formally labelled) where we generated a chemical meme that swept the web in six weeks. It relied on the open programs RasMol and Mage, which we could freely distribute to run in browsers. Chemical MIME was the ideal open project: open specs, open software, and enough open molecules to give it a WOW factor! That visibility gave me my first (part-time) consultancy job and kept me alive for some years after I left Glaxo. At the same time, Alan Mills and I ran the first multimedia course on the web (1995), Principles of Protein Structure. We ran it in a derivative of BioMOO and the Globewide Network Academy; they were all completely open projects stemming from LambdaMOO (Pavel Curtis, Xerox). PPS showed the value of community, and we had 250 volunteers/students (we didn't distinguish) on the course. And, the PPS got me my second job, as a part-time Professor of Pharmacy at Nottingham, setting up virtual educations.

We were all optimists and thought that it would take off rapidly, but we failed to realise that education is ultra-conservative and has to map into real-world constraints. For me, in 1993, the world wide web was transforming because there were no barriers. It engendered open systems, sources, and protocols. They were so prevalent you didn't think about them. We don't realise how powerful a force Tim Berners-Lee has been for open. As I whirled along in a portfolio career of research, consultancy, hacking, I was able to stay alive and develop my ideas. It's worked well for me as some of these ideas have needed 20 years to build and for the community to realise them. (That's not arrogance, many web protocols like MathML or SVG or RDF have had stuttering starts but are now mainstream.)

I was very heavily involved in XML and ran the XML-DEV mailing list—it had 10,000 emails a year and was the basis whereby the community developed XML. I'm most proud of the SAX protocol which was entirely developed on the list in 4 weeks. All this XML not only gave me the basis for the Chemical Markup Language (CML) but lead to a consultancy with JB in London, delivering training in XML. Running courses can be hard work but rewarding enough to gain a living from it. (This was my third job.) Then, I saw the advert for Cyberinfrastructure in Chemistry in Cambridge (Unilever Centre) where one of the pillars was training. Because of my experience I was able to create and deliver training courses and this led to my appointment in the Department (This was my fourth job).

Cambridge gave me great resources (especially through the 250 million GBP eScience program run by Tony Hey in Southampton). I set the goal for myself of building an artificially intelligent (AI) chemist (though I didn't make much noise about it). It was to be based on knowledge and code modules that I had been building for 10 years. I started building it all myself in Java. I got to one stage where I added graphics, using Java3D. Java3D was awful; a wrapper on C code and closed binary. It was consuming my time to too great of an extent. I'd earlier used XMol, which is Dan Gezelter's molecular viewer that ran under X windows. At that stage, it was fairly basic and Java was a better approach. I then noticed the emergence of Jmol, the port to Java. I suddenly thought: "If I don't try to compete with Jmol, I can do the things I really want to do (chemical semantics)." So, I decided to junk my code and link in Jmol at that stage.

This was a really important decision in the scheme of things. Although I generally acted openly, I wasn't really conscious of the open source way in terms of licensing and commitments. But, I became aware of it at this point and started to look for other codebases to link. The uniting architecture was Chemical Markup Language. CML is designed to support most of chemistry in semantic form. Because I was collaborating with the other code groups—CDK, Bioclipse, Jmol, JSpecview, OpenBabel, etc—they adopted CML. This was a massive community win and more than any commercial manufacturer can achieve.

No one will write code for a competitor but many will write to interoperate with a collaborator. We got to know each other, and in 2005 most of us met at the American Chemical Society (ACS) under the blue obelisk in San Diego. I suggested we form a close, informal community under the label Blue Obelisk and that we adopt the mantra: open data, open standards, open source (ODOSOS). We have a mailing list and at intervals I buy Blue Obelisks as awards for publicly valuable contributions. There's a communal agreement to interoperate but no downwards control. It just happens in its own way and at its own speed. We reviewed 5 years on and had 20 groups authoring the paper, which is a remarkable achievement for a very conservative discipline (chemistry) wher established companies are more valued than innovation.

And the AI chemist? What I hadn't reckoned on is that I couldn't build on knowledge because vested interests would throw lawyers to stop it. The major data "owners" fight to prevent re-use of data. When Wikpedia wanted to use CAS registry numbers they got a legal letter from ACS. When NIH developed a free database of chemical information (PubChem), the ACS lobbied Congress to have it closed down. So, I have developed tools to extract facts from the scientific literature; the STM publishers are throwing money and lobbyists at Brussels to stop it happening. It's no surprise that I am now known as an open activist (see my Wikipedia entry).

We cannot do modern science unless it's open. And, I am looking for allies.

Last year I applied for a Shuttleworth Foundation Fellowship (We provide funding for dynamic leaders who are at the forefront of social change.) And, in March 2014 I was awarded one (This was my fifth job in open source). We are going to extract 100 million facts from the literature whether or not the publishers like it, because we've had the law changed.

For my fellow academics, the question is: Can open source get you a job? My answer is: By itself it probably won't get you a lectureship, but all my group have been able to get good jobs in the high-tech industry, or science. I think the public exposure of the open source way has helped. I'm very proud of them.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com

Chủ Nhật, 24 tháng 8, 2014

Sự tăng trưởng của Linux đòi hỏi kho người tài lớn hơn

Linux Growth Demands Bigger Talent Pool

By Jim Zemlin - August 20, 2014 – 6:19am

Theo: http://www.linuxfoundation.org/news-media/blogs/browse/2014/08/linux-growth-demands-bigger-talent-pool

Bài được đưa lên Internet ngày: 20/08/2014

Lời người dịch: Quỹ Linux đã khởi xướng Chương trình cấp Chứng chỉ của Quỹ Linux (The Linux Foundation Certification Program). Điều này để cung cấp các tài năng chuyên nghiệp về Linux mà hiện thị trường đang rất thiếu. Lý do: “Linux ngày nay trang bị cho hầu hết các hạ tầng công nghệ từ các hệ thống nhúng, các thiết bị di động và các đồ điện tử dân dụng cho tới đám mây, máy chủ chuyên nghiệp, điện toán hiệu năng cao và hơn thế nữa”. Khảo sát về kho nhân tài Linux năm 2013 cho thấy: “93% các nhà quản lý đi thuê nhân viên đã nói các kế hoạch thuê những người chuyên nghiệp Linux năm nay. 90% nói khó tìm tài năng đó (tăng 5% so với năm 2013)”.

Hôm nay tại LinuxCon và CloudOpen chúng tôi đửa ra một tuyên bố rằng thông báo bước tiếp theo trong việc giúp xây dựng một kho tài năng đủ điều kiện của những người chuyên nghiệp về Linux khắp thế giới: Chương trình cấp Chứng chỉ của Quỹ Linux (The Linux Foundation Certification Program).

Chúng tôi tìm cách tạo ra một chương trình chứng chỉ Linux mà là có tính đổi mới, được đánh giá cao giữa các nhà chuyên nghiệp và các ông chủ Linux và tiến bộ hiện đại của các cuộc thi cấp chứng chỉ. Chúng tôi nghĩ đây là một tiếp cận khác cho việc kiểm thử và có thể giúp tiến bộ Linux bằng việc mang nhiều hơn tài năng Linux vào thị trường. Các cuộc thi là sẵn sàng bất kỳ khi nào, bất kỳ ở đâu; sự thực thi dựa vào việc kiểm thử trong dòng lệnh; và sự phân phối là mềm dẻo.

Hãy để cho tôi nói cho bạn một chút nhiều hơn về việc vì sao chúng tôi tin tưởng điều này là rất quan trọng. Linux ngày nay trang bị cho hầu hết các hạ tầng công nghệ từ các hệ thống nhúng, các thiết bị di động và các đồ điện tử dân dụng cho tới đám mây, máy chủ chuyên nghiệp, điện toán hiệu năng cao và hơn thế nữa.

Kết quả là một sự thiếu hụt toàn cầu những người chuyên nghiệp Linux có đủ phẩm chất để hỗ trợ cho sự tăng trưởng nhanh này. Linux từng là dự án nguồn mở chính đầu tiên thấy được sự áp dụng rộng khắp và ngày nay là dự án phát triển cộng tác lớn nhất trong lịch sử điện toán. Chúng tôi đang trải nghiệm ngày hôm nay các kết quả của thành công đó và đang đi tiên phong con đường cho các ông chủ để đánh giá tài năng Linux và để tài năng đó có khả năng thể hiện các kỹ năng của họ. Và, chúng tôi không nói về khả năng của họ để trả lời các câu hỏi cho đúng. Chúng tôi nói về khả năng của những người chuyên nghiệp Linux có khả năng giải quyết các kịch bản thế giới thực trong dòng lệnh. Không mắc sai lầm, các Chứng chỉ của Quỹ Linux là khó.

Họ nên tới để trình bày thứ tốt nhất của tốt nhất trong thị trường việc làm Linux.

Chương trình tới ở gót chân của mối quan hệ đối tác của chúng ta với edX để khởi xướng chương trình 'Giới thiệu Linux' tới Khóa học Trực tuyến Mở diện rộng - MOOC (Massive Open Online Course) chưa từng có. Với hơn 230.000 người đã đăng ký thì nó là các khóa học phổ biến nhất từ trước tới nay trong nền tảng edX. Và nhiều năm chúng tôi đã và đang cung cấp thông tin giáo dục để giúp gia tăng sự cung ứng nhân tài về Linux. Chúng tôi xuất bản hàng trăm sách chỉ dẫn, các sách trắng và các báo cáo nghiên cứu gốc; các chương trình đỡ đầu, các cuộc thi Hackathon, các tài liệu truyền tay, các cuộc gặp gỡ của các lập trình viên và một chương trình học bổng huấn luyện Linux tìm kiếm sau cao độ; tham gia vào Mùa hè Mã của Google (Google Summer of Code); và cung cấp sự huấn luyện cho các lập trình viên cả tải chỗ và trong lớp học, cũng như huấn luyện pháp lý. Chương trình cấp chứng chỉ mới mang tới yếu tố khác, sống còn cho công việc của chúng ta ở đây: Gia tăng số lượng những người chuyên nghiệp có chất lượng về Linux.

Chúng tôi thừa nhận tiếp cận của chúng tôi về chứng chỉ là khác. Chúng tôi đã cố gắng làm cho nó tương tự như cách mà Linux được phát triển: sẵn có bất kỳ lúc nào, bất kỳ ở đâu để gia tăng sự truy cập tới nhiều người hơn ở nhiều địa điểm hơn trên khắp thế giới. Một webcam và mirophone được yêu cầu và một người giám thị giám sát cuộc thi để giảm thiểu sự cư xử xấu. Các nhiệm vụ được hoàn thành trong dòng lệnh. Đây là thế giới thực và Linux chạy trên các hệ thống quan trọng. Những người chuyên nghiệp Linux phải biết cách làm việc với bất kỳ điều gì. Đây là sự phân phối mềm dẻo. Linux là về sự lựa chọn và mỗi người có sự ưa thích của họ. Chúng tôi đã bắt đầu với 3 trong số các họ phát tán được sử dụng phổ biến nhất và kỳ vọng các ứng viên tiếp tục lấy các chứng chỉ đặc thù phát tán khi họ đi xa hơn trong sự nghiệp của họ.

93% các nhà quản lý đi thuê nhân viên đã nói các kế hoạch thuê những người chuyên nghiệp Linux năm nay. 90% nói khó tìm tài năng đó (tăng 5% so với năm 2013). Chúng tôi hy vọng Chương trình Chứng chỉ Linux có thể giúp gia tăng kho người tài đủ điều kiện cho Linux và hỗ trợ sự chín muồi và sự tăng trưởng của nền tảng công nghệ ở khắp mọi nơi nhất thế giới này.

Today at LinuxCon and CloudOpen we're making an announcement that signifies the natural next step in helping to build a qualified talent pool of Linux professionals worldwide: The Linux Foundation Certification Program.

We sought to create a new Linux certification program that is innovative, highly valued among Linux pro’s and employers and advances the state-of the-art of certification exams. We think it's a different approach to testing and can help advance Linux by bringing more Linux talent into the market. The exams are available anytime, anywhere; performance based with testing in the command line; and distribution flexible.

Let me tell you a bit more about why we believe this is so important. Linux today powers most of the technology infrastructure that runs our daily lives. It is the fastest growing platform in nearly every sector of technology from embedded systems, mobile devices and consumer electronics to the cloud, enterprise server, high performance computing and more.

The result has been a global shortage of qualified Linux pros to support this rapid growth. Linux was the first major open source project to see widespread adoption and today is the largest collaborative development project in the history of computing. We're experiencing today the results of that success and are pioneering a way for employers to assess Linux talent and for that talent to be able to demonstrate their skills. And, we're not talking about their ability to answer questions correctly. We're talking about the ability of Linux professionals to be able to address real-world scenarios in the command line. Make no mistake, The Linux Foundation Certifications are difficult. They should come to represent the best of the best in the Linux job market.

The program comes on the heels of our partnership with edX to launch the first-ever 'Intro to Linux' Massive Open Online Course (MOOC). With more than 230,000 people registered it's among the most popular courses ever on the edX platform. And, for years we've been providing educational information to help increase the supply of Linux talent. We publish hundreds of tutorial, white papers and original research reports; host mentoring programs, Hack-a-Thons, hangouts, developer meetups and a highly sought-after Linux training scholarship program; participate in Google Summer of Code; and provide developer training both onsite and in the classroom, as well as legal training. The new Certification Program brings another, critical element to our work here: Increasing the number of professional, qualified Linux pro’s.

We admit our approach to certification is different. We tried to make it similar to how Linux is developed: available anytime, anywhere in order to increase access to more people in more places around the world. A webcam and microphone are required and a human proctor monitors the exam to minimize misconduct. Tasks are completed in the command line. This is the real world and Linux runs important systems. Linux pro’s must know how to deal with anything. It’s distribution-flexible. Linux is about choice and everyone has their preference. We’ve started with three of the most commonly-used distribution families and expect candidates to move on to distributions-specific certifications as they get further into their careers.

Ninety-three percent of hiring managers have reported plans to hire Linux pro’s this year. Ninety percent say it’s difficult to find that talent (a five-point increase since 2012). We’re hoping the Linux Certification Program can help increase the qualified talent pool for Linux and support the maturity and growth of the world’s most ubiquitous technology platform.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com

Cha đẻ của mã hóa PGP: Các công ty viễn thông cần phải ra khỏi giường với các chính phủ

Father of PGP encryption: Telcos need to get out of bed with governments

Silent Circle của Zimmermann làm việc với Dutch telco để đưa ra các cuộc gọi được mã hóa.

Zimmermann’s Silent Circle working with Dutch telco to deliver encrypted calls.

by Sean Gallagher - Aug 10 2014, 12:35am ICT

Theo: http://arstechnica.com/tech-policy/2014/08/father-of-pgp-encryption-says-telcos-need-to-get-out-of-bed-with-government/

Bài được đưa lên Internet ngày: 10/08/2014

Lời người dịch: Còn nhớ, trong làn sóng các tiết lộ của Edward Snowden về chương trình giám sát ồ ạt của NSA, chưa tới 24 giờ sau khi công ty chuyên cung cấp dịch vụ thư điện tử có mã hóa LavaBit bị đóng cửa, một công ty có dịch vụ thư điện tử có mã hóa tương tự, Silent Circle cũng đã bị đóng cửa. Còn nay có lẽ thời thế đã khác, nhà đồng sáng lập ra Silent Circle và là người tạo ra mã hóa công khai Pretty Good Privacy, Phil Zimmermann, đã và đang triển khai tiêu chuẩn mã hóa của công ty với đối tác của họ tại các nước như Hà Lan, Bỉ và Đức. Ông cũng kịch liệt phản đối tiêu chuẩn Bộ sinh số ngẫu nhiên của Viện Công nghệ và Tiêu chuẩn Quốc gia Mỹ - NIST. “Chúng tôi sẽ không sử dụng bộ sinh số ngẫu nhiên ngu xuẩn mà NIST đã làm theo chỉ thị của NSA”, ông nói khi trả lời cho một câu hỏi khán thính phòng của Def Con. “Tôi không thể tưởng tượng vì sao bất kỳ ai có thể sử dụng một bộ sinh số ngẫu nhiên ngu xuẩn như vậy”. Xem thêm: Chương trình gián điệp của NSA trên không gian mạng.

LAS VEGAS—Phil Zimmermann, người tạo ra mã hóa khóa công khai Pretty Good Privacy, có một vài kinh nghiệm khi nói về chính trị của mật mã. Trong “cuộc chiến mật mã” của những năm 1990, Zimmermann đã đấu tranh để thuyết phục chính phủ Mỹ dừng phân loại PGP như một “thứ đạn dược” và đóng cửa chương trình Cipper Chip - một nỗ lực tạo ra một vi xử lý mã hóa bắt buộc cho chính phủ mà có thể đã trao cho NSA một cửa hậu trong tất cả các giao tiếp truyền thông điện tử được mã hóa. Bây giờ Zimmermann và công ty mà ông đã đồng sáng lập đang làm việc để thuyết phục các công ty viễn thông - hầu hết ở nước ngoài - rằng đã tới lúc chấm dứt mối quan hệ gần như ấm cúng nhiều thế kỷ của chúng tới các chính phủ.

Zimmermann đã so sánh tư duy của các công ty điện thoại với lòng tin có từ lâu rằng cà chua từng chia cho tới khi nó từng được trình diễn là không phải thế. “Từ lâu, từ hàng trăm năm, các công ty điện thoại khắp thế giới đã tạo ra một văn hóa xung quanh bản thân họ rằng rất cộng tác với các chính phủ trong việc can thiệp vào tính riêng tư của mọi người. Và các công ty điện thoại đó có xu hướng nghĩ rằng không có cách nào khác - rằng họ không thể thoát được văn hóa này, rằng cà chua là độc hại”, ông nói.

Lời gọi vì mật mã

Ngược về năm 2005, Zimmermann, Alan Johnston, và Jon Callas đã bắt đầu làm việc về một giao thức cho các cuộc gọi điện thoại theo tiếng nói qua IP (VoiP), gọi là ZRTP, như một phần của dự án Zfone của ông. Trong năm 2011, ZRTP đã trở thành một Internet Engineering Task Force RFC, và nó từng xuất bản nhưlà nguồn mở theo một giấy phép BSD. Nó cũng là cơ sở của dịch vụ tiếng nói cho Silent Circle, dịch vụ tiếng nói được mã hóa điểm - điểm (end-to-end) mà Zimmermann đồng sáng lập với cựu sỹ quan của Navy SEAL Mark Janke. Silent Circle, mà Ars đã thử trên Blackphone vào tháng 6, là một dịch vụ thông điệp tiếng nói và chết sớm dựa vào ZRTP mà sinh ra các khóa đặc thù cho phiên làm việc giữa những người sử dụng để mã hóa từ điểm này tới điểm kia. Cuộc gọi được đi trong hầm qua một kết nối được mã hóa an ninh tầng vận tải (Transport Layer Security) thông qua các máy chủ của Silent Circle ở Canada và Thụy Sỹ. Các cuộc gọi ZRTP và của Silent Circle không dựa vào PGP hoặc bất kỳ hạ tầng khóa công khai nào khác, nên không có các khóa để trao theo một lệnh FISA hoặ lệnh ép tuân thủ luật nào.

Bây giờ, nhờ phần lớn những phát hiện từ việc giám sát viễn thông của NSA và GCHQ đã là bật dậy từ các tài liệu rò rỉ từ Edward Snowden, có một đòi hỏi thị trường đang gia tăng cho tính riêng tư của các cuộc gọi - và các công ty viễn thông, đặc biệt ở châu Âu, đã trở nên dễ lĩnh hội hơn về việc trao cho các khách hàng sức mạnh để bảo vệ tính riêng tư của họ. Vào tháng 2, nhà truyền tảy viễn thông Hà Lan KPN đã ký một thỏa thuận trở thành nhà cung cấp độc quyền của dịch vụ gọi tiếng nói được mã hóa của Silent Circle ở Hà Lan, Bỉ và Đức. Công ty này đã bắt đầu chào các dịch vụ của Silent Circle cho các khách hàng vào mùa hè này.

Động thái đó đã được dẫn dắt, Zimmermann nói, boửi giám đốc an ninh thông tin của KPN, Jây Baloo. “Bà đã quyết định bà muốn thoát khỏi hàng ngũ từ phần còn lại các công ty điện thoại và làm cho KPN chào tính riêng tư cho các khách hàng của họ”, Zimmermann nói. “Nên lần đầu tiên, bạn thấy một công ty điện thoại chào tính riêng tư thực sự. Hy vọng của tôi là các công ty điện thoại khác sẽ thấy cà chua là không độc hại”.

Phòng vệ thông qua sự phụ thuộc

Một phần nhờ các kết nối của Janke, dịch vụ đã được Navy SEALS chấp nhận - không chỉ cho việc gọi nội địa, mà cho các giao tiếp truyền thông chiến dịch, cũng như các lực lượng tác chiến đặc biệt của Canada, Anh và Úc, các thành viên Quốc hội Mỹ và ép tuân thủ luật Mỹ. “Khoảng 1 năm trước chúng tôi đã có một chuyến viếng thăm từ FBI trong văn phòng của chúng tôi”, Zimmermann nói. “Mike Janke đã gọi và nói, 'FBI từng ở trong văn phòng của chúng tôi hôm nay', và tôi nói, 'Ồ không, điều đó đã bắt đầu rồi'. Và anh ta nói, 'Không, không, học chỉ ở đây để hỏi về giá'”.

Tất cả điều này trong chiến lược của Zimmermann để giữ cho các cơ quan chính phủ khỏi ép vì các cửa hậu trong dịch vụ của Silent Circle. “Tôi nghĩ những gì chúng tôi cần là, chúng tôi cần tạo ra các điều kiện nơi mà không ai sẽ học trên chúng tôi vì các cửa hậu vì họ cần nó cho bản thân họ. Nếu Navy SEAL đang sử dụng điều này, nếu chính phủ của riêng chúng ta phát triển một sự phụ thuộc vào nó, thì họ sẽ nhận thức được rằng nó có thể phản tác dụng đối với họ để có một cửa hậu trong sản phẩm của chúng tôi. Bây giờ có lẽ nó là một sự thừa thận trọng, vì họ chưa bao giờ yêu cầu cho một cửa hậu trong PGP, nhưng mất nhiều năm để nhân giống thứ đó vào trong các khách hàng chính phủ. Chúng tôi đã thấy các khách hàng chinh sphủ lấy thứ này ngay khi sản phẩm sẵn sàng - trong thực tế trước khi sản phẩm sẵn sàng thì họ đã hỏi về nó. Vì thế chúng tôi đã tạo ra một tình huống nơi mà khó cho họ thậm chí đưa gợi ý về một cửa hậu”.

Điều đó không nói lên rằng mọi điều đã trải qua trơn tru. Công ty của Zimmermann đã phải bỏ dịch vụ thư điện tử an ninh của mình trong làn sóng đóng cửa của LavaBit. “Chúng tôi đã quét sạch toàn bộ dịch vụ thư điện tử an ninh của chúng tôi - các sao lưu, và mọi thứ”, Zimmermann đã nói cho khán thính phòng của Def Con. “Một số khách hàng của chúng tôi đã tức giận, nhưng đối với đa số họ hiểu chúng tôi đã bảo vệ tính riêng tư của họ”.

Trao cho NIST (và RSA) ngón thay thối

Kinh doanh với các khách hàng của chính phủ Mỹ thường đòi hỏi sử dụng các tiêu chuẩn mã hóa của Viện Tiêu chuẩn và Công nghệ Quốc gia - NIST (National Institute of Standards and Technology). Nhưng mặc định, Zimmermann nói, Silent Circle sử dụng một tập hợp các công cụ mã hóa thay thế.

“Đã không vì đã có mọi điều thực sự sai với các thuật toán của NIST”, Zimmermann giải thích. “Sau những tiết lộ của Snowden, chúng tôi cảm thấy hơi phẫn uất rằng NIST đã cộng tác với NSA”.

Ông tiếp tục, “vì thế diễn tả sự không bằng lòng của chúng tôi với NIST, chúng tôi đã chào các thuật toán lựa chọn thay thế. Chúng tôi đang sử dụng một đường cong ellip mới (thuật toán mã hóa) mà chúng tôi đã cam kết với Dan Bernstein sẽ làm cho chúng tôi, chúng tôi sử dụng một mật mã khối 2 cá (Twofish block cypher), và chúng tôi sử dụng Skein như là hàm băm của chúng tôi”.

Silent Circle chào các thuật toán NIST như là một sự lựa chọn. Nhưng ông tận dụng cơ hội để sử dụng điều ngược lại đối với tiêu chuẩn sinh số ngẫu nhiêu bây giờ bị phản đối của NIST - một tiêu chuẩn mà đã bị NSA can thiệp vào để cung cấp một cách thức để phá mã hóa - để đào sâu hơn một chút trong một kẻ thù cũ. “Chúng tôi sẽ không sử dụng bộ sinh số ngẫu nhiên ngu xuẩn mà NIST đã làm theo chỉ thị của NSA”, ông nói khi trả lời cho một câu hỏi khán thính phòng của Def Con. “Tôi không thể tưởng tượng vì sao bất kỳ ai có thể sử dụng một bộ sinh số ngẫu nhiên ngu xuẩn như vậy. Mà hình như RSA đã sử dụng, và đặt nó vào thư viện thủ tục Bsafe, nó là nguồn đóng. Nực cười, ngược về những năm 90, ngược về khi mà RSA đã bắt đầu cuộc điều tra tội phạm chống lại tôi bằng việc gọi ủy viên công tố và yêu cầu ông ta cho tôi vào tù, họ nói RSA từng là cái tên đáng tin cậy nhất trong mật mã... Vì thế, thật buồn cười rằng chúng ta đã thấy hôm nay rằng họ đã được trả 10 triệu USD để đặt một bộ sinh số ngẫu nhiên do NSA thiết kế vào thư viện thủ tục của họ”.

LAS VEGAS—Phil Zimmermann, the creator of Pretty Good Privacy public-key encryption, has some experience when it comes to the politics of crypto. During the “crypto wars” of the 1990s, Zimmermann fought to convince the US government to stop classifying PGP as a “munition” and shut down the Clipper Chip program—an effort to create a government-mandated encryption processor that would have given the NSA a back door into all encrypted electronic communication. Now Zimmermann and the company he co-founded are working to convince telecommunications companies—mostly overseas—that it’s time to end their nearly century-long cozy relationship with governments.

Zimmermann compared telephone companies’ thinking with the long-held belief that tomatoes were toxic until it was demonstrated they weren’t. “For a long time, for a hundred years, phone companies around the world have created a culture around themselves that is very cooperative with governments in invading people’s privacy. And these phone companies tend to think that there’s no other way—that they can’t break from this culture, that the tomatoes are poisonous," he said.

A call for crypto

Back in 2005, Zimmermann, Alan Johnston, and Jon Callas began work on an encryption protocol for voice over IP (VoIP) phone calls, dubbed ZRTP, as part of his Zfone project. In 2011, ZRTP became an Internet Engineering Task Force RFC, and it has been published as open source under a BSD license. It’s also the basis of the voice service for Silent Circle, the end-to-end encrypted voice service Zimmermann co-founded with former Navy SEAL Mark Janke. Silent Circle, which Ars tested on the Blackphone in June, is a ZRTP-based voice and ephemeral messaging service that generates session-specific keys between users to encrypt from end to end. The call is tunneled over a Transport Layer Security-encrypted connection through Silent Circle’s servers in Canada and Switzerland. ZRTP and the Silent Circle calls don’t rely on PGP or any other public key infrastructure, so there’s no keys to hand over under a FISA order or law enforcement warrant.

Now, thanks largely to the revelations of NSA and GCHQ monitoring of telecommunications triggered by documents leaked by Edward Snowden, there’s a growing market demand for call privacy —and telecom companies, especially in Europe, have become more receptive to the idea of giving customers the power to protect their privacy. In February, Dutch telecommunications carrier KPN signed a deal to be the exclusive provider of Silent Circle’s encrypted voice call service in the Netherlands, Belgium, and Germany. The company started offering Silent Circle services to customers this summer.

That move was driven, Zimmermann said, by KPN’s chief information security officer, Jaya Baloo. “She decided she wanted to break ranks from the rest of the phone companies and get KPN to offer their customers privacy,” Zimmermann said. “So for the first time, you see a phone company offer real privacy. My hope is that other phone companies will find the tomatoes are not poisonous.”

Defense through dependency

Thanks in part to Janke’s connections, the service has been adopted by the Navy SEALS—not just for calling home, but for operational communications, as well as Canadian, British, and Australian special operations forces, members of the US Congress and US law enforcement. “About a year ago we had a visit from the FBI in our office,” Zimmermann said. “Mike Janke called and told, ‘The FBI was in our office today,’ and I said, ‘Oh no, it’s started already.’ And he said, ‘No, no, they were just here to ask about pricing.”

All of this plays into Zimmermann’s strategy to keep government agencies from pressing for backdoors into Silent Circle's service. “I thought what we need is, we needed to create the conditions where nobody was going to lean on us for backdoors because they need it themselves. If Navy SEALs are using this, if our own government develops a dependency on it, then they’ll recognize that it would be counter-productive for them to get a backdoor in our product. Now maybe it was an overabundance of caution, because they never asked for a backdoor in PGP, but that took years to get that propagated into government customers. We saw government customers take this up almost as soon as the product was ready—in fact before the product was ready they were asking about it. So we’ve created a situation where it’s difficult for them to even bring up the suggestion of a backdoor.”

That’s not to say that everything has gone smoothly. Zimmermann’s company had to abandon its secure email service in the wake of the shutdown of LavaBit. “We wiped out our entire secure email service—backups, and everything,” Zimmermann told the Def Con audience. “Some of our customers were pissed off, but for the most part they understood we were protecting their privacy.”

Giving NIST (and RSA) the finger

Doing business with US government customers generally requires the use of National Institute of Standards and Technology (NIST) standards for encryption. But by default, Zimmermann said, Silent Circle uses an alternative set of encryption tools.

“It wasn’t because there was anything actually wrong with the NIST algorithms,” Zimmermann explained. “After the Snowden revelations, we felt a bit resentful that NIST had cooperated with the NSA."

He continued, “So to express our displeasure at NIST, we offered alternative algorithms. We’re using a new elliptic curve (encryption algorithm) that we commissioned Dan Bernstein to do for us, we use a Twofish block cypher, and we use Skein as our hash function.”

Silent Circle does offer the NIST algorithms as an alternative. But he took the opportunity to use the controversy over the NIST standard’s now-deprecated random number generator standard—one that was crafted by the NSA to provide a way to break encryption—to get in a few digs about an old adversary. “We’re not using the stupid random number generator that NIST did at the behest of the NSA,” he said in response to an Def Con audience question. “I can’t imagine why anyone would use such a stupid random number generator. But apparently RSA did, and put it in their Bsafe subroutine library, which is closed source. It’s funny, back in the 90s, back when RSA started the criminal investigation against me by calling up the prosecutor and asking him to put me in prison, they said RSA was the most trusted name in cryptography…So, it’s ironic that we find today that they were paid $10 million to put an NSA-designed random number generator in their subroutine library.”

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com

Phần mềm tự do nguồn mở cho Việt Nam

Thứ Tư, 27 tháng 8, 2014

Các giáo sư đã nhúng sinh viên trực tiếp vào các cộng đồng nguồn mở

Thứ Ba, 26 tháng 8, 2014

Nâng cấp các thư viện cho hệ thống nguồn mở Koha

Sở hữu trí tuệ & bằng sáng chế phần mềm

Thứ Hai, 25 tháng 8, 2014

Vì sao tất cả các phần mềm của chính phủ lại không phải là nguồn mở nhỉ?

Chúng ta không thể làm khoa học hiện đại trừ phi nó là mở

Chủ Nhật, 24 tháng 8, 2014

Sự tăng trưởng của Linux đòi hỏi kho người tài lớn hơn

Cha đẻ của mã hóa PGP: Các công ty viễn thông cần phải ra khỏi giường với các chính phủ

Nội dung bài theo các nhãn

Các Website yêu thích