通过《实战做项目如何选择开源许可协议(一)-了解协议》大概知道了有哪些开源协议和各个协议的作用和区别。我们准备把代码开放出去时,需要了解各个代码托管平台如何设置开源协议。目前常用的平台有:googlecode、github、sourceforge、codeplex。下面分别列一下这些平台如何设置开源协议:

1、googlecode,google推出的代码托管平台,整体可用还是比较强的,如果不是经常被墙用这个也可以。支持svn、git协议。要在这个上面共享代码,

  • 首先需要注册一个google账号,登录。
  • 在url输入 http://code.google.com/intl/zh-CN/ ,打开网页后,最下方有个 create a new project。

  • googlecode1

  • 点击创建工程后,可以选择自己工程的开源协议。预定义协议支持不是太多,主要有常见的BSD、GPL、MIT、APACHE、ECLIPSE、MPL。没有包含的可以选择other open source 填写。

  • googlecode2

2、github, 这个后期之秀,由于git协议本身的优势这几年也赚足了眼球。更有2011年的报道: Github 的提交次数超过了Sourceforge、Google Code和微软的CodePlex。 这么火的代码托管工具我们当然也要在这个上面共享代码,

  • 需要注册一个github账号,登录。
  • 在首页中间有个 create repositories,创建代码工程。

    github1

    和google code 不同的是,github没有直接选择开源协议这一项。这篇文章可以看得出GitHub一族,正在推动开源软件走向无授权时代。如果要在github设置开源协议如何设置呢?其实很简单,在刚创建的工程主页,点击添加文件按钮。

    github2

    新建一个文件LICENSE(这个命名随意,只要能说明清楚就行),把你需要设置的协议内容复制到对应的文件中去就可以了。当然你想特别说明一下,也可以在项目主页的readme.txt中说明。比如 https://github.com/apache/activemq 的license 设置。
    这个license可以根据自己需要设置,不过最好还是标准模板大家更规范一些。

github3

刚写完github没法设置,今天登录却发现github已经增加了开源协议选项,csdn也有了相关的新闻《Github 终于开始认真考虑开源项目许可证了》。看来任何地方都还是需要规范化,毕竟开源本身就是一个社会群体活动,有了大家的积极参与才能长久持续下去。

github4

ps:托管Git (开源或闭源)项目的网站闭源需要收费,最低7$/月起,另有免费的300G空间,超过也要单独收费,不过作为咋普通开源项目也足够了。

3、sourceforge,曾经很辉煌的全球最大开放源代码软件开发平台和仓库,现在虽然有github这样的竞争者追赶,但依然还是老大。它有这些优势:无带宽限制、提供下载统计分析、每天巨大的流量增加你的文件的曝光率、SourceForge 在开源领域可信度高、支持svn和git协议。

  • 注册登录到sourceforge。
  • 创建project。sourceforge的创建project隐藏的有点深。在登录后的右上角有个me,旁边小三角点击弹出层选中Account。

  • sourceforge1

  • 然后在account页选中projects tab,右边有个 Register a New Project超链接,点击就可以创建项目了。

  • sourceforge2

  • 设置开源协议,点击项目进入项目主页,选择admin tab =》 左侧导航Categoryization =》 页面 license。

sourceforge4

sourceforge的协议支持非常多,有开源协议控的可以多看看,不得不说这个界面操作还是有点复杂。

4、codeplex。最后再看看微软的这个代码托管工具。打开页面设计的还比较直接,显示了几个大按钮,可以很容易就点击到。看到首页界面不知道设置开原协议如何操作?是不是像界面这几个按钮一样简单。

codeplex1

  • 登录codeplex,可以使用微软账号登录。
  • 创建项目,在项目创建页依然没有协议设置,只有googlecode有。
  • 点击创建的project,进入project的设置页面,选择 license tab,点击 tab下方右边一点的 change license链接后 找到自己需要的协议设置。它支持的协议和google code差不多,多了微软协议和CDDL。

    codeplex2

比较了目前最常见的集中开源项目托管平台对开源协议的支持和如何操作,大家按自己需求选择吧。

原创文章,转载请注明: 转载自LANCEYAN.COM

本文链接地址: 实战做项目如何选择开源许可协议(二)- 开放代码

