github组织_投资Github组织！

github组织

首先，让我说Github是这里的主题，只是因为它们是开源行业中最大的。 Github已成为软件开发的Facebook，这就是为什么专注于它的原因。 将来可能会出现一个更好的平台，然后本文将适用于该平台。

几年前，OSS软件是每个人都在咖啡机旁取笑的东西。 唯一拥有Github帐户的开发人员是那些愿意每天进行12小时编程的开发人员，因为他们的公司甚至都没有听说过这个概念。 但是，这些天来，情况发生了巨大变化。 一些最大的公司依靠开源来发展他们的业务，并为社区做出贡献。

在这种情况下，我相信任何一家像样的软件公司都应该考虑在Github上维护组织方面投入时间和预算，在Github上，该组织应该开发应用程序，库和可以与世界共享的任何软件包。 在这篇文章中，我将介绍一些使我想到的原因。

汤姆和杰瑞–杰瑞和金鱼，威廉·汉娜和约瑟夫·巴贝拉

第一个原因是所有事物都在那里。 不仅记录日志库和HTTP客户端，而且记录整个框架和应用程序 。 React ， Angular ， ElasticSearch和许多其他名人都是开源的。 他们的代码是开放的，并且由于当今几乎所有开发人员都已经接触过这些技术，因此他们至少应该知道他们的位置，如何提出问题，提出请求，查找错误的解决方案等–他们将在Github上找到所有内容：注释，指南，维基，已知错误，您都可以命名。 我一直在想：一家封闭公司在使用的OSS产品中存在错误时会怎么做？ 它是否无限期地等待着新版本，希望问题能够得到解决？ 分叉存储库并提供PR会更好吗？

其次 ，任何技术公司都希望敏捷 ，因为开发人员应Swift行动，快速解决错误，无须繁琐地切换框架和程序包，在短短几分钟内设置CI / CD命令行等。严格，封闭的环境没有这样做的习惯或经验。 他或她将不知道ReactJs v15有一个难看的错误 ，该错误会导致输入字段在IE上丢失字符。 在某个时候，当他们意识到这一点时，他们将更新到v16，并花费大量的时间来尝试弄清楚为什么npm构建不再起作用（也就是说，如果他们麻烦检查好的老Jenkins CI几周来一直是红色的）。

顺便说一下， npm社区是这种敏捷性的一个很好的例子。 这些Javascript人员能够在一夜之间从头开始重写应用程序或框架，而不是修复一些可疑的错误或处理三年前被解雇的同事的凌乱代码。 他们很有生产力！ 事情以惊人的速度发展，每个人都在公开场合进行协作，而您却浪费了会议时间，试图决定聘请哪位顾问来培训您的团队使用ReactJS。 然后，在一两年（最好的情况）下，React将会死掉，而您将再一次拥有传统软件，没人知道如何维护。

甚至在Gthub上也有诸如GWT之类的陈旧，枯燥无味的技术。 您可能已经听说过它，因为它曾经是2012年最酷的玩具。您是否知道从Chrome 61开始，所有GWT <2.8.2中的弹出窗口都放错了位置吗？ 这是因为Chrome家伙改变了滚动距离的计算方式。 有很多类似的凭单，因为任何显示弹出窗口的JS库都可能受到影响。

关键是，您需要参与其中，需要知道如何以及何时开发正在使用的某些框架和工具（旧的和新的）。 此外，您必须快速移动，尽可能地自动化，每天交付。 我认为没有OSS文化就无法实现这一目标，仅仅洗净最新的《软件杂志》并阅读最新的流行词还不够。

第三 ，当然是Marketing 。 不一定适合客户，但适合您正在寻找的开发人员。 如今，每个人都在努力雇用和留住开发人员。 让我告诉你，我将用所有的Play Station，乒乓球桌和有趣的枕头进行交易，以争取在我的全职工作时间内从事OSS的工作。 您作为一家公司，将对软件开发人员更具吸引力，仅因为他们会看到您对新技术以及软件世界的发展方式感兴趣。 他们会知道您不是一个笨拙的雇主，仍然会使用木乃伊技术或以浅浅的方式使用新技术。

不要误会我的意思，我并不是说您应该在互联网上提供客户的代码，或者应该将价值数十亿美元的想法放到Github上（尽管那里有数十亿美元的产品）。 相反，您应该为现有项目做出贡献，或者发布自己的组件。 我认为我们可以同意，从任何大型项目中，无论多么重要和机密，都可以提取至少一个通用，可重用的程序包–谁知道，也许您的产品与AWS交互，并且您的团队设法为AWS实现了Java SDK，不像官方那样灾难。

总而言之，这就是为什么我认为OSS对于任何想要长期生存的软件公司都是强制性的原因。 它不应该是一个普通话，而是一条生命线。 如果一家公司想要保持竞争力并在市场上生存，那就再也无法无知。

翻译自: https://www.javacodegeeks.com/2017/12/invest-github-organization.html

github组织