16 nguyên tắc của FOSS tất cả các nhà giáo dục nên biết

16 FOSSisms all educators should know

Posted 10 Jun 2014 Bryan Behrenshausen

Theo: https://opensource.com/education/14/6/16-foss-principles-for-educators

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

Xem thêm: Giáo dục mở và tài nguyên, giấy phép tư liệu mở

 

Khi Heidi Ellis trình bày tại hội nghị Kinh nghiệm Mùa hè Nguồn Mở của các Giáo sư vào năm nay (this year's Professors' Open Source Summer Experience) - được tổ chức vào các ngày 28-30/05/2014 tại Đại học Drexel ở Philadelphia - bà đã muốn các đồng nghiệp của bà hiểu được những lợi ích giáo dục vô cùng to lớn của việc lôi kéo các sinh viên vào các dự án nguồn mở.

Và điều gì giúp họ nhận thức được những lợi ích đó tốt bằng sự thông thái được tôi luyện rồi của bản thân các cộng đồng nguồn mở.

Ellis, người đã cùng điều phối POSSE với giáo sư Greg Hislop ở Đại học Drexel, đã nói với đám đông gần 20 thành viên giáo viên từ các trường cao đẳng và đại học khắp đất nước rằng việc nhúng các sinh viên môn khoa học máy tính của họ vào các cộng đồng nguồn mở có thể tạo thuận lợi cho dạng cam kết tham gia mà các kinh nghiệm trong các lớp học truyền thống không thể đưa ra. Nhưng, bà nói, các sinh viên và các giáo sư, giống như nhau, nên chuẩn bị để bị sốc văn hóa một chút nếu họ không được chuẩn bị để ôm lấy cách thức nguồn mở.

Vì thế Ellis đã dẫn nguồn 16 nguyên tắc từ văn hóa phần mềm tự do nguồn mở - những gì bà gọi là “FOSSisms” (các nguyên tắc của FOSS, hoặc chủ nghĩa FOSS) - để giải thích cách mà các giá trị nguồn mở có thể biến đổi giáo dục của khoa học máy tính.

FOSSism #1: Tất cả là về cộng đồng

Việc để sinh viên bắt đầu với nguồn mở ngụ ý yêu cầu họ làm nhiều hơn so với đơn giản chỉ công việc trong một dự án mới. Nó liên quan tới việc yêu cầu họ ra nhập một cộng đồng, Ellis nói. Và “Khi bạn làm thế”, bà nói “bạn đang ra nhập một văn hóa mới”.

Vì thế các sinh viên phải nhanh chóng thích nghi với các chuẩn mực không được nói thành lời của nhóm người với các phương pháp, các ưu tiên, và cả các trò đùa của riêng nó. Khi ra nhập một cộng đồng nguồn mở, các sinh viên nên xác định rằng các kênh giao tiếp ưu tiên của cộng đồng và sử dụng chúng như các cánh cửa dẫn vào văn hóa của nó.

“Cộng đồng dẫn dắt dự án”, Ellis nói, “chứ không phải ngược lại”.

Bằng việc ra nhập các cộng đồng nguồn mở, các sinh viên có được sự truy cập tới các chuyên gia có thể trợ giúp cho họ khi họ bắt đầu vật lộn với những đóng góp của họ. Theo cách này, các thành viên giáo viên có được những người hướng dẫn có giá trị cho các sinh viên của họ.

“Một khi bạn ở trong cộng đồng, bạn là một phần của cộng đồng đó”, Ellis nói. “Đó là một trong những lợi ích. Họ sẽ quan tâm tới các sinh viên của bạn”.

FOSSisms #2: Hãy là sự mất mát có hiệu quả

Phạm vi của bất kỳ dự án hoặc cộng đồng nguồn mở nào cũng vượt quá bất kỳ khả năng của riêng bất kỳ một con người nào để lĩnh hội thấu đáo nó hoàn toàn. Hệ quả là, các sinh viên có thể thấy sự mất mát hoặc lênh đênh trong miền đất không quen thuộc. Nhưng các người chỉ dẫn của họ nên khuyến khích họ sử dụng sự lúng túng của họ một cách có hiệu quả - để nghiên cứu cộng đồng đó và để học về dự án bằng việc đào sâu qua các tư liệu của nó. Giai đoạn mất phương hướng quay cuồng trong đầu là tự nhiên tuyệt vời - thậm chí có lợi - Ellis đã khẳng định với khán thính phòng của bà. Điều y hệt là đúng cho các giáo sư, những người cũng là mới với các dự án nguồn mở được chọn của họ.

