使用开源进行体验式学习充满了灾难的机会。
开源对于教授们来说是陌生的领域。不是指软件，软件现在已经广为人知。但是教授们不习惯开放式开发。他们把开源项目当作是打发时间的工作或者布置作业的简单方法。参与 FOSS 项目需要工作和时间，甚至可能长达六个月，对于想要在一个学期课程中使用它的人来说，这是一个很大的承诺。在没有教授参与的情况下，将学生送到项目中是失败的根源。
首先，教授们需要为他们的学生选择合适的项目——并非所有项目都适合或准备好迎接大量学生。有些项目根本不想接纳学生。有些项目不欢迎新手——内核就是一个很好的例子。那些参与过旨在欢迎学生和新手的项目的项目，例如 Google Summer of Code 或 OpenHatch，是一个不错的起点。他们是那些知道如何接受经验不足的贡献者的人。
具有讽刺意味的是，有时问题在于开源社区太乐于助人了。我们理解失败是学习过程的一部分，并给予经验不足的贡献者信任。在一个精英管理体制中，人们不会阻止你做事情——他们支持个人追求目标，无论最终目标多么明智。如果一个学生说“我想自掘坟墓！”，社区可能会说“好的！我们会帮你瞄准！” 新手很难分辨一个项目需要多少工作和技能，以及它可能对代码用户产生多大的影响，在学期时间紧张的限制下，帮助他们将自己限制在可解决的问题上尤为重要。
第二个常见问题是，教授们经常犯的错误是将学生作为核心参与者直接扔到项目中，而实际上，学生应该以外围的方式参与——但这与没有价值或不重要的方式不同。许多学生不具备向内核或大型数据库提交代码的知识，他们通常也没有准备好进行长期维护。他们从事的任务应该是非关键路径阻塞的任务，但它们应该改善核心贡献者的生活；询问社区导师他们想要解决但太忙而无法解决的问题。然后询问他们是否愿意教你如何为他们做这项工作。
第三，学生应该在一定程度上从事他们已经知道如何做的事情。如果学生选择需要他们学习大量新技能的任务，让他们快速掌握该任务可能需要很长时间，如果你需要在学期课程中启动和停止一个项目，这又是一个问题。学生可能在一个班级中花费 12 周，每周在该班级花费 12 小时，并且将一半的课堂时间用于你的项目；总共 72 小时，或者少于两周的全职工作；想想实习生或新员工在该时间范围内可以做什么。如果你从过于雄心勃勃的事情开始，你就会陷入“yak shaving”。我记得有一个学生小组想修复一个项目的网页。太棒了，我们说！但是首先……他们必须学习 HTML。没问题。等等——但是首先……要查看网页的 HTML，他们需要学习 git。但是首先……要理解 git，他们必须学习版本控制系统……等等，沿着看似与他们最初任务无关的长链材料向下延伸。有了所有这些启动成本，学生们经常想知道他们什么时候才能“开始做真正的工作”。
第四，告诉学生，他们有责任理解所需的沟通水平。由于 FOSS 项目分布广泛，它们只有在沟通畅通时才能运作。贡献者可能永远不会亲自见面，如果他们见面，也可能只是偶然的机会或每年一次在会议上。如果沟通停止，项目就会停止。学生习惯的模式——完成项目、提交项目、一走了之——在开源中是不成功的。看看 Mike McGrath 关于如何成为一名成功的贡献者的指南，该指南几乎完全侧重于沟通和文化，而不是“技术技能”。学习工具和实践以及与项目社区沟通是真正的工作——就像在“现实世界”中一样。预计沟通将占用你 50% 或更多的时间，而你试图做的实际任务将占用 33-50%。 （之后，Walter Bender 说他认为这些数字对于经验丰富的 FOSS 贡献者来说是乐观的——一年左右之后，你可能会达到 30-50% 左右。Bender 预测，新手的目标是达到 10% 就很不错了。）因此，如果你是一名教授，请告诉你的学生，他们将每天阅读邮件列表并关注 IRC。他们应该知道，仅仅完成实际任务只是与开源社区互动这一整体任务中非常小的一部分。
最后，教授们需要在学生出现之前至少六个月参与他们希望学生参与的项目，并且他们应该坦诚地说明他们的计划。这将使他们有机会选择适合情况和班级、具有合适任务以及拥有可以为学生找到导师的社区的有限项目子集。参与进来可能很棘手，因此，如果你是一位刚接触开源的教授，你可以考虑 Red Hat 的 POSSE（教授开源暑期体验）研讨会，该研讨会向教师介绍开源社区，以便他们可以在下一个学年向学生介绍开源社区。
还有一些额外的资源，由专注的人员提供，可以帮助你入门
祝你好运！
评论已关闭。