开源日报 - Page 12 of 262 - Open Source Daily

开源日报第994期：《快速传输 snapdrop》

29 12 月, 2020
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《快速传输 snapdrop》br/> 今日推荐英文原文：《Three Programmers, Three Paths, One Road to Glory》

今日推荐开源项目：《快速传输 snapdrop》传送门：项目链接
推荐理由：这个项目提供了一个方便的文件传输方式——只要在设备上打开这个网页，就能在这里选择这个网络里其他打开了这个网页的设备进行文件传输。而且这个项目在传输数据的过程中没有引入第三方，同时 web 版使用了 WebRTC 来提供加密传输，从而保证隐私不会泄露。如果需要频繁使用的话，也可以选择使用他们在各个平台上的 app。
今日推荐英文原文：《Three Programmers, Three Paths, One Road to Glory》作者：Zachary Minott
原文链接：https://medium.com/better-programming/3-programmers-3-paths-1-road-to-glory-eb337061c995
推荐理由：三种不同的行动模式会带来的截然不同的未来
Three Programmers, Three Paths, One Road to Glory

Which path will you take?

Three Programmers on a Level Playing Field
Imagine three different junior programmers, all working in the same company with relatively similar sensibilities. Each one makes the same $60k per year starting salary, has similar educational backgrounds, and possess the energy of anyone just starting out.

Let’s give them some names: Nathan, Jack, and Devin.

Nathan goes about his career as he always has. He punches into work, completes his tasks for the day, and his most exciting part of the day is when it ends, so he can come home and relax. He thinks he’s happy but sometimes complains that nothing ever changes for him. His head is filled with pestering “what-if” questions and he wonders how long he’ll have to wait until he can get a promotion or simply ascend to a mid-level developer. He’s a good programmer, but he sticks to confidently doing what he knows how to do.

Jack starts making a few poor choices but nothing crazy. His mind often wanders at work and would intermittently get distracted by his phone or other internet browsers he has opened. He focuses on getting the bare minimum requirements done and lives by the “if it works, don’t touch it” programming philosophy. He drinks red bulls at his desk every day to help him focus and regularly indulges in an unhealthy diet of pizza and chips. He’s a great coder, but his knowledge of that fills him with a sense of pride that keeps him from seeking the help of others, asking too many questions, and sharing information with his colleagues. Needless to say, he still gets his tasks done on time and still meets his deadlines.

Devin decides to start making subtle, positive changes. He starts off his days reading at least ten pages of a non-fiction book that may help improve his career and coding skills. He decides to start meditating and even tries brushing up on his coding skills with an online course for 30 minutes a day. He doesn’t hesitate to ask questions at work and he decided that it would be a good idea to send his boss a progress report twice a week to showcase what he’s got done and what he still needs to do. He doesn’t do anything rash and he makes no grand acts — they’re just simple things anyone could do on a consistent basis. He knows he’s a decent coder, but realizes that he could always be better and so he is constantly looking for ways to improve.
3 Months Later
You wouldn’t be able to see any obvious differences between any of these individuals in regards to their overall performance and skillset.
- Jack is enjoying his career with his ability to get things done quickly and deliver at fast rates.
- Devin continues to find ways to constantly sharpen his skills and mind in the healthiest ways he can surmount.
- Nathan simply continues to do as he always has and just shows up to work because it’s his job to do so.
Although each developer has their own pattern of behavior, three months isn’t long enough for any of them to see any noticeable differences in their situation.
9 Months Later
It’s at this point that each developer has started displaying noticeable changes in their situations.

Jack is starting to feel a little bit clouded in the mind and is becoming more lethargic as a result of his unhealthy diet. He’s ramped up his consumption of Red Bulls to two, maybe even three a day as he doesn’t experience the same energy boost as he used to. He’s still getting stuff done, but it’s not getting easier. He’s starting to feel the drawbacks and time delays of the messy yet quick code he wrote over the past months and is starting to feel like he’s lagging.

Devin, on the other hand, is thinking very clearly. He’s shown an innate sharpness and meticulous approach when writing code. He’s not moving any faster than Jack, but he’s writing more quality code than he ever has before and he’s been able to deliver on more advanced tasks. He has developed relationships with the leaders of his company — they have begun to recognize the progress he’s made through his transparency and ability to communicate what he’s been working on.

