这是一个创建于 3371 天前的主题，其中的信息可能已经有所发展或是发生改变。
刚才发现一个前同事的 Github 上有两个 star 很多的项目，一个是收集型的 markdown 项目，另一个是被用在好几个知名国外公司的前端组件。
像第一个项目这样的资源收集型的高 star 项目，在国内大神中其实常见。
我好奇的是第二个项目（这里称作 B ）是怎么被多个知名公司用的，我发现代码是来自别的项目（这里称作 A ， A 和 B 的前期 commit 都是相同的，但 B 不是 fork 了 A ，因为没有`forked from xxxx`，没有 fork ，这样会误导人认为整个项目都是他做的）， A 项目好几年都没人维护了，然后 A 项目的 issue 下发个新的 issue 链接到 B ，并承诺会维护，然后 B 的 star 就越来越多了。
所以，这里是有个提高自己知名度的方法的：
1 、找个知名的长时间不维护的项目
2 、 import 这个项目（而不是 fork ）
3 、维护一段时间，例如修复几个原项目的 issue
4 、在原项目上发个 issue ，说我的这个是一直在维护的，修复了某某某 BUG 等等
5 、原来项目的用户可能会 star 这个项目
6 、面试官或其他人看到后，可能会以为，原来 XXX 是他做的啊，是大神
大家怎么看 markdown 大神和上面这种方式的大神？
（项目地址就不贴了，无仇无怨的，只是想讨论下我刚才发现的这种方式）
像第一个项目这样的资源收集型的高 star 项目，在国内大神中其实常见。
我好奇的是第二个项目（这里称作 B ）是怎么被多个知名公司用的，我发现代码是来自别的项目（这里称作 A ， A 和 B 的前期 commit 都是相同的，但 B 不是 fork 了 A ，因为没有`forked from xxxx`，没有 fork ，这样会误导人认为整个项目都是他做的）， A 项目好几年都没人维护了，然后 A 项目的 issue 下发个新的 issue 链接到 B ，并承诺会维护，然后 B 的 star 就越来越多了。
所以，这里是有个提高自己知名度的方法的：
1 、找个知名的长时间不维护的项目
2 、 import 这个项目（而不是 fork ）
3 、维护一段时间，例如修复几个原项目的 issue
4 、在原项目上发个 issue ，说我的这个是一直在维护的，修复了某某某 BUG 等等
5 、原来项目的用户可能会 star 这个项目
6 、面试官或其他人看到后，可能会以为，原来 XXX 是他做的啊，是大神
大家怎么看 markdown 大神和上面这种方式的大神？
（项目地址就不贴了，无仇无怨的，只是想讨论下我刚才发现的这种方式）
 | 1 leaves615 2017 年 1 月 31 日  2 根本就是窃取。 |
 | 2 gfexfizv 2017 年 1 月 31 日 via Android 2 这样有意思吗？职业道德听说过吗？ |
 | 3 ryd994 2017 年 1 月 31 日 via Android 2 看看 commit history 全暴露了 真要是死掉了的项目能有人接手是好事，比如 pillow 前提是真的接了 其次不巧遇上 Google 的领导直接 KO |
| 4 ryd994 2017 年 1 月 31 日 via Android 会 Google 的领导 |
 | 5 88250 2017 年 1 月 31 日 你提到的这个大神在告诉我们一个道理：事实胜于雄辩 |
 | 6 rocksolid 2017 年 1 月 31 日 2 也要分得，我觉得能有几次重要升级维护那也无可厚非 |
 | 7 learnshare 2017 年 1 月 31 日 2 |
 | 8 momocraft 2017 年 1 月 31 日 1 不诚实减人品 |
 | 9 NvSylvanas 2017 年 1 月 31 日 1 如果真的是维护好了，我觉得也不是坏事 |
 | 10 Pastsong 2017 年 1 月 31 日 2 维护挺好的啊, fork 的关系本来就可以删掉的, 只要遵循 licences 就好. 何况还是原作者不维护的, 那就更没有问题了. 如果领导看不出来是领导不行吧... |
