关于如何参与到开源项目中《How To Succeed In Open Source ( In Ways You Haven't Considered Yet )》
转自:http://gaslight.co/blog/how-to-succeed-in-open-source-in-ways-you-havent-considered-yet
It’s Easy to Feel Entitled in the Open Source World
A while back, it was easy to think of open source projects as real products. I think that I thought the contributors of these projects were getting some sort of kickback. I’m not sure what I thought they were getting—I assumed that they were getting something and by golly they better work for it! Probably just prestige points that they could trade for sweet jobs, contracts, instant seating at hot spots. Maybe they’re mega-geniuses whose duty it is to share their insight with the world before they die and take that glorious javascript library with them. That is their duty!
I wasn’t necessarily the type to storm into a github repo and demand a new feature, I can’t remember if I’ve ever stooped that low, but I remember feeling as though these “products” ought to be run with the utmost professionalism. I want bug-free code, a dead simple API, changelogs, clear documentation, and while you’re at it give me a cool website so I can get excited about using your free thing! Its not that I thought through any of this in detail, it was just sort of an expectation that lived below the surface of my psyche.
I don’t think that way anymore. I’ve learned to be extremely appreciative and patient with all of my favorite libraries and frameworks. I’ve learned that open source projects are hard to do right; like really right. Its hard to do a paid project right for that matter. So for those OS projects out there getting it right, I applaud you! Bravo!
And the best way to really learn to appreciate open source and how it works, the only way you can really take a look behind that curtain, is to contribute. Go get a Github account—if you don’t already have one—and contribute.
How I Succeeded By Failing at Open Source
I personally got more involved in open source by writing the documentation for UI-Router. The short version is that I was researching Angularjs and Emberjs as frameworks. I preferred Angular overall but I liked Ember’s router. I wanted Embers routing capabilities to exist for Angular. After some searching, I found out that it didn’t exist. How dare the internet not supply me with a thing!!!
I did find a budding online discussion though. The Angular-UI folks were talking about this very idea of nested routing. Hmph! Well I guess I have to participate in this conversation. And I did. I cared enough to really stick with it too. I reviewed code submissions, I wrote down my thoughts and eventually we all came to a consensus for an API. Wow, I just helped a community move forward with a solution. Many thanks to Karsten for the initial code dump that comprised 0.0.1 and to Nate for keeping the code alive almost single-handedly.
It was a great feeling. I wanted to help more. But that ui-router code is scary and those other guys seem to know it so well and… they are just better than me. I didn’t care. I decided I was going to write the docs. This module would need documentation, it would need an API reference, and a FAQ and of course a Readme. Writing docs is not for “grunts” or “bitches”. Its not an easy task to organize thoughts—especially technical ones—into an easily digestible format. Documentation can make or break an open source project, or any project for that matter (look at Ikea!).
So I wrote them. I didn’t do a good job. Boy did I miss the mark! My docs initially created more confusion than they were supposed to alleviate. I wrote examples incorrectly and just plain lied about some of ui-router’s capabilities because I misunderstood how it worked. But my effort led to action. And some docs were better than no docs. Users started to point out the problems in my documentation (aka the action) and I was able to refactor them over time. It’s easier for people to point out the problems of work that exists than to tell you what work needs to be done. Eventually the docs became a life-saver and a daily check-in point for users of UI-Router. I’ve had people tell me thanks; that they depend on my documentation daily; that it’s well organized. That feels good.
Unsure of How to Help Out?
Contribute your time. It really is the most valuable thing you can give. Beyond that, contribute anything! Whatever is visibly in need of being worked on.
1. Write Documentation
Did you find a typo in the docs? Consider fixing it. It really helps the project showcase itself more professionally.
Or maybe you found that the guide conveyed an idea ineffectively. Try taking a stab at fixing up the errors, or rewriting the confusing bits. My friend, Jim, told me that he’d gone in and fixed up some errors that he found in the guide I wrote, and I’m glad he did. Because the truth is, most of the time I don’t want to work on the project. I want to chill with my family, enjoy a book, or just generally turn off the noise from the day. That’s why doing open source is hard. It’s more time you have to sit at a computer. But this article is trying to show you how its not a lost cause with no ROI. There can be incredible, life-changing returns from helping with open source projects. We’ll get to that in a bit. First what are some other ways you can help out?
2. Report Bugs
Did you find a bug in the behavior of the library/framework? I implore you to write it up. It’s easy to feel that someone else will write the bug, and they may, but I challenge you (and myself) to hear this voice next time you come across your next defect: “Don’t even think about not writing it up. What are you? Would you leave a toilet unflushed? Gross man. You are never too busy to write up a bug for a project that you are using for free. Well maybe you are, but try to at least make a note and write it up later.”
3. Fix Bugs
Did you fix a bug?! Holy shit, digital high five! You’ve already done so much. Submit a pull request asap! If you are still scared of git, then at least write up the bug along with how you fixed it. Just mention that you’re a git newbie, no worries. I honestly don’t think anyone knows git, we all just pretend that we do.
4. Request Features
Want a new feature? Write up an RFC, which stands for Request for Comments. An RFC is basically your idea in full; how you perceive the current shortcoming, how your idea solves it, preferably with some psuedo-code examples, and finally if you are capable, volunteer to implement the feature once a consensus is found. Trust me, no one cares about that feature more than you. The RFC will help you find others who agree with your idea and they can give you feedback and perhaps even volunteer some of their time too. Here’s a great RFC we got recently.
Most of all, don’t be shy. Don’t worry about doing it wrong. Some code on the table is better than no code on the table. Your effort will translate into action. If you put your effort into something then its more likely that the core contributors of the project will support you. Or maybe they’ll hate your idea, but then you’ll all know that’s one idea that won’t work. And you can focus on a new one that might work. Its still progress. Doing it wrong is actually doing it right. Here’s a great quote by Addy Osmani, “First do it, then do it right, then do it better.”
More People Who Won By Writing Docs
Getting back to that ROI thing. I’ve found success from being attached to the ui-router project, in particular writing good documentation. Having that under my belt has opened up so many opportunities to me and helped to expand my network. It isn’t why I contribute, but I’d be lying if I said it wasn’t nice to get that payoff.
There are lots of stories of others who’ve experienced documentation success. Joel Hooks, told me his story. He got his start by writing the documentation for the RobotLegs framework for ActionScript. He stumbled onto his project just like me. After researching it he felt like he found a diamond in the rough. Here was this obscure yet beautiful project. In his heart he knew it needed documentation to become popular. Writing the docs for that one project kickstarted his entire career! He was propelled into an evangelism role for the project and started speaking at conferences (even though speaking was absolutely nerve wracking to him). Writing docs compressed his five year career plan into about one year. Ha, I knew there were kickbacks! He ultimately became a consultant and even wrote a book and now he also teaches important concepts online via articles and video tutorials.
The key point is that he would have never written the RobotLegs framework—it was the stuff of legend—but he could write the fucking docs. I’m crying right now, it’s too beautiful.
I also spoke with Matias Niemelä who found success in a similar fashion. He blogged for a while, mostly about MooTools, hence his site’s name yearofmoo. He started to learn Angular and wasn’t really finding good learning materials on the web (back during the pre-1.0 days). So he made an article on SEO and it was really popular. So he wrote another article and the popularity continued, more and more. This caught the attention of the core team and somewhere between Matias’ third and fourth article Misko (an angular core team member) asked him if he’d be able to help revamp the Angular docs as well as create ng-animate as a contractor for Google. It paid off for Matias.
It paid off because he’s passionate about explaining things in a delicate way that simultaneously pulls incongruent yet pertinent details together into one place. He wanted to remove the need to jump from site to site to fully comprehend a single concept. I think if you look at his articles on SEO, Testing, and Animation, you’ll agree that he’s achieved this goal. Even without his leadership role with ng-animate Matias says he’d still have been perfectly happy only working on documentation. He says “Devs notice what makes their lives easier and will notice good docs.” Matias hinted at a cool new boosted-up interactive guide page that is being worked on as well; should be sweet!
Lastly I chatted with Pete Bacon Darwin, whom I’m still not sure if that’s his real name, if it is that’s awesome! His entire career is based on good vibes from open source. He started out by being helpful in the Angular google group, answering emails. He enjoyed helping, giving back to the community, and never expected anything from it. He was learning by helping. Well again, similar to Matias, the core team took note and asked if he’d like to continue helping officially as a Google contractor. I’m sure that was a no-brainer for him, and he’s even moved on to writing a book for Angular with his friend Pawel.
So now he can spend more time doing what he was already passionate about doing. Pete genuinely thinks that most devs contribute to open source for the feeling of giving back. He acknowledges that there is a sort of prestige that comes with working on a well known project though. However I think an ego boost is a great reward for contributing; we all love to be loved.
Pete’s contributions to open source is a success story. He’s now positioned well in the community, so he gets offers often to consult, train, do code reviews and provide guidance.. He feels when you put effort in, you get it right back. That’s really the magic of open source and why its so successful. It complements (and sometimes augments) our real jobs and lives so well.
Conclusion
As for me, I still don’t think my docs are perfect, but they are good enough. They support the beautiful module that they document. And that is the key, it doesn’t need to be perfect, and open source never is, nothing is! We are working on this together and we are working towards perfection.
关于如何参与到开源项目中《How To Succeed In Open Source ( In Ways You Haven't Considered Yet )》的更多相关文章
- 我参与 Seata 开源项目的一些感悟
丁老师在他的知识星球邀请我回答以下一个问题: 我觉得这个问题非常有意思,姑且把它贴到公众号这里,与大家分享一下我对这个问题的一些感悟. 感谢丁老师的邀请问答: 在这里我就简单说下,我这段时间参与 Se ...
- 怎样在Github参与一个开源项目
转载:http://www.csdn.net/article/2014-04-14/2819293-Contributing-to-Open-Source-on-GitHub 最近一年开源项目特别的热 ...
- 使用github参与到开源项目的维护
参与到开源项目的维护工作一般分两种,一种是由项目建立者拉入到贡献者列表中,拥有对项目的读写权限,而普通用户对项目仅有读取权限,另一种是fork项目到自己仓库,然后把修改后的内容发送给项目管理者者请求合 ...
- dotnet 是 前30个增长最快速度的开源项目中排名第一的开发平台
CNCF 的博客 发了一篇文章 <Update on CNCF and Open Source Project Velocity 2020>,中文翻译参见 2020年CNCF和开源项目开发 ...
- android studio 使用jar包,arr包和怎么使用githup开源项目中的aar包或module
我这里的android studio的版本是2.2.3版本 一.现在大家都用android studio了,就有人问怎么使用jar包 其实使用jar包比较简单 直接吧jar放入工程的app目录下的li ...
- [转]C,C++开源项目中的100个Bugs
[转]C,C++开源项目中的100个Bugs http://tonybai.com/2013/04/10/100-bugs-in-c-cpp-opensource-projects/ 俄罗斯OOO P ...
- 如何参与flink开源项目
参与flink开源项目 https://flink.apache.org/how-to-contribute.html 1.回答社区问题 2.撰写bug报告 3.对于改进建议或新的特征 4.帮助别人并 ...
- 开源项目Telegram源码 Telegram for Android Source
背景介绍 Telegram 是一款跨平台的即时通信软件,它的客户端是自由及开放源代码软件.用户可以相互交换加密与自毁消息,发送照片.影片等所有类型文件.官方提供手机版.桌面版和网页版等多种平台客户端. ...
- 细数Android开源项目中那些频繁使用的并发库中的类
这篇blog旨在帮助大家 梳理一下前面分析的那些开源代码中喜欢使用的一些类,这对我们真正理解这些项目是有极大好处的,以后遇到类似问题 我们就可以自己模仿他们也写 出类似的代码. 1.ExecutorS ...
随机推荐
- RTNETLINK answers: File exists
问题: 重启网络时报错如下 >>/etc/init.d/network start RTNETLINK answers: File exists 分析: /etc/init.d/netwo ...
- py基础4--迭代器、装饰器、软件开发规范
本节内容 迭代器&生成器 装饰器 Json & pickle 数据序列化 软件目录结构规范 作业:ATM项目开发 1. 列表生成式,迭代器&生成器 列表生成式 我现在有个需求, ...
- pythonNet day02
网络收发缓冲区 1.协调读写速度.减少和磁盘交互 2.recv和send实际上是从缓冲区获取内容,和向缓冲区发送内容 recv()特性 1.如果连接断开,recv会立即结束阻塞返回空字符串 2.当接收 ...
- 【UVA】11825 Hackers' Crackdown(状压dp)
题目 传送门:QWQ 分析 $ n<= 16 $ 显然是状压 然后搞一搞(靠着蓝书yy一下) 代码 #include <bits/stdc++.h> using namespace ...
- [Octave] optimset()
Create options struct for optimization functions. optimset('parameter', value, ...); %设置所有参数及其值,未设置的 ...
- linux编程vim设置
linux环境下c网络编程vim编辑工具设置,包括自动缩进,tab键对齐等.
- windows下使用 ApiGen 生成php项目的开发文档
之前使用 PHPDocument 生成过开发文档,但是界面看着不爽,遂尝试了 ApiGen 生成,不得不说界面看着舒服多了,下面说说安装和使用的方法. ApiGen官网: http://www.api ...
- AngularJS学习笔记(2)——与用户交互的动态清单列表
与用户交互的动态清单列表 以我之前写的一个清单列表页面作为例子(MVC模式的清单列表效果),优化前代码如下: <!DOCTYPE html> <html ng-app="t ...
- leetcode38
public class Solution { public string CountAndSay(int n) { //1 //11 //21 //1211 //111221 //312211 // ...
- 动量Momentum梯度下降算法
梯度下降是机器学习中用来使模型逼近真实分布的最小偏差的优化方法. 在普通的随机梯度下降和批梯度下降当中,参数的更新是按照如下公式进行的: W = W - αdW b = b - αdb 其中α是学习率 ...