目前国内开源项目正在逐渐升温,中国也开始有不少优秀的开源项目突显出来。在大家摩拳擦掌准备加入开源大军时,也要知道这个圈子里的规则。技术人员不能只是研究技术,任何圈子都有规则,要知道了才能玩得好。前段时间有件关于开源软件的事情挺热闹的,关于国内一个开发者把自己作品开源出来被别的公司的人拿去包装成自己的产品高价卖出去。大部分做开源软件的开发者都不太怎么关注版权这些,具体微博如下:

hoowa_sun
做开源后,发现大部分都被别人拿去学习,然后copy,然后自己闭源卖出去。这里不缺乏大公司,有一家公司拿我的开源系统修改后卖给了一个国内的运营商,卖的还非常贵至少几十万一套。所以我郑重的建议大家,做软件还是要英文版开源,中文版封闭不要开源。

在国内大家习惯了使用盗版、破解,看到这种免费的软件也觉得是理所当然的拿来主义,甚至直接封装到自己的商业组件卖出去。如果你正在这样做,马上停下来研究一下使用的这些开源组件的许可协议,不然某一天你会意外收到一封法院的传票。如果你在开发或者准备开发开源软件,但尚对开源许可协议不了解,也看下这篇文章,选择一种开源许可协议保护你的开源软件。

常见的开源许可协议有:GPL、LGPL、BSD、Apache Licence vesion 2.0、MIT。这些协议有什么区别呢?

  • GPL,全称 GNU General Public License。它的主要内容为:只要在一个软件中使用(“使用”指类库引用或者修改后的代码) GPL 协议的产品,则该软件产品必须也采用GPL协议,既必须也是开源和免费。这个协议就不太适合商用软件,或者准备使用GPL开源组件的商用项目。基于这个协议的项目,极大的提高了开源软件的数量。上面那个微博的案例,如果作者使用了GPL协议,而使用方所写代码的软件包再发布时没有公开源代码就是违反了协议(多谢Sunny2038纠正)。目前用的多的是GPLV1,GPLV2。这两个什么区别看后面那张树形图。采用这个协议的开源软件有:Linux、 MySQL 。
  • LGPL,最初是Library GPL的缩写,后来改称作Lesser GPL。由于GPL太严格,限制了很多商用软件使用GPL组件才推出了这个LGPL。LGPL允许商业软件通过引用类库的方式使用LGPL组件(不直接使用源代码),这样可以不需要开源商业软件的代码。但是如果要修改原始组件的代码,则涉及修改部分的代码和基于原来代码衍生的代码都必须采用LGPL协议。LGPL不适合以LGPL协议为基础的代码进行二次开发的商业软件,但是商用软件可以采用编译后的类库引用就不需要公开源代码了。采用这个协议的开源软件有: JBoss、 FCKeditor 、 Hibernate。之前extjs就因为从LGPL转换到GPL带来了不少的震动。详情点击
  • BSD,全称 Berkeley Software Distribution。这个协议相对上面两个协议宽松很多,允许使用者修改和重新发布代码,也允许使用或在BSD代码基础上开发商业软件发布和销售,因此是适用于商业软件的。使用者别太高兴,使用时还必须做到满足三个条件:1)如果再发布的产品中包含源代码,则在源代码中必须带有原来代码中的BSD协议。
    2)如果再发布的只是二进制类库/软件,则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
    3)不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。适用BSD协议的开源软件有: nginx、CruiseControl、Redis。
  • apache Licence vesion 2.0,这个协议除了为用户提供版权许可之外,还有专利许可。与BSD协议权限类似, 允许代码修改,再发布,适用商业软件。但是也需要满足以下条件:1)需要给代码的用户一份Apache Licence。
    2)如果你修改了代码,需要再被修改的文件中说明。
    3)在延伸的代码中(修改和有源代码衍生的代码中)需要带有原来代码中的协议,商标,专利声明和其他原来作者规定需要包含的说明。
    4)如果再发布的产品中包含一个Notice文件,则在Notice文件中需要带有Apache Licence。你可以在Notice中增加自己的许可,但不可以表现为对Apache Licence构成更改。

    除了这些条件它还有这些好处:

    1)永久权利 一旦被授权,永久拥有。
    2)全球范围的权利 在一个国家获得授权,适用于所有国家。假如你在美国,许可是从印度授权的,也没有问题。
    3)授权免费 无版税, 前期、后期均无任何费用。
    4)授权无排他性 任何人都可以获得授权
    5)授权不可撤消 一旦获得授权,没有任何人可以取消。比如,你基于该产品代码开发了衍生产品,你不用担心会在某一天被禁止使用该代码

    使用apache Licence vesion 2.0协议的开源软件有:Hadoop 、apache httpserver、Spring Framework、MongoDB 。

  • MIT,源自麻省理工学院(Massachusetts Institute of Technology, MIT),又称X11协议。MIT与BSD类似,但是比BSD协议更加宽松,是目前最少限制的协议。这个协议唯一的条件就是在修改后的代码或者发行包包含原作者的许可信息。适用商业软件。使用MIT的软件项目有:jquery、Node.js。