Nathan is still trodding along, in the same exact place he was before, except he’s a little bit more bitter this time.
18 Months Later
Drastic changes can now be clearly seen between the three programmers.

Jack’s overwhelmed with backlogged work that he’s unable to get done on time. Management is complaining about how his code keeps breaking and that it’s taking far too long for him to modify and identify errors in his code. Other programmers are having trouble discerning what his code does when they come to review it. His performance rating has fallen drastically and mentally he’s not all there. His mind is clouded, he’s tired all the time, and he is unable to properly map things out in his mind as he used to do. He gets distracted easily now and maybe only has one to two productive hours a day. Where at first he thought he was thriving, Jack’s programming career is now in peril.

Devin’s daily positive habits over the past several months have proved to be fruitful. He’s now quickly ascended the ladder to become a technical lead and has tight-knit relationships with all the leaders he looks up to in the company. He produces quality work very regularly and isn’t afraid to share information and mentor those that are below him and even above him. He’s still growing and still changing, but his future in tech is looking extremely bright.

Nathan still hasn’t changed much but, to him, his situation appears to be something that he simply can’t control. He’s actually mystified by Devin’s performance and believes it’s something he wouldn’t be able to replicate.
The Moral of the Story
Many people falsely believe that if they simply stick around long enough to become “more experienced,” they’ll linearly ascend through the ranks of programmers and technical talent.

That’s simply not true.

As we see with these three gentlemen, it’s the apparently insignificant things you do on a consistent basis that, over time, sculpt you into the person that you either want to be or don’t want to be.

Just increasing your awareness of those tiny things helps you to realize what you need to improve upon.

As I regularly preach, great programming talent is produced through a commitment to lifelong, deliberate, learning and practice in both soft and hard skill subject areas.
If you are going to achieve excellence in big things, you develop the habit in little matters. Excellence is not an exception, it is a prevailing attitude. — Colin Powell, Former US Secretary of State
Simply recognize the person that you identify with the most. It’s best to be brutally honest with yourself.

Are you really the Devin? Or are you more like Jack? Most people tend to be like Nathan and just sit around waiting for life to happen.

Remember: When it comes down to it, it’s your decision to make things right and make the change for the better. Your value increases as a result of the small things that you do very regularly.

So ask yourself, which path do you want to choose for your long-term programming career?
- Nathan: The Path of Neutrality
- Jack: The Path of Instant Gratification
- Devin: The Path of Self-Transformation
Maybe you won’t walk the path perfectly, but at least, whatever path you choose, you’ll be intentional about the decisions that you make.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第993期：《数据库 AvenirSQL》

28 12 月, 2020

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《数据库 AvenirSQL》
今日推荐英文原文：《Permanent Smile》

今日推荐开源项目：《数据库 AvenirSQL》传送门：项目链接
推荐理由：该项目是作者用 Node.js 设计的一个数据库，支持常见的 SQL 语句，其目的是了解 MySQL 底层的原理，做学习之用。
今日推荐英文原文：《Permanent Smile》作者：Fọlábòmí Àmọ̀ó
原文链接：https://psiloveyou.xyz/permanent-smile-a3571379bfc7
推荐理由：一首小诗，给自己喜爱的人或事物。
Permanent Smile
You are
my muse

My artistic
inspiration

my creative
direction

The concept
behind my every
love note

The reason
for every pause

gesture
or exclamation

You are
my treasure

The one
beyond
all competition

The reward
of too many
fruitless quests

The prize
above
any expectations

You are
my happiness

the reason
I smile

And you are also
the reason

it never
disappears.

下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第992期：《BiliBiliTool》

27 12 月, 2020

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《BiliBiliTool》
今日推荐英文原文：《Google scientists reportedly told to make AI look more ‘positive’ in research papers》

