2009年10月20日 星期二

Getting Started with Issue Tracking

Getting Started with Issue Tracking | ActiveState Blog

Got issues to manage? Most software teams do. They’re to-do lists
that get angry when they don’t get done, and they can make teamwork
flow through the day or end up in an unmanaged state. If your email
inbox is the only tool you’re using to track issues, you’re more likely
treading water than swimming. And it’s just that feeling that brings
many development teams to an issue tracking system to get a handle on
bugs and feature requests. With that in mind, we have a 2-part post of
guidelines for getting started with issue tracking.


Too Many Fields?

When you dig into your issue tracking tool of choice, you’ll likely see
a lot of fields. Just the thought of filling them all out for every
issue you log might make you think email isn’t so bad. But as the
Hitchhiker’s Guide says, “Don’t panic!” When getting started, look for
the fields that map comfortably to the way you and your team currently
talk about issue handling. Start with those, but keep the other fields
in mind as you work. As you get used to seeing them, you’ll likely find
good ways to incorporate them into the workflow.


Defining Terms

Without setting some definitions, you’d be leaving your team to bring
their own definitions to a system meant to get people communicating and
working together smoothly. There are 2 specific places where a strong
definition set from the start will solve a lot of uncertainty and
confusion, and maybe even prevent some arguments as you go forward.


Bug vs. Feature Requests

While this might sound like an easy and obvious distinction, it often
gets lost in moments of frustration, which are exactly the moments that
both bug reports and feature requests are born from. Making the
distinction clear in your charter for a new issue tracking tool will
help everyone understand these categories clearly.


  • A bug is something that was asked for but doesn’t work in the way
    it’s supposed to. It can only be used to describe existing
    functionality, or something that the software does but does not do
    correctly. If it’s broken, it’s a bug.
  • A feature request is a request for new functionality or a change to the way something in the software works.

Severity or Priority

Your issue tracking tool will use one of these terms to express ‘how
important is this issue?’. Some systems use both, and while that can be
useful, in most cases you will only need one or the other. When
reporting an issue affecting them, people are likely to see it as more
important than it really is in the grand scheme, because that issue is
topping them from getting things done. Some objective criteria can help
set some perspective.


I tend to favor the Priority label, and depending on whether an
issue is for a bug or a feature request, we’ll need different criteria
to evaluate it.


Bug Priority


  • Urgent or Critical: The problem prevents the
    software from operating or key requirements from being met. People
    cannot do their work with an urgent or critical bug.
  • High: The problem prevents key requirements from being met, but there is a workaround that will suffice in the short term.
  • Medium/Normal: The problem does not prevent key requirements from being met and can be worked around or lived with in the short term.
  • Low: The problem is an annoyance but is not preventing any requirement from being met.

Feature Request Priority


  • Urgent or Critical: The feature is needed as soon
    as possible. Not delivering it will severely impact the relationship
    with clients or customers. Other work needs to stop to make this
    feature happen.
  • High: The feature is strongly desirable and should be given priority, but does not disrupt any current work.
  • Medium/Normal: the feature is nice to have and can be assigned into an upcoming milestone
  • Low: The feature is nice to have and can be added to milestones with some time available.

Alternatively, you can use Severity and Priority to indicate
relative importance for users and developers respectively. For example,
end users could be allowed to set the Severity of a bug, but not the
Priority. Developers could then set the Priority based on the Severity
assigned by the user, while taking into account the development road
map, time constraints, and technical considerations.


None of these definitions are air-tight, and you’ll likely need to
reassign or discuss the priority of specific issues from time to time.
The important thing is that the whole team starts from the same page,
and over time you can refine the definitions to fit how you see the
world.


In the next post, we’ll look at considerations for getting started
with issue tracking for the team and client culture that your team
works in.

Getting Started With Issue Tracking - part 2 | ActiveState Blog

Getting started with issue tracking is much more than deciding on a
software application or hosted service. It requires taking stock of
team and client culture to arrive at a smooth and productive workflow.
In the first part of this 2-part post, we talked about starting with
the basics of what your choice of issue tracking system offers and
growing from there, as well as defining terms for describing issues
consistently across the whole team. In this post, we’ll look at more
high-level aspects of implementing issue tracking in your team’s
practices.


Visibility

The subject of visibility in tracking issues is about how much you let your clients or customers see in the issue database.