列出了常用协议,还有一些比较常用的大家就谷歌了,比如: Mozilla Public License、Creative Commons、Eclipse Public License 1.0等。

有一篇博客的树形图很好阐述了当前主流许可协议的区别。
src1
另附一张目前github上项目采用的许可协议比例图:
src2
下一篇介绍一下如何在项目网站上添加开源许可协议。

参考:
http://www.aqee.net/a-short-guide-to-open-source-and-similar-licenses/
http://www.iteye.com/news/27616

原创文章,转载请注明: 转载自LANCEYAN.COM

本文链接地址: 实战做项目如何选择开源许可协议(一)-了解协议

说起敏捷开发,并不是因为敏捷而敏捷。这几年的敏捷开发已经被很多敏捷咨询服务商神话了,这个东西并不是神器,实施了就可以解决所有软件公司的问题,而是要结合自己公司的特点和问题摸索出适合自己的一套模式。

大家都知道,创业公司刚开始需要研发出一款产品并且能够使公司赚钱的产品,不过大部分创业公司没有那么容易一下就能做出来,很多公司还没有成功的产品资金链就断掉了,公司也死掉了。我们公司是这样一个状况,有一条产品线可以维持公司开支并仅仅刚够盈余,要扩大高速发展还不够,一直维持就没有创业的意义。另一条线是做技术创新为未来能够开发一款人气爆棚的产品摸索着,但是又不能饿着肚子去开发。我们是如何结合自身的特点实施敏捷开发的呢?一个难题,很大的难题!

我们技术团队人员是这样的配置:1名技术总监、2名资深开发工程师、1名高级开发工程师、2名潜力开发工程师、1名前端开发、1名测试。技术总监需要处理很多团队管理、客户管理的工作,能够参与项目的时间最多每天二分之一。2名资深开发需要负责给其他工程师做导师,参与新项目开发时间大概有80%。高级工程师要预留项目学习时间,参与项目的时间大概有90%。潜力开发工程师需要有一些时间学习技术和项目,但是基本可以做到70%的时间投入项目。前端开发和测试哪里有需要就在哪里革命,属于机动部队。

现在总共有六个老项目在维护,两个新项目需要开发。六个项目的维护总共需要每周4人天时间(人天指需要花1个人4天的时间完成一个事情)。其中一个新项目“项目1”大概估计120人天的开发时间,需要1个月之内开发完成。“项目2”大概估计要40人天的开发时间,需要2周开发完成。而现在的人力按照能够投入的时间算一下,总共资源为 (1 * 1/2 + 2 * 8/10+1 * 9/10+2 * 7/10) 30天 = 132 人天,6个老项目每周需要4人天,一个月4周,需要 4 * 4 = 16人天。项目能够投入的资源有 132 – 16 = 116人天,而总共需要120 + 40 = 160天,足足少了44人天,这看起来是一个不可完成的任务。

不过到最后,我们还是使用敏捷开发完成了这两个项目,也没有影响老项目的维护。我们是怎么操作的?最开始我们两个开发,这个时候只要两个人就能够很好的合作把产品开发出来,不需要什么模式。随着人员的扩充,团队间如何协作按时按质按量完成任务就需要好好思考下了。