今日推荐开源项目：《BiliBiliTool》传送门：项目链接
推荐理由：BiliBiliTool不仅可以自动完成每日任务，投币，点赞，直播签到，自动兑换银瓜子为硬币，自动送出即将过期礼物，漫画App签到，大会员领取B币卷等。每天获得65点经验，助你快速升级到Lv6。另外，通过结合GitHub Actions，可以实现每天线上自动运行，只要部署一次，小助手就会在背后一直默默地帮我们完成我们预先布置的任务。还有其他一些小功能，比如漫画签到、直播签到等等。
今日推荐英文原文：《Google scientists reportedly told to make AI look more ‘positive’ in research papers》作者：Corinne Reichert
原文链接：https://www.cnet.com/news/google-scientists-reportedly-told-to-make-ai-look-more-positive-in-research-papers/
推荐理由：路透社周三的报道称，谷歌母公司Alphabet一直要求其科学家确保人工智能技术在他们的研究论文中看起来更加 “积极”。据报道，一项新的审查程序已经到位，因此研究人员在探讨人脸分析以及种族、性别和政治背景等问题之前，会咨询谷歌的法律、政策或公关团队，进行 “敏感话题审查”。
Google scientists reportedly told to make AI look more ‘positive’ in research papers
Google parent Alphabet has been asking its scientists to ensure that AI technology looks more “positive” in their research papers, says a Wednesday report by Reuters. A new review procedure is reportedly in place so researchers consult with Google’s legal, policy or PR teams for a “sensitive topics review” before exploring things like face analysis, and racial, gender and political affiliation.

“Advances in technology and the growing complexity of our external environment are increasingly leading to situations where seemingly inoffensive projects raise ethical, reputational, regulatory or legal issues,” one of the internal webpages on the policy says, according to Reuters.

Other Google authors were told to “take great care to strike a positive tone,” internal correspondence shared with Reuters said.

The report follows Google CEO Sundar Pichai earlier this month apologizing for the handling of artificial intelligence researcher Timnit Gebru’s departure from the company and saying it would be investigated. Gebru left Google on Dec. 4, saying she’d been forced out of the company over an email sent to co-workers.

The email criticized Google’s Diversity, Equity and Inclusion operation, according to Platformer, which posted the full text of her missive. Gebru said in the posted email that she’d been asked to retract a research paper she’d been working on, after receiving feedback on it.

“You’re not supposed to even know who contributed to this document, who wrote this feedback, what process was followed or anything,” she wrote in the email. “You write a detailed document discussing whatever pieces of feedback you can find, asking for questions and clarifications, and it is completely ignored.

“Silencing marginalized voices like this is the opposite of the NAUWU principles which we discussed. And doing this in the context of ‘responsible AI’ adds so much salt to the wounds,” she added. NAUWU stands for “nothing about us without us,” the idea that policies shouldn’t be made without input from the people they affect.

Google didn’t immediately respond to a request for comment.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第991期：《简单粗暴 thebestmotherfuckingwebsite》

26 12 月, 2020

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《简单粗暴 thebestmotherfuckingwebsite》
今日推荐英文原文：《The Biggest Lie in Open Source》

今日推荐开源项目：《简单粗暴 thebestmotherfuckingwebsite》传送门：项目链接
推荐理由：在简单粗暴的外表之下是平时会被忽视的种种网站应当具备的能力。
Good design is as little design as possible. -Some German motherfucker on motherfuckingwebsite.com
今日推荐英文原文：《The Biggest Lie in Open Source》作者：Fernando Doglio
原文链接：https://medium.com/better-programming/the-biggest-lie-in-open-source-de38f71aa88c
推荐理由：解开关于开源的一些误区
The Biggest Lie in Open Source

There are several big ones, so I’ll let you be the judge
Open source is one of the most fascinating things I’ve ever encountered in our industry. It is a movement that essentially groups people together to work on a product because they want to. They usually do it for free, especially during the first stages of the project, and then — get this — they maintain it so that others can use it. Also for free.

I tend to think that if more industries were to adopt open source as we do in software development, things would be a lot easier. Then again, that’s not why we’re here. In fact, this amazing, almost nirvana-like movement of open source is not as perfect as one might think because people are involved in it, and people aren’t perfect.

During the lifespan of what we call open source, a lot of misconceptions have been created around it. Most of them come from either not being an active part of it (i.e. only consuming its products but never contributing to it) or having bad luck and participating in the wrong first project, thus destroying what could’ve been an amazing experience.

My intention with this article is to cover some of the most common lies about open source in our industry so you, the newcomer, can decide for yourself whether you want to be part of the movement or not.

Let’s do this.

Full disclosure: This article was inspired by this tweet by Dan Abramov. I took the prompt and went with it.
It’s Free of Cost, Thus It Must Be Free to Use
Who hasn’t heard this one, right? Open source is free. We’re literally able to download libraries from places like GitHub without any costs, and we as developers know that we can publish there for free as well.

