关于如何参与到开源项目中《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 ...
随机推荐
- JVM体系结构之三:方法区之2(jdk1.6,jdk1.7,jdk1.8下的方法区变迁)
方法区 方法区存储虚拟机加载的类信息,常量,静态变量,即时编译器编译后的代码等数据.HotSpot中也称为永久代(Permanent Generation),(存储的是除了Java应用程序创建的对象之 ...
- 利用PHP实现页面跳转同时POST传参,CURL不行
function payto(){ echo "<form style='display:none;' id='form1' name='form1' method='post' ac ...
- 529. Minesweeper
▶ 扫雷的扩展判定.已知棋盘上所有点的情况(雷区 'M',已翻开空白区 'B',未翻开空白区 'E',数字区 '1' ~ '8'),现在给定一个点击位置(一定在空白区域),若命中雷区则将被命中的 M ...
- How to run eclipse in clean mode? and what happens if we do so?
What it does: if set to "true", any cached data used by the OSGi framework and eclipse run ...
- Symfony 2.0 认识Request, Response, Session, Cookie
在上一节中,我们提到了如何创建一个Bunlde 并且在默认控制器中添加一些方法.如果有参照之前的说法进行的话,读者很有可能会被提示说 返回的Response对象不能为空.好啦,我们就来研究一下,怎么从 ...
- 78. Subsets (Back-Track, DP)
Given a set of distinct integers, nums, return all possible subsets. Note: Elements in a subset must ...
- Oracle 注意点大全
1.索引 经常查询的字段.主表与从表关联主键id必须建立索引.
- soapUI参数中文乱码问题解决方法&soap UI工具进行web接口测试
soapUI参数中文乱码问题解决方法 可能方案1: 字体不支持中文,将字体修改即可: file-preferences-editor settings-select font 修改字体,改成能显示中文 ...
- Unknown type name 'NSString'
今天看到个问题,编辑工程提示Unknown type name 'NSString',如下图 导致出现异常的原因是是因为工程中添加了ZipArchive(第三方开源解压缩库) 一般情况下出现“Unkn ...
- bzr: ERROR: No push location known or specified.
出现这种错误,要先uncommit,然后拉带最新版本,再commit最后push