尝试一,传统软件开发模式。整个过程为 需求分析、系统设计、任务分解计划安排、开发设计、编码、测试、交付、验收、维护。这个模式也是大家最常使用的模式,不过套用在我们公司时我们是这么操作的。

传统开发过程
传统开发过程

由于公司创业,老板有一个想法,但并不能很好的描述需求,所以需求分析的任务落在技术总监身上。系统设计和任务分解刚开始是技术总监完成,后面资深开发工程师可以承担一部分。开发设计可以让各个开发工程师完成,资深工程师进行把关,再到测试人员测试,最后再交付用户验收、技术维护。看起来很好的模式,开发了几个产品最终有的延时有的产品离用户的期望差距甚远,参与项目团队的人信心受挫。

为什么会失败呢?后来思考了这些问题:

1、技术总监不是产品经理,不能够承担产品设计的责任。老板是信任技术总监能做好产品,就交给他做。但这里搞混了一个概念,产品经理和项目经理,技术总监应该起到项目经理和架构师的作用。项目经理管控项目进度和计划、架构师把握整体技术问题。而技术总监接到这个任务又不能不做好,责任所在。说到底,就是机制没有把产品设计和项目经理区分开,不等于技术实现者就是产品设计者。更多的应该让老板或者其他业务人员承担产品设计的工作。

2、需求不稳定,变化后改动代价大。由于创业,需求为了适应市场会经常调整,但是一但调整,很多开发计划就会受到相应的调整。如果部分功能已经正在开发,调整需求后很多工作要重新开始,严重影响了技术同事积极性。业务不调整需求是不可能的,他们是为了满足用户的要求,用户满意了才能给企业带来价值。不过如果调整,代价太大,很多代码要重写,大家就会责怪技术总监或者项目负责人没有把握好需求。

3、团队经常加班,但战斗力不强。 核心团队疲于应对需求、技术开发、老系统维护,没时间指导新同事技术学习,而新同事技能暂时还没有发挥出来干活效率低,任务经常延期,没有成就感。核心团队事情很多,没有时间整理项目文档,新员工没有文档上手慢。大家每天很多事情,需要加班才能完成,比较疲惫。每个人除了工作还有很多事情需要做,比如回家看看电视、陪陪家人、看看书学习一下等。如果让一个员工一天二十四小时都是工作,他能同意,他家人也不一定同意。让大家愉悦的开发,比疲惫的上班效率要高很多。

4、交付软件质量差,离用户期望差距大。创业时大家的想法都是好的,大干一番,做一个所有人都爱使用的产品。现实是残酷的,大家辛辛苦苦做出来的东西,老板不满意、用户不埋单,付出的努力没有人认可。交付的软件没时间自测试,或者自测试不充分,交给测试又是一大堆问题。有些公司还没有测试,直接出去给用户,相当危险。这样交出去的公司不仅仅影响了用户的使用,还影响了整个公司的口碑。

不是说传统软件开发模式不好,只是不太适合我们这种创业公司。开始尝试其他模式,如果没有一个很好的体制就不能把大家的最大生产力发挥出来。

尝试二,敏捷开发模式。敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。敏捷方法强调以人为本,专注于交付对客户有价值的软件。在高度协作的开环境中,使用迭代式的方式进行增量开发,经常使用反馈进行思考、反省和总结,不停的进行自我调整和完善。

敏捷开发的主旨

一:个体及交互比流程与工具更具价值
二:可用的软件比冗长的文档更有价值
三:与客户的协作比合同谈判更有价值
四:对变化的响应比遵循计划更有价值

而我们之前的问题,交付软件客户不满意、延期、需求更改代价大貌似都可以解决。这么好的模式赶紧要试试,先看一张敏捷开发的流程图。

创业公司敏捷开发敏捷流程化
创业公司敏捷开发敏捷流程化

敏捷开发简单流程

