mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
Merge pull request #8787 from FelixYFZ/master
IT automation: How to make the case Translation finished
This commit is contained in:
Xingyu.Wang
GitHub
commit
9b7d6089ee
@ -1,95 +0,0 @@
|
||||
Translating by FelxiYFZ IT automation: How to make the case
|
||||
======
|
||||
At the start of any significant project or change initiative, IT leaders face a proverbial fork in the road.
|
||||
|
||||
Path #1 might seem to offer the shortest route from A to B: Simply force-feed the project to everyone by executive mandate, essentially saying, “You’re going to do this – or else.”
|
||||
|
||||
Path #2 might appear less direct, because on this journey you take the time to explain the strategy and the reasons behind it. In fact, you’re going to be making pit stops along this route, rather than marathoning from start to finish: “Here’s what we’re doing – and why we’re doing it.”
|
||||
|
||||
Guess which path bears better results?
|
||||
|
||||
If you said #2, you’ve traveled both paths before – and experienced the results first-hand. Getting people on board with major changes beforehand is almost always the smarter choice.
|
||||
|
||||
IT leaders know as well as anyone that with significant change often comes [significant fear][1], skepticism, and other challenges. It may be especially true with IT automation. The term alone sounds scary to some people, and it is often tied to misconceptions. Helping people understand the what, why, and how of your company’s automation strategy is a necessary step to achieving your goals associated with that strategy.
|
||||
|
||||
[ **Read our related article,** [**IT automation best practices: 7 keys to long-term success**][2]. ]
|
||||
|
||||
With that in mind, we asked a variety of IT leaders for their advice on making the case for automation in your organization:
|
||||
|
||||
## 1. Show people what’s in it for them
|
||||
|
||||
Let’s face it: Self-interest and self-preservation are natural instincts. Tapping into that human tendency is a good way to get people on board: Show people how your automation strategy will benefit them and their jobs. Will automating a particular process in the software pipeline mean fewer middle-of-the-night calls for team members? Will it enable some people to dump low-skill, manual tasks in favor of more strategic, higher-order work – the sort that helps them take the next step in their career?
|
||||
|
||||
“Convey what’s in it for them, and how it will benefit clients and the whole company,” advises Vipul Nagrath, global CIO at [ADP][3]. “Compare the current state to a brighter future state, where the company enjoys greater stability, agility, efficiency, and security.”
|
||||
|
||||
The same approach holds true when making the case outside of IT; just lighten up on the jargon when explaining the benefits to non-technical stakeholders, Nagrath says.
|
||||
|
||||
Setting up a before-and-after picture is a good storytelling device for helping people see the upside.
|
||||
|
||||
“You want to paint a picture of the current state that people can relate to,” Nagrath says. “Present what’s working, but also highlight what’s causing teams to be less than agile.” Then explain how automating certain processes will improve that current state.
|
||||
|
||||
## 2. Connect automation to specific business goals
|
||||
|
||||
Part of making a strong case entails making sure people understand that you’re not just trend-chasing. If you’re automating simply for the sake of automating, people will sniff that out and become more resistant – perhaps especially within IT.
|
||||
|
||||
“The case for automation needs to be driven by a business demand signal, such as revenue or operating expense,” says David Emerson, VP and deputy CISO at [Cyxtera][4]. “No automation endeavor is self-justifying, and no technical feat, generally, should be a means unto itself, unless it’s a core competency of the company.”
|
||||
|
||||
Like Nagrath, Emerson recommends promoting the incentives associated with achieving the business goals of automation, and working toward these goals (and corresponding incentives) in an iterative, step-by-step fashion.
|
||||
|
||||
## 3. Break the automation plan into manageable pieces
|
||||
|
||||
Even if your automation strategy is literally “automate everything,” that’s a tough sell (and probably unrealistic) for most organizations. You’ll make a stronger case with a plan that approaches automation manageable piece by manageable piece, and that enables greater flexibility to adapt along the way.
|
||||
|
||||
“When making a case for automation, I recommend clearly illustrating the incentive to move to an automated process, and allowing iteration toward that goal to introduce and prove the benefits at lower risk,” Emerson says.
|
||||
|
||||
Sergey Zuev, founder at [GA Connector][5], shares an in-the-trenches account of why automating incrementally is crucial – and how it will help you build a stronger, longer-lasting argument for your strategy. Zuev should know: His company’s tool automates the import of data from CRM applications into Google Analytics. But it was actually the company’s internal experience automating its own customer onboarding process that led to a lightbulb moment.
|
||||
|
||||
“At first, we tried to build the whole onboarding funnel at once, and as a result, the project dragged [on] for months,” Zuev says. “After realizing that it [was] going nowhere, we decided to select small chunks that would have the biggest immediate effect, and start with that. As a result, we managed to implement one of the email sequences in just a week, and are already reaping the benefits of the desecrated manual effort.”
|
||||
|
||||
## 4. Sell the big-picture benefits too
|
||||
|
||||
A step-by-step approach does not preclude painting a bigger picture. Just as it’s a good idea to make the case at the individual or team level, it’s also a good idea for help people understand the company-wide benefits.
|
||||
|
||||
“If we can accelerate the time it takes for the business to get what it needs, it will silence the skeptics.”
|
||||
|
||||
Eric Kaplan, CTO at [AHEAD][6], agrees that using small wins to show automation’s value is a smart strategy for winning people over. But the value those so-called “small” wins reveal can actually help you sharpen the big picture for people. Kaplan points to the value of individual and organizational time as an area everyone can connect with easily.
|
||||
|
||||
“The best place to do this is where you can show savings in terms of time,” Kaplan says. “If we can accelerate the time it takes for the business to get what it needs, it will silence the skeptics.”
|
||||
|
||||
Time and scalability are powerful benefits business and IT colleagues, both charged with growing the business, can grasp.
|
||||
|
||||
“The result of automation is scalability – less effort per person to maintain and grow your IT environment, as [Red Hat][7] VP, Global Services John Allessio recently [noted][8]. “If adding manpower is the only way to grow your business, then scalability is a pipe dream. Automation reduces your manpower requirements and provides the flexibility required for continued IT evolution.” (See his full article, [What DevOps teams really need from a CIO][8].)
|
||||
|
||||
## 5. Promote the heck out of your results
|
||||
|
||||
At the outset of your automation strategy, you’ll likely be making the case based on goals and the anticipated benefits of achieving those goals. But as your automation strategy evolves, there’s no case quite as convincing as one grounded in real-world results.
|
||||
|
||||
“Seeing is believing,” says Nagrath, ADP’s CIO. “Nothing quiets skeptics like a track record of delivery.”
|
||||
|
||||
That means, of course, not only achieving your goals, but also doing so on time – another good reason for the iterative, step-by-step approach.
|
||||
|
||||
While quantitative results such as percentage improvements or cost savings can speak loudly, Nagrath advises his fellow IT leaders not to stop there when telling your automation story.
|
||||
|
||||
“Making a case for automation is also a qualitative discussion, where we can promote the issues prevented, overall business continuity, reductions in failures/errors, and associates taking on [greater] responsibility as they tackle more value-added tasks.”
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://enterprisersproject.com/article/2018/1/how-make-case-it-automation
|
||||
|
||||
作者：[Kevin Casey][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://enterprisersproject.com/user/kevin-casey
|
||||
[1]:https://enterprisersproject.com/article/2017/10/how-beat-fear-and-loathing-it-change
|
||||
[2]:https://enterprisersproject.com/article/2018/1/it-automation-best-practices-7-keys-long-term-success?sc_cid=70160000000h0aXAAQ
|
||||
[3]:https://www.adp.com/
|
||||
[4]:https://www.cyxtera.com/
|
||||
[5]:http://gaconnector.com/
|
||||
[6]:https://www.thinkahead.com/
|
||||
[7]:https://www.redhat.com/en?intcmp=701f2000000tjyaAAA
|
||||
[8]:https://enterprisersproject.com/article/2017/12/what-devops-teams-really-need-cio
|
||||
[9]:https://enterprisersproject.com/email-newsletter?intcmp=701f2000000tsjPAAQ
|
||||
@ -1,79 +0,0 @@
|
||||
Translating by FelixYFZ 10 easy steps from proprietary to open source
|
||||
======
|
||||
"But surely open source software is less secure, because everybody can see it, and they can just recompile it and replace it with bad stuff they've written." Hands up: who's heard this?1
|
||||
|
||||
When I talk to customers--yes, they let me talk to customers sometimes--and to folks in the field2 this comes up quite frequently. In a previous article, "[Review by many eyes does not always prevent buggy code][1]", I talked about how open source software--particularly security software--isn't magically more secure than proprietary software, but I'd still go with open source over proprietary every time. But the way I've heard the particular question--about open source software being less secure--suggests that sometimes it's not enough to just explain that open source needs work, but we must also actively engage in [apologetics][2]3.
|
||||
|
||||
So here goes. I don't expect it to be up to Newton's or Wittgenstein's levels of logic, but I'll do what I can, and I'll summarise at the bottom so you have a quick list of the points if you want it.
|
||||
|
||||
### The arguments
|
||||
|
||||
First, we should accept that no software is perfect6. Not proprietary software, not open source software. Second, we should accept that good proprietary software exists, and third, there is also some bad open source software out there. Fourth, there are extremely intelligent, gifted, and dedicated architects, designers, and software engineers who create proprietary software.
|
||||
|
||||
But here's the rub: fifth, there is a limited pool of people who will work on or otherwise look at proprietary software. And you can never hire all the best people. Even in government and public sector organisations--who often have a larger talent pool available to them, particularly for cough security-related cough applications--the pool is limited.
|
||||
|
||||
Sixth, the pool of people available to look at, test, improve, break, re-improve, and roll out open source software is almost unlimited and does include the best people. Seventh (and I love this one), the pool also includes many of the people writing the proprietary software. Eighth, many of the applications being written by public sector and government organisations are open sourced anyway.
|
||||
|
||||
Ninth, if you're worried about running open source software that is unsupported or comes from dodgy, un-provenanced sources, then good news: There are a bunch of organisations7 who will check the provenance of that code, support, maintain, and patch it. They'll do it along the same type of business lines that you'd expect from a proprietary software provider. You can also ensure that the software you get from them is the right software: Their standard technique is to sign bundles of software so you can verify that what you're installing isn't from some random bad person who's taken that code and done Bad Things™ with it.
|
||||
|
||||
Tenth (and here's the point of this article), when you run open source software, when you test it, when you provide feedback on issues, when you discover errors and report them, you are tapping into--and adding to--the commonwealth of knowledge and expertise and experience that is open source, which is made only greater by your doing so. If you do this yourself, or through one of the businesses that support open source software8, you are part of this commonwealth. Things get better with open source software, and you can see them getting better. Nothing is hidden--it's, well, open. Can things get worse? Yes, they can, but we can see when that happens and fix it.
|
||||
|
||||
This commonwealth does not apply to proprietary software: what stays hidden does not enlighten or enrich the world.
|
||||
|
||||
I know that I need to be careful about the use of the "commonwealth" as a Briton; it has connotations of (faded…) empires, which I don't intend in this case. It's probably not what Cromwell9 had in mind when he talked about the "Commonwealth," either, and anyway, he's a somewhat controversial historical figure. What I'm talking about is a concept in which I think the words deserve concatenation--"common" and "wealth"--to show that we're talking about something more than just money, but shared wealth available to all of humanity.
|
||||
|
||||
I really believe in this. If you want to take away a religious message from this article, it should be this10: the commonwealth is our heritage, our experience, our knowledge, our responsibility. The commonwealth is available to all of humanity. We have it in common, and it is an almost inestimable wealth.
|
||||
|
||||
### A handy crib sheet
|
||||
|
||||
1. (Almost) no software is perfect.
|
||||
2. There is good proprietary software.
|
||||
3. There is bad open source software.
|
||||
4. There are clever, talented, and devoted people who create proprietary software.
|
||||
5. The pool of people available to write and improve proprietary software is limited, even within the public sector and government realm.
|
||||
6. The corresponding pool of people for open source is virtually unlimited…
|
||||
7. …and includes a goodly number of the talent pool of people writing proprietary software.
|
||||
8. Public sector and government organisations often open source their software anyway.
|
||||
9. There are businesses that will support open source software for you.
|
||||
10. Contribution--even usage--adds to the commonwealth.
|
||||
|
||||
|
||||
|
||||
1 OK--you can put your hands down now.
|
||||
|
||||
2 Should this be capitalized? Is there a particular field, or how does it work? I'm not sure.
|
||||
|
||||
3 I have a degree in English literature and theology--this probably won't surprise regular readers of my articles.4
|
||||
|
||||
4 Not, I hope, because I spout too much theology,5 but because it's often full of long-winded, irrelevant humanities (U.S. English: "liberal arts") references.
|
||||
|
||||
5 Emacs. Every time.
|
||||
|
||||
6 Not even Emacs. And yes, I know that there are techniques to prove the correctness of some software. (I suspect that Emacs doesn't pass many of them…)
|
||||
|
||||
7 Hand up here: I'm employed by one of them, [Red Hat][3]. Go have a look--it's a fun place to work, and [we're usually hiring][4].
|
||||
|
||||
8 Assuming that they fully abide by the rules of the open source licence(s) they're using, that is.
|
||||
|
||||
9 Erstwhile "Lord Protector of England, Scotland, and Ireland"--that Cromwell.
|
||||
|
||||
10 Oh, and choose Emacs over Vi variants, obviously.
|
||||
|
||||
This article originally appeared on [Alice, Eve, and Bob - a security blog][5] and is republished with permission.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/17/11/commonwealth-open-source
|
||||
|
||||
作者：[Mike Bursell][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://opensource.com/users/mikecamel
|
||||
[1]:https://opensource.com/article/17/10/many-eyes
|
||||
[2]:https://en.wikipedia.org/wiki/Apologetics
|
||||
[3]:https://www.redhat.com/
|
||||
[4]:https://www.redhat.com/en/jobs
|
||||
[5]:https://aliceevebob.com/2017/10/24/the-commonwealth-of-open-source/
|
||||
@ -0,0 +1,96 @@
|
||||
IT自动化:如何去实现
|
||||
======
|
||||
|
||||
在任何重要的项目或变更刚开始的时候，TI的管理者在前进的道路上面临着普遍的抉择。
|
||||
|
||||
第一条路径看上去是提供了一个从A到B的最短路径：简单的把项目强制分配给每个人去执行，本质来说就是你要么按照要求去做要么就不要做了。
|
||||
|
||||
第二条路径可能看上去会不是很直接，因为要通过这条路径你要花时间去解释项目背后的策略以及原因。你会沿着这条路线设置停靠站点而不是从起点到终点的马拉松：
|
||||
“这就是我们正在做的-和为什么我们这么做。”
|
||||
|
||||
猜想一下哪条路径会赢得更好的结果？
|
||||
|
||||
如果你选的是路径2，你肯定是以前都经历过这两条路径-而且经历了第一次的结局。让人们参与到重大变革中总会是最明智的选择。
|
||||
|
||||
IT领导者也知道重大的变革总会带来严重的恐慌、怀疑，和其他的挑战。IT自动化确实是很正确的改变。这个术语对某些人来说是很可怕的，而且容易被曲解。帮助人们理解你的公司需要IT自动化的必要性的原因以及如何去实现是达到你的目标和策略的重要步骤。
|
||||
|
||||
[**阅读我们的相关文章，**[**IT自动化最佳实践：持久成功的7个关键点**][2]. ]
|
||||
|
||||
考虑到这一点，我们咨询了许多IT管理者关于如何在你的组织中实现IT自动化。
|
||||
|
||||
## 1. 向人们展示它的优点
|
||||
|
||||
我们要面对的一点事实是：自我利益和自我保护是本能。利用人们的这种本能是一个吸引他们的好方法：向他们展示自动化策略将如何让他们和他们的工作获益。自动化将会是软件管道中的一个特定过程意味着将会减少在半夜呼叫团队同事来解决故障？他将能让一些人丢弃技术含量低的技能，用更有策略，高效的有序工作代替手工作业，这将会帮助他们的职业生涯更进一步？
|
||||
|
||||
”向他们传达他们能得到什么好处，自动化将会如何让他们的客户和公司受益，“来自vipual的建议，ADP全球首席技术官。”将现在的状态和未来光明的未来进行对比，展现公司将会变得如何稳定，敏捷，高效和安全。“
|
||||
|
||||
这样的方法同样适用于IT领域之外的其他领域；只要在向非技术领域的股东们解读利益的时候解释清楚一些术语即可，Nagrath 说道。
|
||||
|
||||
设置好前后的情景是一个不错的帮助人们理解的更透彻的故事机。
|
||||
|
||||
“你要描述一幅人们能够联想到的当前状态的画面，”Nagrath 说。“描述现在是什么工作，但也要重点强调是什么导致团队的工作效率不够敏捷。”然后再阐释自动化过程将如何提高现在的状态。
|
||||
|
||||
## 2.将自动化和特定的商业目标绑定在一起
|
||||
|
||||
一个强有力的案列的一部分要确保人们理解你不只是在追逐潮流趋势。如果i只是为了自动化而自动化，人们会很快察觉到进而会更加抵制的-也许在IT界更是如此。
|
||||
|
||||
“自动化需要商业需求的驱动，列如收入和运营开销，” David说道，Cyxtera的副总裁和首席信息安全官。“没有自动化的努力是自我辩护的，而且任何技术专长都不应该被当做一种手段，除非它是公司的一项核心能力”
|
||||
|
||||
像Nagrath一样，Emerson建议将达到自动化的商业目标和奖励措施挂钩，用迭代式的循序渐进的方式推进这些目标和相关的激励措施。
|
||||
|
||||
## 3. 将自动化计划分解为可管理的条目
|
||||
|
||||
即使你的自动化策略字面上是“一切都自动化，”对大多数组织来说那也是很艰难的而且可能是没有灵活性的。你需要一个能够将自动化目标分解为可管理的目标的计划来制定一个强有力的方案。而且这将能够创造很大的灵活性来适应之后漫长的道路。
|
||||
|
||||
“当制定一个自动化方案的时候，我建议详细的阐明推进自动化进程的奖励措施，而且允许迭代朝着目标前进来介绍和证明利益处于一个低风险水平，”Emerson说道。
|
||||
|
||||
Sergey Zuev, GA Connector的创始人，分享了一个为什么自动化如此重要的快节奏体验的报告-它将如何帮助你的策略建立一个强壮持久的论点。Zuevz应该知道：他的公司的自动化工具将公司的客户关系应用数据导入谷歌分析。但实际上是公司的内部经验使顾客培训进程自动化从而出现了一个闪耀的时刻。
|
||||
|
||||
“起初， 我们曾尝试去建立整个培训机制，结果这个项目搁浅了好几个月，”Zuev说道。“认识到这将无法继续下去之后，我们决定挑选其中的一个能够有巨大的时效的领域，而且立即启动。结果我们只用了一周就实现了其中的电子邮件序列的目标，而且我们已经从被亵渎的体力劳动中获益。”
|
||||
|
||||
## 4. 出售主要部分也有好处
|
||||
|
||||
循序渐进的方法并不会阻碍构建一个宏伟的蓝图。就像以个人或者团队的水平来制定方案是一个好主意，帮助人们理解全公司的利益也是一个不错的主意。
|
||||
|
||||
“如果我们能够加速达到商业需求所需的时间，那么一切质疑将会平息。”
|
||||
|
||||
Eric Kaplan, AHEAD的首席技术官，赞同通过小范围的胜利来展示自动化的价值是一个赢得人心的聪明策略。但是那些所谓的“小的”的价值揭示能够帮助你提高人们的整体形象。Kaplan指出个人和组织间的价值是每个人都可以容易联系到的领域。
|
||||
|
||||
“最能展现的地方就是你能够在节约多少时间，”Kaaplan说。“如果我们能够加速达到商业需求所需的时间，那么一切质疑将会消失。”
|
||||
|
||||
时间和可伸缩性是业务和IT同事的强大优势，都被业务的增长控制，能够被控制。
|
||||
|
||||
“自动化的结果是伸缩灵活的-每个人只需较少的努力就能保持和改善你的IT环境”，红帽的全球服务副总裁John最近提到。“如果增加人力是提升你的商业的唯一途径，那么伸缩灵活就是白日梦。自动化减少了你的人力需求而且提供了IT演进所需的灵活性和韧性。”(详细内容请参考他的文章，[DevOps团队对CIO的真正需求是什么。])
|
||||
|
||||
## 5. 推广你的成果。
|
||||
|
||||
在你自动化策略的开始时，你可能是在目标和要达到目标的预期利益上制定方案。但随着你的自动化策略的不断演进，没有什么能够比现实中的实际结果令人信服。
|
||||
|
||||
“眼见为实，”ADP的首席技术官Nagrath说。“没有什么比追踪记录能够平息质疑。”
|
||||
|
||||
那意味着，不仅仅要达到你的目标，还要准时的完成-这是迭代的循序渐进的方法论的另一个不错的解释。
|
||||
|
||||
而量化的结果如比列的提高或者成本的节省可以大声宣扬出来，Nagrath建议他的IT领导者的同事们在讲述你们的自动化故事的时候不要仅仅止步于此。
|
||||
|
||||
为自动化提供案列也是一个定性的讨论，通过它我们能够促进问题的预防，归总商业的连续性，减伤失败或错误，而且能够在他们处理更有价值的任务时承担更多的责任。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://enterprisersproject.com/article/2018/1/how-make-case-it-automation
|
||||
|
||||
作者：[Kevin Casey][a]
|
||||
译者：[FelixYFZ](https://github.com/FelixYFZ)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://enterprisersproject.com/user/kevin-casey
|
||||
[1]:https://enterprisersproject.com/article/2017/10/how-beat-fear-and-loathing-it-change
|
||||
[2]:https://enterprisersproject.com/article/2018/1/it-automation-best-practices-7-keys-long-term-success?sc_cid=70160000000h0aXAAQ
|
||||
[3]:https://www.adp.com/
|
||||
[4]:https://www.cyxtera.com/
|
||||
[5]:http://gaconnector.com/
|
||||
[6]:https://www.thinkahead.com/
|
||||
[7]:https://www.redhat.com/en?intcmp=701f2000000tjyaAAA
|
||||
[8]:https://enterprisersproject.com/article/2017/12/what-devops-teams-really-need-cio
|
||||
[9]:https://enterprisersproject.com/email-newsletter?intcmp=701f2000000tsjPAAQ
|
||||
@ -0,0 +1,81 @@
|
||||
从专有到开源的十个简单步骤
|
||||
======
|
||||
|
||||
"开源软件的确不是很安全，因为每个人都能使用它，而且他们能够随意的进行编译并且用他们自己写的不好的东西进行替换。"举手示意：谁之前听说过这个？1
|
||||
|
||||
当我和顾客讨论的时候，是的，他们有时候会让我和顾客交谈，对于场景2的人来说这是很常见的。在前一篇文章中，"[许多人的评论并不一定能防止错误代码]"，我会
|
||||
谈论尤其是安全的软件这块--并没有如外界所说的那样比专有软件安全，但是和专有软件比起来，我每次还是比较青睐开源软件。但我听到--关于开源软件不是很安全--表明了有时候仅仅解释开源需要工作投入是不够的，但是我们也需要积极的参与进去。
|
||||
|
||||
我并不期望能够达到牛顿或者维特根斯坦的逻辑水平，但是我会尽我所能，而且我会在结尾做个总结，如果你感兴趣的话可以去快速的浏览一下。
|
||||
|
||||
### 关键因素
|
||||
|
||||
首先，我们必须明白没有任何一款软件是绝对安全的。无论是专有软件还是开源软件。第二，我们应该接受确实还是存在一些很不错的专利软件的。第三，也存在一些不好的开源软件。第四，有很多优秀的，很有天赋的，专业的架构师，设计师和软件工程师设计开发专利软件。
|
||||
|
||||
但也有些摩擦：第五点，从事专有软件的人员是有限的，而且你不可能总是能够雇佣到最好的员工。即使在政府部门或者公共组织--他们拥有丰富的人才资源池，但在安全应用这块，他们的人才也是有限的。
|
||||
|
||||
第六点，开发，测试，提升改善开源软件的人总是无限的，而且还包含最好的人才。第七(也是我最欢的一)，这群人找那个包含很多编写专有软件的人才。第八，许多政府或者公共组织开发的软件也都逐渐开源了。
|
||||
|
||||
第九，如果你在担心你在运行的软件的不被支持或者来源不明，好消息是：有一批组织会来检查软件代码的来源，提供支持和补丁更新。他们会按照专利软件模式那样去运行开源软件：他们的技术标准就是去签署认证以便你可以验证你正在运行的开源软件不是来源不明或者是恶意的软件。
|
||||
|
||||
第十点（也是这篇文章的重点），当你运行，测试，在问题上进行反馈，发现问题并且报告的时候，你正在为共福利贡献知识，专业技能以及经验，这就是开源，正因为你的所做的这些而变得更好。如果你是通过个人或者提供支持的商业组织，，你已经成为了这个组织的一部分了。开源让软件变得越来越好，你可以看到它们的变化。没有什么是隐藏封闭的，它是完全开放的。事情会变坏吗？是的，但是我们能够及时发现问题并且修复。
|
||||
|
||||
这个共享福利并不适用于专有软件：保持隐藏的东西是不能照亮个丰富世界的。
|
||||
|
||||
我知道作为一个英国人在使用联邦这个词的时候要小心谨慎的；它和帝国连接着的，但我所表达的不是这个意思。它不是克伦威尔在对这个词所表述的意思，无论如何，他是一个有争议的历史人物。我所表达的意思是这个词有共同和福利连接，福利不是指钱而是全人类都能拥有的福利。
|
||||
|
||||
我真的很相信这点的。如果i想从这篇文章中国得到一些虔诚的信息的话，那应该是第十条：共享福利是我们的遗产，我们的经验，我们的知识，我们的责任。共享福利是全人类都能拥有的。我们共同拥有它而且它是一笔无法估量的财富。
|
||||
|
||||
### 便利贴
|
||||
|
||||
1. （几乎）没有一款软件是完美无缺的。
|
||||
2. 有很好的专有软件。
|
||||
3. 有不好的专有软件。
|
||||
4. 有聪明，有才能，专注的人开开发专有软件。
|
||||
5. 从事开发完善专有软件的人是有限的，即使在政府或者公共组织也是如此。
|
||||
6. 相对来说从事开源软件的人是无限的。
|
||||
7. …而且包括很多从事专有软件的人才。
|
||||
8. 政府和公共组织的人经常开源它们的软件.
|
||||
9. 有商业组织会为你的开源软件提供支持.
|
||||
10. 贡献--即使使用--为开源软件贡献.
|
||||
|
||||
|
||||
|
||||
1 OK--you can put your hands down now.
|
||||
|
||||
2 Should this be capitalized? Is there a particular field, or how does it work? I'm not sure.
|
||||
|
||||
3 I have a degree in English literature and theology--this probably won't surprise regular readers of my articles.4
|
||||
|
||||
4 Not, I hope, because I spout too much theology,5 but because it's often full of long-winded, irrelevant humanities (U.S. English: "liberal arts") references.
|
||||
|
||||
5 Emacs. Every time.
|
||||
|
||||
6 Not even Emacs. And yes, I know that there are techniques to prove the correctness of some software. (I suspect that Emacs doesn't pass many of them…)
|
||||
|
||||
7 Hand up here: I'm employed by one of them, [Red Hat][3]. Go have a look--it's a fun place to work, and [we're usually hiring][4].
|
||||
|
||||
8 Assuming that they fully abide by the rules of the open source licence(s) they're using, that is.
|
||||
|
||||
9 Erstwhile "Lord Protector of England, Scotland, and Ireland"--that Cromwell.
|
||||
|
||||
10 Oh, and choose Emacs over Vi variants, obviously.
|
||||
|
||||
This article originally appeared on [Alice, Eve, and Bob - a security blog][5] and is republished with permission.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/17/11/commonwealth-open-source
|
||||
|
||||
作者：[Mike Bursell][a]
|
||||
译者：[FelixYFZ](https://github.com/FelixYFZ)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://opensource.com/users/mikecamel
|
||||
[1]:https://opensource.com/article/17/10/many-eyes
|
||||
[2]:https://en.wikipedia.org/wiki/Apologetics
|
||||
[3]:https://www.redhat.com/
|
||||
[4]:https://www.redhat.com/en/jobs
|
||||
[5]:https://aliceevebob.com/2017/10/24/the-commonwealth-of-open-source/
|
||||
Loading…
Reference in New Issue
Block a user