If you’re running an open-source or public project, the decision is
an easy one. Of course you need people to both see the issues that have
been reported and to contribute their own findings and requests to the
queue.


On a private project, the decision is more complex and comes down to
knowing the relationship you have with the people you’re developing
for. Let’s tackle the question in 2 stages: stage one is letting
clients and customers see issues and their status; stage two is letting
them add and modify issue tickets.


To decide if clients should see issue tickets and their status, ask yourself these questions:


Do your clients or customers ask for a lot of detail in how work is progressing, or only ask for periodic updates?
If
clients like detail, chances are they’re just looking for reassurance,
and being able to see that a ticket is logged for the fixes they care
most about will go a long way towards giving them some peace of mind.


Do you receive input on bugs or feature requests from multiple people?

If you get feedback from multiple people, then you’re likely seeing
duplicate issues. Enabling reporters to first search existing tickets
before firing off an email can help reduce duplicate issues, but it
won’t eliminate them altogether.


Assuming you’ve decided to let clients see tickets, now let’s figure out if they should touch them as well:


Do the bug reports and requests you get provide the right level
of detail and clarity, or are they more like emails with a subject line
saying “Help, it’s broken!”?

If clients and customers are giving
you reports that pivot nicely into starting a fix or a productive
conversation on how to proceed, then letting them file tickets and
answer questions in the system can be a huge time-saver. It has the
added benefit of allowing the reporting person to stay in touch with
how the issue is being handled, and maybe even give extra guidance or
details along the way.


Workflow
One of the most common causes of
confusion in issue tracking doesn’t come when opening tickets but
rather when closing them out. Make it clear to the team who comes next
in the chain of handling issues, and what the criteria are for closing
them. Some systems provide controls that only allow certain roles to
close tickets, while others can mark them as resolved or ready for
testing. Even in those that don’t, it’s important that the whole team
plays by the same rules, or you’ll end up re-opening tickets and
re-visiting bugs more often than you’d like.


As the team gets used to using the new system, you may need to
gently divert them from the old channels that were used beforehand. If
someone with the ability to create a ticket sends you an email about a
bug, you’re going to have to ask them to add a ticket for it, or you’ll
be back to dealing with email, as well as the new ticketing system.


Evolution
After you get rolling with issue
tracking, schedule some time 2 weeks in and again 2 months in for a
checkpoint meeting with the team about how the system is working for
them. Making sure everyone understands that how you use the system can
change with feedback will make the prospect of using it easier to get
into.


In fact, you can create an issue category for process improvement,
and invite everyone involved to log suggestions or points of friction
in using the tracking system itself. That’s right, we can use the
process and tools to fix what doesn’t work with the process and tools.


Conclusion

If there’s any part of good software development practices that defies
a one-size-fits-all approach, it’s issue tracking. The right system for
you will accommodate the idiosyncrasies of how your team works, while
gently suggesting good practices to follow from its built-in business
logic.

2009年10月18日 星期日

NAT Traversal

COdE fr3@K » Blog Archive » NAT Traversal, part 0
NAT Traversal, part 0
Posted on September 20th, 2006 at 1:43 by fr3@K

根據 wikipedia 的定義, 一個 peer-to-peer (p2p) computer network 是一個主要依賴該網路上參與者 (相對於依賴服務器) 的運算能力與帶寬的網路.


P2p 網路的達成主要有兩個困難點:

1. Signal, 一個 peer 如何找到另一個 peer 並與其溝通
2. P2p 資料傳輸

達成第一點的方法, 也就是使用的 signalling protocol 有很多, 現階段的規範也比較成熟完善. 例如 SIP 與 IMS. 相對來說, p2p 的資料傳輸是更走在技術的前沿.

無論原因為何, 大多數的裝置 (通常是電腦) 不是直接連上 Internet, 而是透過 NAT 或 NAPT (以下均稱為 NAT) 連上 Internet. 在這種情況下, NAT 的穿透 (NAT traversal) 成為了 p2p 資料傳輸的前提.

這些在 NAT 後面的裝置沒有公網 IP, 如不利用服務器轉送, 傳統上幾乎沒有廣泛通用的方法1 從一台這樣的裝置把資料傳輸資料到另一個這樣的裝置.