1、产品负责人将整个产品设计成产品backlog。产品backlog就是一个个需求列表。(backlog可以理解为需求或者要做的事情)
2、召开产品backlog计划会议,预估每个backlog的时间,确定哪些backlog是需要在第一个sprint中完成的,即sprint的backlog。(sprint可以理解为一个团队一起开发的一个任务集合)
3、把sprint的backlog写在纸条上贴在任务墙,让大家认领分配。(任务墙就是把 未完成、正在做、已完成 的工作状态贴到一个墙上,这样大家都可以看得到任务的状态 )
4、举行每日站立会议,让大家在每日会议上总结昨天做的事情、遇到什么困难,今天开展什么任务。(每日站立会议,是在每天早上定时和大家在任务墙前站立讨论,时间控制在15分钟内)
5、绘制燃尽图,保证任务的概况能够清晰看到。(燃尽图把当前的任务总数和日期一起绘制,每天记录一下,可以看到每天还剩多少个任务,直到任务数为0 ,这个sprint就完成了)
6、sprint评审会议是在sprint完成时举行,要向客户演示自己完成的软件产品 。
7、最后是sprint总结会议,以轮流发言方式进行,每个人都要发言,总结上一次sprint中遇到的问题、改进和大家分享讨论。

我们怎么结合敏捷开发解决现有项目的问题,要记得任何措施都是为了保证按时按质按量把软件交付给用户,不要为了敏捷而教条实施敏捷,公司不能产生商业价值,任何先进的理念或者技术都是无意义的。我们做了这些措施:

1、推广敏捷开发理念。不管是大公司还是小公司强制推行一项制度效果一般都不怎么好。要能推行下去的任何东西一定要大家接受的,才能被认可。

  • 首先培养测试小妹学习敏捷开发,后续让她承担部分产品责任人和敏捷指导者的角色,原因有:
    a、测试要验收功能,必须理解业务需求。
    b、测试也是QA质量体系的一块,学习好了对于软件质量有个更深的认识。
    c、团队大部分是男生,女生推广更有亲和力一些。
  • 召集所有技术团队开会准备推广。开始和测试小妹好好讨论下,怎么给大家说更有效,更容易接受。她要讲解一定要自己非常清楚敏捷开发,并且准备充分知识点。开会时先指出我们现在问题,让大家看看有什么想法解决问题吗?现在我们做的产品,客户不认可、老板不满意、自己很累没有成就感,有什么办法解决。在大家讨论后,抛出敏捷开发的优势,一般情况下大家都会认可的。大家可能会问到如何执行、落地,可以尝试找一个项目试点,如果实施成功就可以让大家全面推广,不成功也只影响了部分项目。

2、搭建敏捷开发环境。大家要实施敏捷开发,需要比较好的基础条件保证敏捷开发顺利进行。主要几个关键的软件:nexus 搭建仓库依赖中心、maven 管理工程的依赖、jenkins 持续集成和自动编译发布、svn 集中代码管理、jira 记录需求和状态。具体参考《敏捷开发环境搭建》

3、敏捷项目实施。整个公司建立以业务目标为导向的氛围。就以“项目1”来说,目的是完成这个项目,需要进行这几步:

  • 先根据各自的能力和意向聚集一批完成这个目标的勇士,不管技术和非技术。如果聚集的人不够,技术总监可以根据总体项目的投入机动调整资源以支持,不过条件允许的话还是根据大家意愿来聚集。最终“项目1”召集了一个技术总监、一个资深开发、两个潜力开发、一个前端、一个测试,除去大家做其他事情的时间,总共可以算作4个人。
  • 充分调动客户(老板和业务同事)参与进项目,他们的参与直接决定了项目成功与否。结合之前的经验,如果他们参与不够,最终做出来的东西就不是他们要的,或者离他们要的差距很大。他们刚开始加入的时候,很迷茫有时会表现的比较抗拒,这个时候一定要耐心坚持让大家把第一个sprint开发成功,使大家尝到甜头。让他们全程参与项目也是表示了我们拥抱变化,如果有需求变化,就添加任务到任务墙,大家可以对所有任务的时间有个全面了解,如果超过sprint结束时间就需要业务决策哪些功能不在这个sprint周期加入。
  • 技术总监安排和客户沟通,客户这里指老板和业务。测试小妹负责和客户沟通记录,技术总监辅助。多次沟通后,尝试让测试把需求原型用最简单的工具绘制出来,技术总监审核通过后和客户沟通确认,反复迭代,直到整个需求大家没有异议。很多公司这种需求是有一个专门产品负责人来执行,但按照我们目前的人力是没办法做到的。这里没有让技术总监做主要是为了避免之前出现的问题,过度技术设计产品。
  • 产品设计出来后,召集项目成员分解任务,确定每个任务的时间,可以使用敏捷扑克牌来估计。任务分解尽量控制在1-2天的粒度,这样大家1-2天就可以做出一个能测试的原型,尽早可以集成测试发现问题。一个sprint的任务集合尽量控制在1-2周,不能太长,也不能太短。太长会出现疲劳,太短的sprint会让大家觉得工作太多,做完一个又一个。“项目1”估算结果为120人天,总共投入4个人,需要30天4周时间,我们切成了4个sprint,差不多1个月时间完成,满足业务的时间要求。
  • 分阶段实施sprint,绘制任务墙,划分未开始、已计划、进行中、完成、燃尽图。把要做的sprint任务上墙,贴到未开始的地方。
