mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-29 21:41:00 +08:00
73 lines
7.0 KiB
Markdown
73 lines
7.0 KiB
Markdown
[#]: collector: (lujun9972)
|
||
[#]: translator: ( )
|
||
[#]: reviewer: ( )
|
||
[#]: publisher: ( )
|
||
[#]: url: ( )
|
||
[#]: subject: (Open source vs. proprietary: What's the difference?)
|
||
[#]: via: (https://opensource.com/article/20/2/open-source-vs-proprietary)
|
||
[#]: author: (Seth Kenlon https://opensource.com/users/seth)
|
||
|
||
Open source vs. proprietary: What's the difference?
|
||
======
|
||
Need four good reasons to tell your friends to use open source? Here's
|
||
how to make your case.
|
||
![Doodles of the word open][1]
|
||
|
||
There's a lot to be learned from open source projects. After all, managing hundreds of disparate, asynchronous commits and bugs doesn't happen by accident. Someone or something has to coordinate releases, and keep all the code and project roadmaps organized. It's a lot like life. You have lots of tasks demanding your attention, and you have to tend to each in turn. To ensure everything gets done before its deadline, you try to stay organized and focused.
|
||
|
||
Fortunately, there are [applications out there][2] designed to help with that sort of thing, and many apply just as well to real life as they do to software.
|
||
|
||
Here are some reasons for choosing [open tools][3] when improving personal or project-based organization.
|
||
|
||
### Data ownership
|
||
|
||
It's rarely profitable for proprietary tools to provide you with [data][4] dumps. Some products, usually after a long battle with their users (and sometimes a lawsuit), provide ways to extract your data from them. But the real issue isn't whether a company lets you extract data; it's the fact that the capability to get to your data isn't guaranteed in the first place. It's your data, and when it's literally what you do each day, it is, in a way, your life. Nobody should have primary access to that but you, so why should you have to petition a company for a copy?
|
||
|
||
Using an open source tool ensures you have priority access to your own activities. When you need a copy of something, you already have it. When you need to export it from one application to another, you have complete control of how the data is exchanged. If you need to export your schedule from a calendar into your kanban board, you can manipulate and process the data to fit. You don't have to wait for functionality to be added to the app, because you own the data, the database, and the app.
|
||
|
||
### Working for yourself
|
||
|
||
When you use open source tools, you often end up improving them, sometimes whether you know it or not. You may not (or you may!) download the source and hack on code, but you probably fall into a way of using the tool that works best for you. You optimize your interaction with the tool. The unique way you interact with your tooling creates a kind of meta-tool: you haven't changed the software, but you've adapted it and yourself in ways that the project author and a dozen other users never imagined. Everyone does this with whatever software they rely upon, and it's why sitting at someone else's computer to use a familiar software (or even just looking over someone's shoulder) often feels foreign, like you're using a different version of the application than you're used to.
|
||
|
||
When you do this with proprietary software, you're either contributing to someone else's marketplace for free, or you're adjusting your own behavior based on forces outside your own control. When you optimize an open source tool, both the software and the interaction belong to you.
|
||
|
||
### The right to not upgrade
|
||
|
||
Tools change. It's the way of things.
|
||
|
||
Change can be frustrating, but it can be crippling when a service changes so severely that it breaks your workflow. A proprietary service has and maintains every right to change its product, and you explicitly accept this by using the product. If your favorite accounting software or scheduling web app changes its interface or its output options, you usually have no recourse but to adapt or stop using the service. Proprietary services reserve the right to remove features, arbitrarily and without warning, and it's not uncommon for companies to start out with an open API and strong compatibility with open source, only to drop these conveniences once its customer base has reached critical mass.
|
||
|
||
Open source changes, too. Changes in open source can be frustrating, too, and it can even drive users to alternative open source solutions. The difference is that when open source changes, you still own the unchanged code base. More importantly, lots of other people do too, and if there's enough desire for it, the project can be forked. There are several famous examples of this, but admittedly there are just as many examples where the demand was _not_ great enough, and users essentially had to adapt.
|
||
|
||
Even so, users are never truly forced to do anything in open source. If you want to hack together an old version of your mission-critical service on an old distro running ancient libraries in a virtual machine, you can do that because you own the code. When a proprietary service changes, you have no choice but to follow.
|
||
|
||
With open source, you can choose to forge your own path when necessary or follow the developers when convenient.
|
||
|
||
### Open for collaboration
|
||
|
||
Proprietary services can affect others in ways you may not realize. Closed source tools are accidentally insidious. If you use a proprietary product to manage your schedule or your recipes or your library, or you use a proprietary font in your graphic design or website, then the moment you need to coordinate with someone else, you are essentially forcing them to sign up for the same proprietary service because proprietary services usually require accounts. Of course, the same is sometimes true for an open source solution, but it's not common for open source products to collect and sell user data the way proprietary vendors do, so the stakes aren't quite the same.
|
||
|
||
### Independence
|
||
|
||
Ultimately, the open source advantage is one of independence for you and for those you want to collaborate with. Not everyone uses open source, and even if everyone did not everyone would use the exact same tool or the same assets, so there will always be some negotiation when sharing data. However, by keeping your data and projects open, you enable everyone (your future self included) to contribute.
|
||
|
||
What steps do you take to ensure your work is open and accessible? Tell us in the comments!
|
||
|
||
--------------------------------------------------------------------------------
|
||
|
||
via: https://opensource.com/article/20/2/open-source-vs-proprietary
|
||
|
||
作者：[Seth Kenlon][a]
|
||
选题：[lujun9972][b]
|
||
译者：[译者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/seth
|
||
[b]: https://github.com/lujun9972
|
||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/EDUCATION_doodles.png?itok=W_0DOMM4 (Doodles of the word open)
|
||
[2]: https://opensource.com/article/20/1/open-source-productivity-tools
|
||
[3]: https://opensource.com/tags/tools
|
||
[4]: https://opensource.com/tags/analytics-and-metrics
|