So as long as we have our computer at hand, we can create code and share it with an amazing industry all for free.

Wrong.

We tend to associate costs with resources — usually physical resources — but since we already have a computer, what other resources do we need to produce and maintain open source software?

Your time.

That’s right: Your time is a resource. In fact, it’s one of the most valuable resources you have and you’re thinking about giving it away for free? Think again. The time you spend working on an open source project is probably time you’re not getting compensated for by your employer (unless you’re building that project for them). So if there is no income in exchange for your time, what are you exchanging? Time with your loved ones? The time you could be spending relaxing? Hours of sleep? Exercising time?

Your time is valuable and so is the time of everyone involved in an open source project. Simply because they’re willing to make the sacrifice of building something open for you to use doesn’t mean you’re entitled to demand whatever it is you’re thinking of demanding. I’ve seen people demand 24-hour support or that their features get accepted because they need them for their own (private) projects. The list goes on.

Depending on the project, you can be looking at a one-man team or a huge group led by a committee inside it spending time and other resources (yes, sometimes they need to spend money on these projects) so you can have that library or framework for free. So next time you’re thinking about complaining about an OSS project, consider the cost it has on its maintainers.
It Can’t Be a Source of Income
Open source software is free. Therefore, its maintainers and creators can’t make a living out of it.

Wrong.

At first glance, open source software is free for its users. But there is a lot more to understand before saying it can’t be a valid source of income.

Like with any digital product, making money is all about your business model and the marketing strategy behind it. If you’re interested in making money from open source projects, here are some ideas for you to consider.
Selling professional services
This is the most common one. As I’ve said before, people tend to assume that because you’ve built a project and published it to the world, you need to support it 24 hours a day. That’s not only untrue, but it’s definitely a whole different area of work. So why not charge for it?

In fact, why not charge for training as well and even provide support for companies trying to use your free product? Those are what we call professional services (services meant for companies using your product).

There are big examples of open source projects doing this exact thing. For example, RedHat, IBM, Hortonworks (around Apache Hadoop), and Percona (for their open-source database).
Selling related content
How many books have you seen (or even read) about React or PHP? The books weren’t free, were they?

If you managed to build an open source project that people like and use, then you can make money by giving those people products they can use to learn how to use it. This is very similar to the professional services model, yet that one implies you’re personally involved (thus allowing you to charge higher rates). However, with products, you can build cheap alternatives that are accessible to non-company users (i.e. developers trying to use your code).

Even if you’re not the project’s author, you can benefit from their success by doing this exact same thing. You’re building products around an open source project (just not your own).

We’re talking about writing books about it, creating video courses for platforms such as Udemy, or even writing sponsored blog posts about these OS projects. Why not? Sometimes, authors will be willing to pay you money to write about their projects.
Donations
You can make money from people donating to your cause. Don’t be afraid to ask for money. As long as it’s done tastefully, it’s definitely a valid income option.

And if you’ve built a project that a big community is using, you’ll be surprised at the results. Looking at projects such as Git, you’ll see that they do receive donations from anyone interested in their cause.

It’s all about the reach your project has and the community built behind it. If it’s big enough, then there is probably a way to make money out of it.

There are many other ways you can go about building income from your open source work. It’s just a matter of getting creative.
Your Contributions to It Define You as a Developer
We all know that only developers who contribute to open source are worthy of the name, right?

Wrong.

Being able to contribute to open source (be it in the form of a project or through a PR to someone else’s project) is a privilege — not a requirement to get a job or to be considered good at what you do.

Yes, OS contributors indeed benefit from their work by having it be public. This, in turn, allows both the industry and potential employers to find their work and get a somewhat biased level of understanding of their skills. However, it is also true that there are great closed-door developers out there unable to benefit from the same thing.

Sure, you can say that they could take the time to contribute, but maybe they value their time in a different way than you do, thus rendering them unable to publish or contribute to OSS.

What I’m calling out here is the fact that some companies or even some other developers assume you’re great at what you do if you do open source. Otherwise, you’re a corporate rat who’s unable to write a single if statement without looking it up on Google.