创业公司敏捷开发任务墙
创业公司敏捷开发任务墙
  • 每日站立会议大家认领任务。包括业务任务、开发设计、开发编码、前端设计开发、测试等都是一个个任务,统一管理起来。强调的是一个团体,如果有同事请假,其他同事可以顶上完成任务。站立会议总结昨天的任务是否有问题,对于当前的任务有什么建议,尽量控制在15分钟内,有效会议。这里不会像以前业务或者项目经理追着大家屁股要结果,而是团队驱动,每天大家做的事情都反映在墙上,谁出现了什么状况,大家都会帮他想办法,保证整个项目能够成功。每一个任务完成,由项目执行者把任务从进行中贴到完成区域。再从未分配区域认领新任务贴到进行中的区域。
  • 软件开发过程。认领任务后,怎么保证大家开发有质量的代码?团队有资深点的工程师,不需要太多指导,直接可以参与项目的开发。而学习型工程师,需要指导帮助才能一步步做用例、系统分析。技术总监不建议认领太多开发任务,他负责开发团队的概要设计审核,没有审核通过的设计不能开发,并指导大家分析和设计系统。大家都知道,系统思路有了,剩下就是技术实现的过程,只要技能掌握熟练实现基本难度不大。大家可能会问,敏捷开发不是强调软件开发的产品是软件,而不是文档吗?我们这里也不是像传统开发软件一样为了文档而文档,只是让大家把自己的设计思路写下来,只有经过自己仔细设计后才能把思路清晰的写下来。大家写的时候也不需要长篇大论,这样的文档是不欢迎的,受欢迎的文档只需写出用例分析,表设计,复杂的逻辑需要画出流程序列图。
  • 结对编程。之前这个编程模式被无数人调侃过,其实也不可能让每一个项目全程都是两个人结对编程。这个不现实也浪费资源。我们的结对是在大家开发一个难点模块时,会给结对的人增加一项任务去配合其他开发一起完成这个任务。其实我们在开发时,很多时候都会结对,比如指导新同事、讨论设计模块,而之前这些都没有算在我们的开发工作量里。
创业公司敏捷开发结对编程
创业公司敏捷开发结对编程
  • 项目演示和总结会议。在项目结束后,让所有参与项目的成员都参加,一起演示给客户展示,并解答客户的问题,充分让大家感受到收获的果实。总结会议主要对于这个sprint中大家遇到的问题和经验分享,并为下一个sprint做准备。

经过敏捷实施后,我们的生产力提高了很多,员工的积极性提高了,业务的参与使整体需求把控也很好,大家沟通多了,30天的任务提前了5天完成。我们多出来的时间,让大家每周有一天或者半天研究自己感兴趣的领域,但是这些研究最终必须体现出成果。比如后台开发想研究一个新技术,最后做完需要写个ppt给大家分享下。既能让大家做自己想做的事情,也给大家创造了一个互相学习的氛围。

ps:所有的模式都不应该是教条的模式,先进的模式并不是好的模式,适合自己的才是最好的。套用一句俗话:不管黑猫白猫抓得住耗子的才是好猫。

另曝光一下项目1参与成员:

项目1敏捷团队
项目1敏捷团队

原创文章,转载请注明: 转载自LANCEYAN.COM

本文链接地址: 创业公司如何实施敏捷开发