“Đây có thể là khái niệm rất xa lạ đối với những người chỉ dẫn”, Ellis nói. “Chúng ta được dạy rằng chúng ta được hỗ trợ để trở thành các chuyên gia của vấn đề chủ đề đó”.

FOSSisms #3: Trao ngược trở lại

Các dự án phần mềm nguồn mở sống sót vì những đóng góp từ những người sử dụng và các lập trình viên, Ellis giải thích, nên các sinh viên phải học để bắt đầu trao ngược trở lại ngay tức thì. Họ nên cập nhật tài liệu, mã kiểm thử, khẳng định các lỗi, trả lời các câu hỏi từ những người khác - lao vào bất kỳ nơi đâu họ có thể. Họ sẽ sớm học được họ không cần phải là các chuyên gia để tạo ra các ảnh hưởng tích cực cho các cộng đồng của họ; họ chỉ cần có thiện chí làm việc. Thậm chí những đóng góp nhỏ nhất là có giá trị, Ellis nói.

FOSSisms #4: Chủ nghĩa cơ hội ngự trị

Vì ít lập trình viên nguồn mở làm việc trong dự án của họ toàn thời gian, việc cạnh tranh các yêu cầu luôn hạn chế khả năng của họ để đóng góp. Vì thế sự phát triển nguồn mở có thể khá là cơ hội chủ nghĩa, Ellis giải thích: sự phát triển diễn ra theo những cố gắng khi các lập trình viên tận dụng các tài nguyên sẵn có. Các sinh viên phải nhận thức được rằng các quy trình phát triển nguồn mở không luôn phản ánh những gì của giới công nghiệp; công việc có thể xảy ra theo từng đợt và bắt đầu phù hợp khả năng của các thành viên cộng đồng.

FOSSisms #5: Nếu điều đó không công khai, thì điều đó không xảy ra

Công việc nguồn mở xảy ra công khai. Các lập trình viên sử dụng các danh sách thư, các kênh chat IRC, và các kênh giao tiếp công khai khác nên mọi người trong cộng đồng - và bất kỳ ai muốn ra nhập cộng đồng - có thể chọn bất kỳ điều gì họ đang làm. Các sinh viên phải trở nên thoải mái với cách làm việc công khai và chia sẻ các tài nguyên của họ, Ellis nói.

“Nếu mọi người không thể thấy họ”, bà nói, thì “họ là không tốt đối với mọi người”.

Sự minh bạch cũng có thể gây hoảng hốt cho cả các giáo sư nữa, Ellis bổ sung.

“Hầu hết các nhà nghiên cứu hàn lâm là thâm căn cố đế và về điều đó và bạn không xuất bản bất kỳ điều gì cho tới khi nó trở nên hoàn hảo”, bà nói. “Trong thế giới nguồn mở, điều đó là hoàn toàn ngược lại”.

FOSSisms #6: Ôm lấy sự minh bạch tận gốc

Vì các cộng đồng nguồn mở tham gia trong phát triển một cách phân tán, họ ôm lấy sự minh bạch tận gốc và các tư liệu họ tạo ra - tất cả tư liệu, mã, và các chế tác khác mà các sinh viên có thể giành lấy để cải thiện việc học hỏi của họ - mặc định là mở, sẵn sàng để sử dụng trong lớp học (và hơn thế).

“Tất cả điều này là con đường giàu, giàu có cho việc học tập”, Ellis nói.

FOSSisms #7: Yêu cầu tha thứ, chứ không yêu cầu sự cho phép

Hầu hết lúc nào cũng vậy, các cộng đồng nguồn mở sử dụng vài dạng kiểm soát phiên bản, Ellis giải thích, nên các sinh viên nên nhận thức được rằng những đóng góp của họ ít có cơ hội làm trệch hướng hoàn toàn một dự án. Họ không cần yêu cầu sự cho phép để vọc với thứ gì đó; họ nên đơn giản bắt đầu làm việc, yêu cầu sự tha thứ của cộng đồng nếu họ làm sai. Thường gặp nhiều hơn là không, các thành viên cộng đồng hiểu và hỗ trợ, vì việc sửa các lỗi lầm mất ít nỗ lực.

FOSSisms #8: Các nhánh là tự do