And that is completely and utterly wrong. So stop doing it, OK?
Maintaining Open Source Code Is Easy
What can I say about this one? Maintaining any type of project is not easy, period. Add to that the fact that you’re doing it out of the goodness of your heart and you’ll start seeing the problem.

When you’re building some closed-code project, you may have to share your code with four, maybe five other developers. When you’re maintaining open source code, the entire industry is capable of reviewing, commenting, and publicly shaming you for the code you wrote. So no pressure there, bud!

There are many articles out there stating that one of the benefits of open source is that it forces you to write clean and maintainable code because of this fact. To me, being pressured into writing quality code is not a big selling point, but to each their own, right?

Back to the point: Maintaining code that millions of developers could be using is a big responsibility. Even if you have the entire community trying to help, how can you be sure they have the same standards as you do? How can you be sure those ten PRs waiting for your review have considered all the potential security risks they could be adding to the project?

Maintaining an open source project is a very difficult task if you do it right. Unfortunately, it can quickly lead to burnout. Back in 2018, a hacker gained control of an open source repository and introduced code to steal personal information. And that person did it because the owner and maintainer of an OS project being used by millions of other developers was so burnt out by the responsibility of keeping up with the requests of the community that they decided to give the project to someone else.

They were tired and someone else took over.
It’s Easy to Get Into
There are plenty of open source projects, so surely it must be simple for someone to get started, right?

Wrong.

If you’re looking to start contributing to OSS projects, finding one that is actively looking for help and then helping in a way that the project’s maintainers will accept is not that easy. Some projects openly state that they’re looking for help and they even tag issues that are perfect for newcomers (a perfect example is Node.js, which tags its issues with “Help wanted” or “Good first issue” so you know where to start).

There are, of course, projects that don’t do this — either because they’re not looking for external help or they don’t have experience with people wanting to contribute to their projects.

If, on the other hand, you’re looking to get help on your own OSS project, then things are even harder because there is really no place for you to go and find help. Yes, if you have a large following on social media, you can probably find people. Otherwise, you’re depending on the popularity of your project and the interest it generates in others.
You Can Copy the Code and Do Whatever You Want With It
It’s free code after all, right?

Well, not exactly.

The pirate in all of us (admit it, we all have one) tends to think that if a piece of code is available for free, then we can do anything with it. And that includes copying the code and redistributing it under another name or even taking credit for it.

This is why we invented licenses (actually, I don’t know for sure whether that’s the case, but you get the point). Every open source project that hopes to get used and reach some kind of audience should consider picking a license.

This controls the way people can use, change, and redistribute it, protecting both you and your users from any illegal actions that might take place.

Contrary to popular belief, a lack of a license does not mean you can do anything with the code. If you find a public project on a place such as GitHub, there are already some restrictions and implications agreed upon in the Terms of Service by the author of the repository. So if you, as a user, find a project that has no license, consider that its author actually decided to not share their code with anyone and that you can’t use it.

If you’re an author and want to understand which is the best license for your project and your intentions with it, refer to Choose a License to get started.

Licensing should be mandatory for all open source projects. And if you’re looking to help or even use one, you should pay attention to the implicit restrictions associated with the chosen license.
Conclusion
There are many assumptions developers have about open source software because we don’t normally pay for it. That being said, those assumptions are wrong and affect both the projects themselves and the lives of their authors and maintainers.

In your opinion, what is the biggest lie about open source? Leave a comment down below and share your opinion!
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/

开源日报第994期：《快速传输 snapdrop》

Three Programmers, Three Paths, One Road to Glory

Which path will you take?

Three Programmers on a Level Playing Field

3 Months Later

9 Months Later

18 Months Later

The Moral of the Story

开源日报第993期：《数据库 AvenirSQL》

Permanent Smile

开源日报第992期：《BiliBiliTool》

Google scientists reportedly told to make AI look more ‘positive’ in research papers

开源日报第991期：《简单粗暴 thebestmotherfuckingwebsite》

The Biggest Lie in Open Source

There are several big ones, so I’ll let you be the judge

It’s Free of Cost, Thus It Must Be Free to Use

It Can’t Be a Source of Income

Selling professional services

Selling related content

Donations

Your Contributions to It Define You as a Developer

Maintaining Open Source Code Is Easy

It’s Easy to Get Into

You Can Copy the Code and Do Whatever You Want With It

Conclusion