技術是一直在往前走的, 現在, IETF 的 behave , midcom 與 mmusic 等 working group 已提出在多數狀況下達到 p2p 資料傳輸的方法 (protocol). 在開始進入這些方法之前, 對 NAT 的相關行為必須要有透徹的了解.

這一系列的 NAT Traversal 將從了解 NAT 的行為開始, 到 STUN 與 TURN, 計畫會在 ICE 以及 ICE 在 SIP 的應用劃下句點.

繼續閱讀 NAT Traversal, part 1 – NAT Behavior.

1. 部份 NAT 支持由 Micro$oft 提出的 UPnP, 在應用程式也支持時也可達成 NAT traversal. UPnP 的功能包山包海, 因此其最大缺點為肥大以及容易產生安全漏洞. [↩]
COdE fr3@K » Blog Archive » NAT Traversal, part 1 – NAT Behavior
NAT Traversal, part 1 – NAT Behavior
Posted on September 21st, 2006 at 1:12 by fr3@K

續自 NAT Traversal, part 0.

NAT (不包含防火牆) 處理 UDP 封包的行為中, 對 p2p 影響最大的兩類為:

1. External Port Mapping
2. Filtering


exteranl-port-mapping.640x550.png

External Port Mapping 指的是當使用內部同一個端口 (L:l) 對外部發封包的時候, NAT 對外面是否使用同一個端口 (N:?):

* 若 NAT 對外使用的都是同一個端口 (n1 == n2 && n2 == n3), 則該 NAT 的 External Port Mapping 行為是 endpoint independent (與外部端點無關).
* 若只有在外部端點 IP 不變只變 port 的情況下, NAT 對外使用的都是同一個端口 (n1 == n2 && n2 != n3) 則該 NAT 的 External Port Mapping 行為是 address dependent (與外部端點地址有關).
* 若對任何不同的外部端點 NAT 對外使用的都不是同端口 (n1 != n2 && n2 != n3 && n1 != n3) 則該 NAT 的 External Port Mapping 行為是 address port dependent (與外部地址與端口都有關).

filtering.640x550.png

Filtering 指的是在不考慮封包掉了的情況下, 當一個位於內部的端口 (L:l) 對外部的一個端口 (X:x1) 發了封包, 外部不同端口 (X:x1, X:x2 and Y:y) 對 NAT 上 map 出來的端口 (N:n) 發封包時的過濾行為:

* 若內部端口都能收到任何外部端口所發的封包, 則 該 NAT 的 Filtering 行為是 endpoint independent.
* 若內部端口能收到外部同一個 IP 的另一個端口 (X:x2) 所發的封包, 則該 NAT 的 Filtering 行為是 address dependent.
* 若內部端口僅能收到外部同一個 IP 固定端口 (X:x1) 所發的封包, 則該 NAT 的 Filtering 行為是 address port dependent.

在所有 NAT 上, 這兩類行為都同時存在. 但組合起來時, 不是如直覺般產生九種組合 (3 X 3 的矩陣). 細想一下就會知道只能有六種組合:

* External Port Mapping 為 endpoint independent 時, Filtering 可為 endpoint independent, address dependent 或 address port dependent.
* External Port Mapping 為 address dependent 時, Filtering 可為 address dependent 或 address port dependent.
* External Port Mapping 為 address port dependent 時, Filtering 只能是 address port dependent.

繼續閱讀 NAT Traversal, part 2 – STUN.
COdE fr3@K » Blog Archive » NAT Traversal, part 2 – STUN
NAT Traversal, part 2 – STUN
Posted on October 1st, 2006 at 23:46 by fr3@K

續自 NAT Traversal, part 1 – NAT Behavior.

Intro

STUN 是個非常簡單的 protocol. 就只一種功能性的 request - Binding Request1. 可以先簡單想像為 ping, 不同之處在於 server 的 response 會將 client 發出 request 的 source ip:port 放在裡面回應.