Các sinh viên vẫn ngần ngại làm việc trực tiếp với kho mã của cộng đồng nên nhớ rằng họ có thể dễ dàng tạo nhánh một dự án đang tồn tại và thay vào đó nghịch với các bản sao cục bộ. Làm điều này có thể giải phóng họ để thực hành. Điều đó có thể làm cho họ sửa được lỗi - một kết quả họ có thể sau đó dễ dàng chia sẻ với dự án, Ellis nói.

FOSSisms #9: Duy trì lịch sử

Kiểm soát phiên bản chỉ là một cách thức các cộng đồng nguồn mở duy trì lịch sử. Nhưng gần như mọi thành phần trong chuỗi công cụ phát triển nguồn mở đều được lưu lại. Vì thế các sinh viên có thể sử dụng các hồ sơ dự án để tiêu hóa nhanh chóng hơn trong cộng đồng đó. Họ cũng có thể sử dụng các công cụ duy trì hồ sơ y hệt, Ellis nói, khi học kỳ tới gần và họ sẵn sàng để đưa ra công việc họ đã làm xong.

FOSSisms #10: Bắt đầu bằng những việc nhỏ

Các sinh viên nên luôn bắt đầu bằng các lỗi nhỏ nhất, dường như phi logic nhất, Ellis nói - quả ở tầm thấp cho phép họ tiến hành những đóng góp có hiệu quả cho dự án sớm nhất theo thời gian. Họ có thể cập nhật tài liệu hoặc thẩm định lỗi, những đóng góp quan trọng đòi hỏi ít tri thức về dự án. Ellis đã cảnh báo rằng các giáo sư yêu cầu các sinh viên của họ bắt đầu bằng việc xác định những đóng góp cho dự án có lẽ bản thân họ thấy quá tải.

“Đừng có ôm cả thế giới”, bà nói.

FOSSisms #11: Đó không phải là những gì bạn biết; đó là những gì bạn muốn học

Với tư cách của họ là người đứng trong lớp học - một môi trường thiên về tính tò mò - các sinh viên nằm ở vị trí tốt rồi để đóng góp cho các dự án nguồn mở, Ellis nói, vì các cộng đồng đó đánh giá cao các thành viên muốn học cách họ có thể trợ giúp. Mỗi thành viên của cộng đồng nguồn mở từng một lần là những người mới tới, Ellis nhắc nhở các đồng nghiệp của bà; các dự án nguồn mở thường chào đón các thành viên mới sẵn sàng và có thiện chí học các kỹ năng cần thiết để tạo ra sự khác biệt cho dự án.

FOSSisms #12: Phát hành sớm, phát hành thường xuyên

Các ứng dụng nguồn mở hưởng lợi từ các vòng phản hồi ngắn, chặt chẽ giữa các lập trình viên và những người sử dụng, Ellis nói. Các dự án thường lặp đi lặp lại, và các sinh viên nên quen với sự thay đổi liên tục. Nhưng một trạng thái “phát hành sớm và thường xuyên” cũng đảm bảo rằng các sinh viên học được từ các sai lầm của họ nhanh chóng - thường nhanh hơn so với họ có thể nếu họ chờ đợi hàng tuần người chỉ dẫn duy nhất hoặc người trợ giảng để đánh giá và xếp loại công việc của họ.

FOSSisms #13: Đẩy lên dòng trên

Các sinh viên nên luôn – luôn luôn, luôn luôn - đẩy công việc của họ tới các lập trình viên và các cộng đồng dòng trên, từ những nơi mà họ hưởng lợi. Đây là cách thức đúng duy nhất trong các cộng đồng nguồn mở. Bằng cách làm như vậy, các sinh viên cũng nhận thức được về ý thức hoàn thành khi các cộng đồng nhận thức được về chức năng và sự tao nhã học đã cung cấp cho một dự án. Ngắn gọn, các sinh viên học về tầm quan trọng của việc có đi có lại - về việc đóng góp ngược trở lại.

FOSSisms #14: Hãy cho tôi xem mã

Các cộng đồng nguồn mở, Ellis nói, là thực dụng tuyệt vời: các lập trình viên chỉ là tốt như kỹ năng họ thể hiện. Như Linus Torvalds đã nói: “Nói thì ít có giá trị. Hãy cho tôi xem mã”. Các sinh viên tham gia trong các dự án nguồn mở phải sẵn sàng tiếp xúc với việc lập trình tận gốc nếu họ muốn được chấp nhận như một phần của các cộng đồng đáng kính của họ.

