何同学犯的错，是每个产品经理都会碰见的“抉择”
最近，何同学的一个视频《我用36万行备忘录做了个动画》，因为想为四年前致敬，将1万行跑马灯做成了36万行，并且声称：“我们专门做了一个软件”。
而视频播出后，画面追溯视频的代码画面，有网友就查询到了源代码的内容来源于github开源项目，发现何同学将其开源源代码的作者名称出处进行抹去，在视频里放出。
加上这一期视频是内容包含了广告厂家，因此这个也被称之为：“恰饭真难吃”。
作为产品经理，源代码搬用其实这个已经是：“软件行业的普遍现象了”
你做产品经理期间会调研开源代码吗？
几乎每个产品经理都会选择：“开原方案”
回顾我们做产品经理的时候，一个ideal或者来自领导的业务需求。
因为刚开始并不知道这个产品会带来多少的用户，考虑到研发进度与成本，以及第一时间实现需求，我们都会选择开源项目作为其基础支撑。
这也就传出了行业里面说的那句话：“初级的程序员都在control+C 和control+V”。
举个例子，我曾经在做iPhone雷达激光APP，也会选择在早期用开源的3D建模算法来完成MVP的产品谁家方案。
所以选择开源方案，大大提升研发效率。
lidar 3d scanner
还有基于医学的3D建模相关算法，也有大量的开源工具，如下面的3d slicer也是用这个工具，快速将Dicom文件建模。
3d slicer 开源项目
产品从MVP成长后，就会推倒重构
由于早期产品没有盈利，并且还不知道产品的商业化可行性，因此早期开源项目都会直接投入使用，最多稍微调整参数即可。
产品从MVP成长后，有了用户数甚至是付费用户，就会进入到资本扩张阶段，等到新资本进来了之后，研发团队就可以开始推进“代码重构了”，这里的重构不是指的是功能全部不要，而是底层逻辑代码结构重写。
图片来自网络
即使没有资本加入，本身产品在线上持续的用户量增加，考虑到数据加载速度、代码维护、结构优化，很多开发就会选择在一定量进行重写，并且将开源代码也重写了。
所以这个时候就会把开源的内容推倒重做，变成了“自研化”。
因此这也是大多数产品迭代的过程，从开源品拼凑的MVP再到全部自研
这也是大多数产品迭代过程中，背后的研发规划
何同学应该坚持做一个产品，而不是“一蹴而就”
像何同学这样的视频工作室，很难做一个坚持做产品的初心。因为视频的主题每一期不同，所需要的产品也不同。
自然就不可能有产品迭代的需求，一切低成本的研发、与高效的研发速度，选择开源自然是最小化成本，甚至才能解决问题。
可是，一个好的产品绝对不是来源第一个版本，可能是在第N个版本之后才逐步被用户知道，因此想要一蹴而就做一款产品，是不可能的。
无论多厉害的研发团队或工程师，在碰到一个需求都会面临新技术、算法的调研，都需要调研新技术，不是谁都是可以从0到1，而且也没必要浪费那个时间与精力。
何同学，忘了开源项目也有收费的分类！
相较于其他同学，何同学账户下的用户画像包含了相当多的程序员、产品经理，这些在一线工作的同学，看到了代码截图都会比较敏感甚至是能看懂。
并且现在已经有代码的原作者来回应了：“相信我不是第一个”
而开源项目不等于就是都可以免费用，开源项目也分为3个类型，分别是
商业式开源（收版权费），本质是通过开源这种方式，让大家使用，形成生态后，通过技术服务的方式获得收益。
纯粹的技术分享型，比如GITHUB上的项目，或者以GPL协议开放的项目。他们是从技术分享的角度，把自己的软件和技术分享给大家使用。
结合了二者特点的开源项目授权开源，只有授权后才能够兼容老版本比如LINUX，
以上3个开源类型，只有收费的开源往往是可以持续的，因为这样就可能有收入给到团队，团队才有动力持续的迭代项目与维护。
很多完全免费公开的开源项目要是找不到维护人员，就会年久失修，你需要花费大量的时间解读源代码，也没有被使用的价值。
所以一般产品经理都会选择有人维护的。
今天的分享就在这里
