当辛辛苦苦开发好一个程序、一套系统，如果想要期望这个软件能够养家活口、甚至是荣华富贵，就必须要思考一个问题：如何向用户收钱？

软件可以收钱的模式，大致可分为几种类型：

• 依功能计价
• 依数据容量计价
• 依使用人数计价
• 依使用时间计价
• 依内容与服务计价

依功能计价

这是最传统的收费模式，许多的大型软件公司早期都是用这样的方式来获利、起家的，像是 Microsoft、Oracle、Adobe。过往都是采用卖断的方式，只能向用户收取一次性的费用。在现今的移动平台也还是有多的开发者采用这种模式，用户透过系统厂商提供的平台来付费下载程序。或是程序容许免费下载但内含购买选项，锁上一部份的功能，在你需要时向你收钱。

这种模式其实对于开发者来说是比较没有经济效益的，就像是 Apple 的 iPhone 一旦目标客户都卖过一轮后，势必就得面临营收数字下滑的情况一样。但是和硬体产品不同的是，硬体坏了可视情况收取维修费，软件还得不断地更新程序来修正错误但几乎收不到钱。在收入锐减的情况下还要持续不断地投入成本，很容易就陷入资金上的危机。所以有的软件公司为了持续地获利，只好使用各种名目来改版，让用户再掏一次钱出来。尽管新增加的功能不见得是用户需要的，用户在忧心不相容及终止支援的恐惧心态之下，还是会迫于无奈地买单。

随着网络环境的成熟，后续出现新的盈利方式就是租赁。一些大型的软件公司也都开始改采这种模式，以月、年为周期计价来向用户收费。有的软件更进一步地提供免费的安装并限定时间试用，试用满意后再开始付钱，甚至直接在云上提供功能省去了软件安装的步骤。只不过这对使用频率不高的用户来说并不划算，一个月使用一次和天天都使用付的钱是一样的，相对地就可能会有客群流失的疑虑，尤其是当所开发的软件有竞争对手、具高度替代性的时候。

对依功能计价的这一种收费模式来说，云所带来的好处是不用再想方设法地限制用户运行程序的环境，像是设计硬体锁之类的。这类的方法多少有带来一点吓阻非法使用的效果，但是道高一尺、魔高一丈，还是有被破解的版本会在市面上流传。当然这种版本是没有执行限制的，非法的不用特殊的工具开心地使用，合法的要设定个半天搞不好还因为相容性问题不能运行，结果反而产生了是在惩罚合法的付费用户的现象。上了云之后，则是一个都跑不掉，更不用担心有破解版导致获利上的损失，只不过有山寨版出现来抢生意又是另外一件事了！

在移动平台上依功能计价有一点是需要注意的，一般来说这个模式原则上都是付费后只能安装在一个装置上，或是约定最多只能同时装在多少个装置上，像是 Apple 和微软都有提供类似的限制。但是 Google Play 目前只认帐户，所以只要在 Android 上切换到有购买的帐户就可以下载已付费的 App，而且理论上是无限多台。

依数据容量计价

就是程序本身会限制用户可以产生或是程序能够处理的数据量，当数据量达到上限就必须要再付费来取得新的数据空间。这个模式本身并不是什么新鲜的手法，只是上了云之后更有强制性，因为数据都在服务端，用户要增加也只能乖乖地付钱。最典型的例子大概就属云空间了，因为这种程序最核心的工作就是用来管理数据空间，像是：OneDrive、iCloud、Google Drive、DropBox。

只是单纯地以数据容量来做为盈收的依据，其实还是会有一些在收益上的盲点。如果用户的数据特性是流动的，就可以在既有的空间中不断地替换数据来使用程序。举个例子来说，假设有一个线上的项目管理系统，一开始限制只能新增五个项目，超过要收费。但当一个用户同时会进行的项目最多只有四个，项目结束了数据只要封存就好，所以对这种用户来说，五个项目是够用的，只要项目结束后把数据清掉再开始新的循环就行了。对付钱的来说是一个好消息，但对收钱的来说可能就不是了，除非程序还有另外的收钱选项。

所以这类型的线上服务商，早期叫 ASP (Application Service Provider) 之后有另一种说法叫 SaaS，除了会限制数据的数量，有时还会和功能一并组合成购买的选项。就像前面提到过的，这是程序云化后所产生的另一个获利优势，由于程序和数据都掌握在提供服务的一端，所以在收费策略上具有更多的筹码。

依使用人数计价

跟依数据容量计价的模式很像，只是把数据换成了可以使用程序的人数。

这是微软惯用的收费策略，在还没深入了解微软产品的授权结构之前，会以为要建置一个以微软产品为基础的 Client-Server 环境只要付钱替二端的硬体各买一套操作系统就行了，了解之后才发现事情并没有这么简单。在服务器那端除了要操作系统的使用授权之外，还有所谓的“客户端访问许可证 CAL(Client Access Licenses)”。是的，连线存取也是要授权的，否则在法律上是无权与 Server 连线。由于微软的产品种类繁多，CAL 的组合也相对地复杂，如果真的要认真的收钱，微软真的搞得清楚他的客户有没有付足额的费用？