FOSSisms #15: Hãy nhớ làm cạn các lỗi

Ellis đã nhắc các đồng nghiệp của bà về những gì Eric Raymond gọi là “Luật Linus” (Linus' Law): "đưa ra đủ các cặp mắt, thì tất cả các lỗi sẽ cạn". Các sinh viên, bà nói, phảI học chấp nhận sự giúp đỡ từ các cộng đồng mà họ là một phần của nó; họ phải sẵn sàng yêu cầu trợ giúp khi họ cần nó, hơn là kéo lê trong sự cô lập trong khi sự khó chịu ngày càng gia tăng. Họ nên nói ra ngay lập tức khi họ có khó khăn, sao cho cộng đồng có thể can thiệp và thảo luận về vấn đề đó như một nhóm.

FOSSisms #16: Tránh công việc không có giao tiếp

Ellis nói rằng các sinh viên phải học để biến đổi công việc của họ một cách trang nhã khi họ kết thúc thời gian học tập nghiên cứu hàn lâm; họ nên biết rằng các nỗ lực của họ sẽ không hoàn chỉnh cho tới khi họ đã đảm bảo rằng các cộng đồng của họ có thể an toàn quan tâm chăm sóc (hiểu, duy trì, và xây dựng dựa vào nó) tới những gì họ đã đóng góp. Họ luôn nên nhận diện ra những người duy trì dự án và trao đổi về những ý định của họ một cách đúng đắn - thậm chí nếu họ không đạt được các mục tiêu của họ.

“Là tốt hơn để trao đổi công việc chưa làm được”, Ellis nói, “hơn là tiến hành công việc không có giao tiếp”.

When Heidi Ellis took the floor at this year's Professors' Open Source Summer Experience—held May 28-30 at Drexel University in Philadelphia—she wanted her colleagues to understand the extraordinary educational benefits of involving students in open source projects.

And what better to help them realize these benefits than the distilled wisdom of open source communities themselves.

Ellis, who co-coordinated POSSE with Drexel professor Greg Hislop, told a crowd of nearly 20 faculty members from colleges and universities across the country that embedding their computer science students in open source communities could facilitate a kind of engagement traditional classroom experiences just can't offer. But, she said, students and professors alike should be prepared for a bit of culture shock if they aren't prepared to embrace the open source way.

So Ellis derived 16 maxims from free and open source culture—what she calls "FOSSisms"—to explain how open source values might transform computer science education.

FOSSism #1: It's all about community

Getting students started with open source means asking them to do more than simply work on a new project. It involves asking them to join a community, Ellis said. And "when you do that," she said "you're joining a new culture."

So students must quickly acclimate to the unspoken norms of a group with its own methods, preferences, and in-jokes. When joining an open source community, students should identify that community's preferred channels of communication and use those as windows into its culture.

"The community drives the project," Ellis said, "not vice versa."

By joining open source communities, students gain access to experts that can assist them when they begin struggling with their contributions. In this way, faculty members acquire valuable mentors for their students.

"Once you're in the community, you're a part of the community," Ellis said. "That's one of the benefits. They'll care for your students."

FOSSism #2: Be productively lost

The scope of any open source project or community exceeds any single person's ability to completely comprehend it. Consequently, students might feel lost or adrift in unfamiliar territory. But their instructors should encourage them to use their confusion productively—to investigate the community and to learn about a project by digging through its materials. A period of head-spinning disorientation is perfectly natural—even beneficial—Ellis assured her audience. The same is true for professors who are also new to their chosen open source projects.

"This can be a very foreign concept to instructors," Ellis said. "We are taught that we are supposed to be the subject matter experts."

FOSSism #3: Give back

Open source software projects survive on contributions from users and developers, Eillis explained, so students must learn to start giving back immediately. They should update documentation, test code, confirm bugs, answer questions from others—pitch in wherever they can. They'll soon learn they don't need to be experts to make positive impacts to their communities; they just need to be willing to do the work. Even the smallest contributions are valuable, Ellis said.

FOSSism #4: Opportunism reigns

Because few open source developers work on their projects full-time, competing demands always limit their ability to contribute. So open source development can be rather opportunistic, Ellis explained: development occurs in spurts as coders take advantage of resources as they appear. Students must realize that open source development processes don't always mirror those of industry; work might occur in fits and starts according to community members' availability.

FOSSism #5: If it isn't public, it didn't happen

Open source work occurs in the open. Coders make use of mailing lists, IRC channels, and other public communication channels so everyone in the community—and anyone wanting to join the community—can peek at what they're doing. Students must become comfortable with working in public and sharing their resources, Ellis said.

"If people can't see them," she said, "they're no good to people."

Transparency can be startling to faculty, too, Ellis added.

"Most academics have it ingrained in them that you don't publish anything until it's perfected," she said. "In the open source world, it's the complete opposite."

FOSSism #6: Embrace radical transparency

Because open source communities engage in distributed development, they embrace radical transparency and the materials they produce—all the documentation, code, and other artifacts that students can seize to enhance their learning—are open by default, ready for use in the classroom (and beyond).

"All this is a rich, rich avenue for learning," Ellis said.

FOSSism #7: Ask forgiveness, not permission

Almost invariably, open source communities utilize some form of version control, Eillis explained, so students should realize that their contributions have little chance of completely derailing a project. They needn't ask permission to tinker with something; they should simply begin working, asking for the community's forgiveness if they make a mistake. More often than not, community members are understanding and supportive, because undoing errors involves little effort.

FOSSism #8: Branches are free

Students still reluctant to work directly with a community's codebase should remember that they can easily branch an existing project and fiddle with local copies instead. Doing this might liberate them to experiment. It might even result in their fixing a bug—a result they can then easily share with the project, Ellis said.

FOSSism #9: Keep a history

Version control is merely one way that open source communities keep histories. But nearly every component in open source development toolchains keeps records. So students can use a project's records to more quickly assimilate into the community. They can also use these same record-keeping tools, Ellis added, when the semester comes to a close and they're ready to hand off the work they've done.

FOSSism #10: Begin with the finishing touches

Students should always begin with the smallest, most seemingly inconsequential bugs, Ellis said—the low-hanging fruit that allows them to make productive contributions to a project early in the term. They might update documentation or verify a bug, important contributions that require little knowledge of a project. Ellis cautioned that professors asking their students to begin with project-defining contributions might find themselves overwhelmed.

"Don't take on the world," she said.

FOSSism #11: It's not what you know; it's what you want to learn

By virtue of their being in a classroom—an environment predisposed to inquisitiveness—students are already well-positioned to contribute to open source projects, Ellis said, because these communities value members who want to learn how they can assist. Every member of an open source community was once a newbie, Ellis reminded her colleagues; open source projects typically welcome new members ready and willing to learn the skills necessary to make a difference to the project.

FOSSism #12: Release early, release often

Open source applications benefit from short, tight feedback loops between developers and users, Ellis said. Projects iterate often, and students should become accustomed to constant change. But a "release early and often" mentality also ensures that students learn from their mistakes quickly—often quicker than they would if they waited weeks for a single instructor or teaching assistant to assess and grade their work.

FOSSism #13: Push to upstream

Students should always—always, always—push their work to the upstream developers and communities from whom they benefit. This is only proper decorum in open source communities. But by doing so, students also realize a sense of accomplishment as communities recognize the functionality and polish they've provided to a project. In short, students learn the importance of reciprocity—of giving back.

FOSSism #14: Show me the code

Open source communities, Ellis said, are consummately pragmatic: programmers are only as good as the skills they demonstrate. As Linus Torvalds has said: "Talk is cheap. Show me the code." Students participating in open source projects must be ready to hit the ground coding if they want to be accepted as part of their respective communities.

FOSSism #15: Remember shallow bugs

Ellis reminded her colleagues of what Eric Raymond calls "Linus' Law": "given enough eyeballs, all bugs are shallow." Students, she said, must learn to accept help from the communities of which they're a part; they must be ready to ask for help when they need it, rather than toil away in isolation while growing increasingly frustrated. They should speak up immediately when they're having trouble, so the community can step in and discuss the problem as a group.

FOSSism #16: Avoid uncommunicated work

Ellis said that students must learn to transfer their work gracefully when they finish the academic term; they should know that their efforts aren't complete until they've ensured that their communities can safely care for (understand, maintain, and build upon) what they've contributed. They should always identify project maintainers and communicate their intentions appropriately—even if they've fallen short of their goals.

"It's better to communicate undone work," Ellis said, "than to do uncommunicated work."

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com