11
srx1982 2017 年 1 月 31 日 1 所以，按你文中写的这么玩 github ，最终目的就是给面试官或其他人看，为了成为对方口里的大神对吗？
 | 12 xcatliu 2017 年 1 月 31 日 7 收集型的 Markdown 项目很常见，有 stars 也很正常，有没有价值大家都知道。 Fork 的项目取决于源项目的协议。如果协议允许重新修改再分发，那么即使不声明源项目，法律上和道德上也都完全没问题。 开源需要持续的付出，表面上看他有很多 stars ，很风光，让人羡慕嫉妒。背后说不定也付出过很多的精力。 总结一句话，只要是符合开源精神的，都值得鼓励。 |
 | 13 nyanyh 2017 年 1 月 31 日 用心点做个 awesome-xxx ，保持更新并吸取别人的建议，弄多点 star 不难吧 |
| 14 learnshare 2017 年 1 月 31 日 1 @nyanyh awesome xx 只能吸引 star ，极少有人看，只满足了收集癖而已 |
 | 15 SharkIng 2017 年 1 月 31 日 如果真的持续维护一个已经不维护的好项目，即使是 fork 的也没关系吧？ |
 | 16 alwjlola 2017 年 1 月 31 日 via Android 直接 fork 修改吧。 |
 | 17 but0n 2017 年 1 月 31 日 via iPhone 1 读书人的事 怎么能叫偷？ |
18 Syc 2017 年 1 月 31 日 via Android 1 一个长期不维护 /停止维护的开源项目，在无法联系上原作者寻取授权的情况下，遵循原项目的协议并在其原有基础上的进行二次维护更新重新分发是值得允许的和肯定的。 署名不带原作者不代表原项目属于他，但他维护的部分值得署名。 |
 | 19 loading 2017 年 1 月 31 日 via Android 真当面试的是傻子？ 你是不想在这个圈子里找工作了是不是？ |
 | 20 hjlmjx 2017 年 1 月 31 日 via Android 只能说，百度垃圾，不如谷歌 |
 | 21 zgqq 2017 年 1 月 31 日 via Android @learnshare 同感 |
 | 22 PythonAnswer 2017 年 1 月 31 日 kennethreitz 也搞列表。。。你们怎么看 |
 | 24 xcodebuild 2017 年 1 月 31 日 有人维护也算个好事，但这个 star 不瞎就能看出来，没意思 |
 | 25 Hamniba 2017 年 1 月 31 日 谁说这样子的人就是「大神」了？ 投机取巧的人哪里的有。/div> |
 | 26 xrr2016 2017 年 1 月 31 日 有人维护挺好的,加个注明就好了 |
 | 27 bianhua 2017 年 1 月 31 日 @xcatliu > 如果协议允许重新修改再分发，那么即使不声明源项目，法律上和道德上也都完全没问题。 只可惜这句话很容易就被人理解成“改掉了 Copyright 也没问题”，然后连原作者一起都被删除了。 |
 | 28 fffflyfish 2017 年 1 月 31 日 我觉得 star 多的项目一定会有好事者去查的，躲得了初一躲不了十五 |
 | 29 pwcong 2017 年 1 月 31 日 每个 star 都能让我兴奋一整天(●ˇˇ●) |
 | 30 CrispElite 2017 年 1 月 31 日 @but0n 233333333333 |
 | 31 rashawn 2017 年 2 月 1 日 via iPhone 楼主为啥说前同事 刚当你同事的时候为啥不知道 你俩不写同一个语言？ |
 | 32 mintist 2017 年 2 月 1 日 其实， markdown 收集型的价值是 垂直领域的优质资源聚合，有利于普及和减小不必要的搜索，也省电了不是， |
 | 33 binaryer 2017 年 2 月 1 日 弱弱问一句 收集型是什么意思？ |
 | 34 yjxjn 2017 年 2 月 2 日 via iPhone @binaryer 不是代码类的 repo ，比如 gfwlist 啊， adblock list 这一类的，资源整合的 repo …… |
 | 35 hanzichi 2017 年 2 月 2 日 看看 commits ，如果长期维护的，我觉得可以 |
Select Language