当然，也不是只有微软才这么做，不过像微软这种计价模式大概也只有这种等级的软件公司才承担得起对应的维运成本。一般的方式有可能用帐户的名称来认定，也有可能用连线的设备来认定。像是允许用户可以设定多少个登入的帐户，或是连线的设备要先经过系统的登记，超过就要再收费。更简单一点的就不管开多少帐户、使用多少连线的设备，只限定同时在线的连线数量，也就 Concurrent 数，多了服务端就拒绝连线。

在盈收上需要考量的问题和依数据容量计价是类似的，因为设备或帐户又不见得直接对应到个人，所以有可能只买了一个授权然后全公司用，全公司只要协调好使用的时间不要重叠就行了。在认定上，公司的人员本来就是有流动的可能，若要严格地追究起来很容易和用户之间形成罗生门。结果就是如果要以这种模式来计价，在数字的估算上就需要保守一点。

依使用时间计价

就如同我们打电话、照通话时间计费一样，是依据用户使用程序的时间长短来决定费用多寡。和先前提到的租赁不同之处，就像电信收费模式，之前的是套餐，现在这个算是充值卡。直接向用户依照使用时间计价的模式并不是业界主流的作法，但目前有一种很热门的方式是依使用时间向第三方收钱，那就是移动平台上 App 内含的广告。广告收益和时用使用量有什么关系？在 App 内放置的广告通常靠的是曝光率或点击率来累积收益的数字，所以当用户用得愈久，可以显示广告的次数就愈多，相对地曝光率或点击率就会提高，也等于是变相地依使用时间来计价。

这种模式透过向第三方收钱可以减少争议，使用程序的人觉得没付出什么代价就可以使用程序，付钱的人觉得曝光的目的达到了，开发程序的人有收到在金钱上的回馈，皆大欢喜。但如果是要直接向用户依时间计价，却又是另外一回事了！首先是要如何记录用户使用的时间，并且向用户提出收费的明细？不管是要事先收钱还是事后付费，都会需要有一定程度的后台系统来维持运作。

此外，使用时间的认定也很容易有争议，假设今天程序使用到一半，小孩哭闹要喂奶、换尿布，程序没关的情况下算不算是使用的时间？程序处理数据的效率不够好要照时间收钱是不是合理？用户心里的 OS 会不会是：程序处理的比较慢也要收钱，谁知道是不是故意写得比较慢？我就是没钱买比较好的硬体，结果反而因为程序处理比较久要多付钱？

也许在评估过投入后台加上处理用户争议的成本，还不如直接卖断比较省事。同时，开发的应用程序使用的频率很低，也许设定一次之后就不会再使用，这样的程序使用这个计价模式就不是一个很好的选项，应该要考虑其他不同的收费模式。

依内容与服务计价

这是目前应用最广泛的盈利模式，因为受到早期网络免费风气的影响，再加上开发工具愈来愈先进，使得制作软件的技术门槛大幅降低，以致竞争激烈，所以单纯地想靠程序本身来获利并不是一件容易的事。用这种模式计价时，程序所能带来的盈收助益都常都不是重点，又或是开发技术的门槛不高，只能以内容或服务取胜。

在这个模式中，能够用来计价的标的可以有很多种面向。以内容为例，在移动平台上经济规模最大的应该就属游戏类型程序，游戏本身也许要付钱也许不要，但后续的盈收重点是在游戏的关卡上，而关卡就是游戏的内容。虽然开发关卡也是需要成本，但这样的模式最少把软件的价钱分散在不同的内容上，降低购买的基准，也减少用户的抗拒心理。

不过要谈内容比较接近的应该是媒体或出版业所开发的系统，毕竟产生内容才是他们的本业、他们的强项。内容反而是他们的重点，程序是附属的。不光是内容，很多的行业由于受到网络所带来的冲击，必须透过把实体的服务带入网络来进行转型，程序上提供的功能则是把业务延伸到网络世界的垫脚石。

这同时也会让这类型的程序陷入一个盲点是：业者往往只注重内容或服务的销售，而忽略了对用户在使用程序的友善度，或是所呈现的内容过于单一、局限。于是有另外一种新的服务的模式是用程序来建立平台，开发系统的人透过平台上的销售行为来抽取佣金，内容或服务的提供者只需专注在自己擅长的领域，达成一种专业分工合作的形式。

所谓的平台目前最热门的就属 Google 和 Apple 所提供的各式商店，程序、新闻、杂志、图书、音乐、影片，几乎是想把所有数位的商品都囊括在内。而卖实体商品常见的就是网购、拍卖平台，卖服务的则有订机票、订饭店、找住宿、打滴等形形色色的软件。就连通讯软件都不是靠程序或通讯服务来获利，而是透过平台贩卖贴图，甚至是贩卖周边的商品。

看似商机无限，只不过不论是要单纯地卖内容、服务，还是要做平台抽成，都需要有足够的后台来支撑，这包含了人力、资金。可以想见期初就要投入大量的成本来等待获利，并不是独立的开发者想选就能选的。所以，这个计价的模式最大的限制在于还得要看开发者有没有本钱做这样的生意。