當 client 收到 response, 從中得到 server 稍早 `看到’ request 的 source ip:port 可大略分為兩種狀況:

* 與 client 發出 request 封包的 ip:port 一樣, client 可藉由這種狀況發現自己擁有公網 ip.
* 與 client 發出 request 封包的 ip:port 不同, client 可藉由 response 知道發出 request 的私網 ip:port 被 NAT 被 map 成外部的那個端點. 這也正是這個 request 叫做 Binding Request 的原因.

絕大多數的 protocol, server 都會用收到 request 的 ip:port 來發出 response 以回應 client. STUN 特有一個很有趣的 attribute, 叫做 CHANGE-REQUEST. 用來要求 server 回應 client 的時候, 換一個 port (ip 不變) 或是換一個 ip 發送 response.

藉由把 STUN daemon 跑在一個 ip 的兩個 port 以及第二個 ip 上, client 就可以藉此了解它所處內網對外的 NAT 對 p2p 傳輸最具影響力的兩種行為; External Port Mapping 以及 Filtering.

External Port Mapping

Client 先用同一個 port 對 server 的兩個 ip (X:x1 and Y:y) 各發送一個 Binding Request, 如果兩個 response 顯示的 source ip:port 一樣 (N:n1 == N:n3), 則該 NAT 的 External Port Mapping 行為是 endpoint independent. 若不一樣, 就再對 server 在其中一個 ip 的第二個 port (X:x2) 發送一個 Binding Request, 如果這次的 response 回應的 source ip:port 與第一個 response 一樣 (N:n1 == N:n2), 該 NAT 的 External Port Mapping 行為是 address dependent. 否則為 address port dependent.

Filtering

等一段時間之後2, 接著 client 對 server 的一個 port (X:x1) 發送兩個 request, 其中第二個 request 要求 server 以不同 ip (Y:y) 回應. 如果 server 能收到第二個 request 的 response, 那表示該 NAT 的 Filtering 行為是 endpoint independent. 若收不到, 則再發一個 request, 要求 server 以同一個 ip 的另一個 port (X:x2) 回應, 如果這次收到了response, 這個 NAT 的 Filtering 就是 address dependent, 否則為 address port dependent.

External Port Mapping 與 Filtering 都是 endpoint independent 的 NAT 對 p2p 傳輸而言最為有利. 任何端點 (X:x1) 跟你通信之後, 可以直接把你 NAT 外部端點 (N:n1) 告知第三者, 第三者就能直接發送 (Y:y) 訊息給你. 只要 External Port Mapping 是 endpoint independent, 即使 Filtering 是 address port dependent, 也很容易克服, 跟你通訊的端點除了把你的外部端點告知第三者之外, 只要把第三者用來發送訊息的端點 (Y:y) 告訴你. 讓你能向那個端點發送個封包就能把 Filtering 的限制解除.

繼續閱讀 NAT Traversal, part 3 – TURN.

1. 實際上有兩種 request, 只是另一個 request 用途是認證, 與功能性無關. [↩]
2. 等一段時間的目的是讓 client 對外的 binding 超時, 否則第二輪測試完全無意義. 但要如何知道 binding 的超時為多少時間呢? 就留給你做功課吧. [↩]
COdE fr3@K » Blog Archive » NAT Traversal, part 3 – TURN
NAT Traversal, part 3 – TURN
Posted on April 14th, 2007 at 15:53 by fr3@K

續自 NAT Traversal, part 2 – STUN.

像是 MSN messenger 等的傳統 IM (Instant Message) 網路, 其 server 只負責少許的任務, 絕大部分的工作都是一個 client 節點與別的 client 節點之間的事情. 即便如此, 在這種網路之中, 每一個 client 還是從頭到尾都是與 server 溝通, 從來不會直接對另一個 client 收發訊息. Server 除了一開始對 client 認證, 後續除了 relay (轉發) 訊息與 data (例如檔案傳輸) 之外, 幾乎就沒別的任務. 對 service provider 來說, 這種架構可說是非常浪費網路資源. 每一個經過 server relay 的封包, 都代表對 service provider 頻寬與計算能力的損耗.


這種應用之所以會採用如上述對 service provider 的 core network 負擔較大的網路架構, 最主要是因為其 client 大都在 NAT 後面, client 與 client 之間無法有效建立直通的連線 (direct connectivity). 在這種網路架構之下, 由於沒有其他明顯缺點, 常會把 signal 通道與 data 通道 multiplex 在一個 connection 裡面.

若一個 application 把 signal 與 data 分開 (如 SIP + RTP), 就可以利用 TURN (STUN relay, formerly known as Traversal Using Relay NAT), 一種泛用 (generic) 的 relay protocol. 早期的 TURN 與 STUN 類似但稍微複雜的 protocol. 在 新版本的 STUN draft 中, 已經把 TURN 納入為 STUN 的一種 usage (可視為一種 extension). 說明了兩種 protocol 之間的血緣關係. 也是 protocol 作者 在發表早期 TURN draft 時, 表明希望可以大量利用 STUN 的基礎, 發揮到最大的一種表現.

TURN 的特點是 TURN client 必須知道對方 (external peer) 使用的 transport parameter (e.g. ip:port). 才能使 TURN server 開始 relay. 假設一個 client 透過某個 signal router 與 Media Server 交換 transport parameter. TURN client, TURN server 與 Media Server (此例的 external peer). 三者的網路架構與互動流程如下圖:

TURN Architecture/Flow

Click to ZOOM or open in a new window.

首先 TURN client 對 TURN server 以 Allocate Request 做 port allocation 的動作 (1~2). 得到了 TURN server 上 allocate 給 client 的 port 之後就可以開始與 Media Server 的 offer/answer (3~6). Offer/answer 完成後 client 會得到 Media Server 的 transport parameter, 然後再藉由 Set Active Destination Request 通知 TURN server 對方的 transport parameter (7~8). 之後 Media Server 發送到 TURN server 特定端口的封包 (9) 都會被 relay 到 TURN client (10).

TURN server 除了 relay 之外, 與 TURN client (建立 TURN session 的 client) 之間仍會用少數的 request/indication/response 溝通. 但對 external peer (另一邊的端點) 卻是 transparent. 換句話說, 對 external peer 來說, TURN server 上的某個特定端點的表現, 就如同是 TURN client 就跑在這個端點上. 即便如此, 一個在 TURN client, 在 NAT 後面的節點, 無法透過 TURN server 變成一個隨意接受第三方 message 的 server. 在 TURN client 還沒有經由 Send Indication 或 Set Active Destination Request 來把某個 external peer 加入 TURN session (on TURN server) 上的 permission list 之前, 這個 external peer 送到 TURN server 的封包都不會被 relay 回 TURN client (i.e. discard).

如果兩邊都使用 TURN, 則兩邊各自都是不同 TURN session 的 client, 與它們對應的 external peer 則是對方使用的 TURN server. 下圖中兩個 client 各自建立了一個 TURN session 來與對方溝通, 對於 Client A 在 TURN (server) A 建立的 session (Session A) 來說, Client A 是這個 session 的 client, TURN (server) B 是 external peer. 反之亦然:

turn-both.640.png

Click to ZOOM or open in a new windows.

這個例子還有個有趣的地方, 在 TURN A 到 Client A 與 TURN B 到 Client B 這兩段跑的是 TURN, 但在兩個 TURN server 中間跑的卻是原本的 data protocol (non-TURN’ed). TURN A 與 TURN B 都不會知道對方是個 TURN server, 它們只當 external peer 就跑在另一個 TURN server 的特定端口上.

TURN 支援在同一個 session 裡面同時對多個 external peer 溝通. 除了 active destination (preferred external peer) 之外, 與不同的 external peer 往來訊息時, 對方發給 TURN client 的封包會被包在 Data Indication 裡. 而 TURN client 則透過 Send Indication 來 encapsulate 發給非 active destination 的封包. 這兩種 indication 都包含了 REMOTE-ADDRESS 這個 attribute, 用以表示 external peer 的位址 (i.e. ip:port). 對 active destination 收發訊息時則不需要經過 encapsulation.

雖然單純採用 TURN 並沒有辦法降低對 core network 整體頻寬與計算能力的消耗, 但可以藉由把 signal routing 與 data relay 分佈在不同的 core network 節點, 達到分散 network I/O 與 computation 的效果.

預告: NAT Traversal, part 4 – ICE.

2009年10月10日 星期六

蔡子強﹕高錕校長的故事:大學就是包容
周二諾貝爾獎公布當晚,有記者採訪我,聽我說了上述故事後,問我,今天回想,會不會覺得我們這些學生當年錯怪了校長。我想了一想之後,答說:「20年後的今天,我想當年反對校長出任港事顧問的學生,仍然會堅信自己的觀點是對的,所不同的是,我們應從校長身上,學曉處理不同意見應有的態度。」

2009年10月1日 星期四

小企業的生存之道

小企业的生存之道 - 阮一峰的网络日志
这几天,我在读Seth Godin的《创业者圣经:有创意,无资金,如何起家》(The Bootstrapper's Bible,上海译文出版社,2000)。我读的是实体书,不过译言上有网友翻译的中译本。

这本书的第一章就谈了一个很重要的问题:在与大企业的竞争中,小企业怎么活下去?

表面上看,如果市场已经被大企业占领,小企业就根本没可能活下来。

原因有以下五点:

1)经销渠道。大企业的产品无处不在,广告铺天盖地。
2)融资渠道。大企业能够借到大笔资金。
3)名牌效应。消费者信任著名品牌。
4)客户关系。客户往往不信任新公司,更愿意与以前的合作方合作。
5)优秀雇员。大企业能够吸引优秀的人才。

因为上面这些原因,所以就算小企业有非常优秀的产品,也很难与大企业竞争。这就告诉我们,创业的时候,应该避开大企业的优势领域,而选择进行侧面竞争,也就是避其锋芒,攻其不备。

具体来说,是这样的:

1)经销渠道。尽量不要采用传统的经销渠道,更多地考虑与用户面对面地推销。
2)融资渠道。不选择需要大量资金的项目进行创业。
3)名牌效应。你的产品没有人家名气大,那就只好选择比人家便宜了。
4)客户关系。先做一笔小生意,与客户建立关系,或者直接把产品送给客户试,然后再慢慢蚕食大企业的客户。而且每次都以一个客户作为重点,开展销售工作,不分散力量。
5)优秀雇员。并非所有的雇员都追求公司的名气、稳定的工作和高报酬,事实上,很多人都喜欢带有冒险性的工作,喜欢有灵活的工作时间、关心下属的老板、认股权、方便的工作地点、没有官僚主义和复杂人际关系的工作环境,良好的发展机会等等。只要你能提供这些大企业无法提供的东西,你就能从他们手里争夺到优秀人才。

因此,只要你有一个好的产品(或服务),然后采取正确的策略,你就有机会在竞争中生存下来。

更有利的是,互联网时代的到来,使得小企业的生存环境进一步改善。

a. 小企业大多选择服务业创业,服务业的规模效应不显著,互联网加强了这种趋势。
b. 在新技术的帮助下,小企业能达到与大企业一样的高效率。
c. 小企业机构简单,管理灵活,更适合向顾客提供个性化的产品/服务。

所以,总的来看,巨人并不是不可战胜的,大企业的优势其实也不是那么牢不可破。如果说20世纪是大公司和大集团的世纪,那么也许21世纪就是小企业和创业者的世纪。

OpenOffice.org的Cost Down哲學

OSS應用軟體電子報
OpenOffice.org的Cost Down哲學

上一期電子報提到,近年來有許多企業開始控制IT預算上的支出,以節省營運成本,所以紛紛考慮採用自由軟體的方案,筆者最近接到許多企業詢問的案例,莫不先以節省公司IT支出費用的出發點做為考量,做為導入OpenOffice.org的動機,整體來說,出發點是正確的,但是對於整體的考量似乎又不大完整,筆者有以下幾個觀點,讓各位讀者參考一下。


節省支出要看長期,而非一張訂單就決定

許多企業在導入OpenOffice.org的時候,都想看到立即的效益!舉個最常見的狀況來說,很多企業主認為OpenOffice.org是自由軟體,所以軟體授權費用等於「零」,結果都認為這樣可以幫公司省去許多費用,準備大刀闊斧一番,最後往往在執行的過程中就付出許多代價而多浪費了許多時間、人力的成本。

第二個狀況是聽完一場專業的OpenOffice.org導入簡報,結果發現竟然要額外花上一筆顧問咨詢的費用,經過「評估」之後,單純就費用而言,轉換OpenOffice.org的方案與升級Office的費用相去不遠,於是因為無法幫公司省到錢,所以結論是等到「下次」升級Office的時候再做一次評估,可是等到那個時候,重新的再評估一次,又浪費了一次時間,最後乾脆就重買一次License,而這樣的故事會不斷地上演…

沒錯!以上兩種狀況都會讓企業的整體營運費用減少,雖然短期之內就可以看到好的績效(可能是今年的軟體費用減少了,或是執行了有效的升級方案了),但以長期來看實際上是增加許多的成本的,通常筆者會建議企業可以用二年或是三年來檢視一次轉換的績效,尤其目前正是轉換的大好時機,愈早轉換至OpenOffice.org,企業所要付出的軟體成本將會愈低,如下圖所示:



愈早轉換至OO.o,軟體授權的成本將會愈低,而採用OO.o之後,企業人數將不會是軟體成本升高的主因,但若還是採用傳統商用的Office方案,卻會是愈來愈高。


可將轉換OpenOffice.org視為「投資」

初期導入OpenOffice.org所支付的成本可能是顧問導入咨詢的費用、人員初期使用不習慣所造成的時間成本,這些成本就算是轉換成新版的Office都可能會產生,但是若採用自由軟體的OpenOffice.org,就可省去未來的授權費用,另外在第二年之後的成本會趨於平緩,整體的平均成本也會遠低於商用Office的方案,長期而言,為公司能省下的費用是相當可觀的,如果像是零售業、製造業等低毛利的產業,省下來的費用甚至可以當成是賺到的呢。

自由軟體是新的軟體趨勢,所有的企業IT人員都必需了解如何應用自由軟體來為企業達到最大的效益,唯有長期關注、採取實際行動,將其視為投資,才能實際擁有IT的自主權。

提供OpenOffice.org商業服務的網站:http://www.openoffice.com.tw

OpenOffice.com.tw的噗浪連結:http://www.plurk.com/openoffic

電郵營銷小本萬利

電郵營銷小本萬利 - Yahoo! 新聞
電郵營銷小本萬利
(明報)2009年9月9日 星期三 05:05

【明報專訊】一封近乎「零成本」的電郵,憑著一點心思、創意,原來可以變成一盤千萬元的生意。雷克系統有限公司行政總裁郭正光(Francis),9年前研發出一套電郵營銷(eDM)系統,針對收件者的身分、喜好,發送「度身訂做」的宣傳電郵;這技術吸引了東亞銀行 、貿易發展局及Canon等機構及品牌光顧,每年營業額逾千萬元。

雷克去年更跳出香港,於廣州、上海 設分公司,「我希望能變成地區企業,不要做山寨廠」。

Francis於2000年與兩名朋友合資少於10萬元成立雷克,研發人工智能系統,在網站收集及分析使用者的行為數據,然後向收件者作購物推薦,例如在書店網站中你曾瀏覽某一作者的書,系統便會根據你的瀏覽紀錄,自動列出該作者其他書籍作推薦,「分析都幾準㗎!」Francis說。

針對用戶口味發宣傳電郵

一年後他們將產品推出市場惟適逢科技泡沫爆破,結果敗陣而回,「因為人們不相信『.com』,大家亦不敢上網購物」。

Francis曾與多間大公司合作,掙到經驗卻掙不到錢,於是一改策略,針對電郵研發新產品,因為美國 當年正立法針對濫發電郵,「立法並非要打壓,而是要規管,這令電郵營銷服務有需求」。利用已設計的人工智能系統,結合電郵營銷的概念,Francis在2003年成功開發一套個人電郵營銷系統,是全球首個同類系統。

「每個客人都喜歡買東西,但就不喜歡硬銷。」電郵營銷的概念,是針對客人喜好,透過為企業設計電子通訊(e-newsletter)收集數據後,分析各用戶喜好、興趣及習慣等,再發出針對其「口味」的電郵,吸引他們消費(見另稿),「最重要是全個過程自動化」。

「增值」兼營市場分析

以大客Global Sources為例,這套方案每月可針對20個活動發出通知電郵,每封電郵針對個別收件者會有不同內容,發送的電郵量數以萬計,最多可應付800個活動的電郵,「甚至再多一點,視乎客戶的要求和需要」。

市場上競爭對手崛起,一按eDM便能找到很多同類服務的公司,最便宜的數百元有交易。不過,Francis現在賣的不單是發電郵系統,更是一整套市場分析顧問服務,為客戶「增值」,視乎整個宣傳策略的規模,收費由數萬元至100萬元不等。現時他公司的研發、設計及顧問團隊共有40多人。

進軍廣州上海 1年收支平衡

內地每10人便有5.5人用電郵,Francis看準這龐大市場,去年進軍廣州及上海,1年便已收支平衡。他說未來會繼續研發系統,不止單向的電郵宣傳,而是要做到e-communication,「有交流,有反應,才是真正的好科技」。

明報記者 謝凱瑩