Email Deliverability part 2: Chất lượng tập địa chỉ nhận

Trong bài trước, chúng ta đã phân tích yếu tố ảnh hưởng đầu tiên đến email deliverability: Nguồn Gửi.

Email Deliverability part 1: IP và Domain

Loạt bài tiếp theo đây, chúng ta sẽ phân tích các yếu tố ảnh hưởng tiếp theo: Chất lượng tập địa chỉ nhận.

Nguồn: ChooseWhat

Có 3 loại địa chỉ đặc biệt được nhà cung cấp dịch vụ mailbox xem xét: Địa chỉ không tồn tại (Unknown users), Bẫy spam (Spam traps) và Địa chỉ không hoạt động (Inactive users).

Địa chỉ không tồn tại (Unknown users)
Là địa chỉ chưa từng tồn tại, hoặc bị nhà cung cấp dịch vụ mailbox hay chính người dùng xóa khỏi hệ thống. Khi nhận email đến 1 địa chỉ không tồn tại, hệ thống email nhận sẽ trả về mã lỗi Hard-bounce 5xx có dạng:
550 <subscriber@acme.com> User unknown
550 <subscriber@acme.com> Mailbox does not exist
550 <subscriber@acme.com> Invalid recipient

Tỷ lệ unknown users / tổng số email trong 1 đơn vị thời gian cần được kiểm soát ở mức an toàn dưới 2%. Tỷ lệ trên 2% bắt đầu được coi là dấu hiệu nguồn gửi này là spammers. Tỷ lệ trên 10% thì hầu hết các hệ thống nhận email đều coi nguồn gửi này chắc chắn là Spammers.

Bẫy spam (Spam traps)
Là những hộp thư đặc biệt, được nhà cung cấp dịch vụ dành riêng để tiếp nhận email và phân tích khả năng nguồn gửi là spammers hay không.
Một email rơi vào bẫy spam nghĩa là nguồn gửi có vấn đề: 1/ lấy địa chỉ email từ nguồn xấu, hoặc 2/ địa chỉ nhận email không được dọn dẹp thường xuyên. Kể từ thời điểm này, địa chỉ IP, tên miền của nguồn gửi hoặc mẫu nội dung thư có thể bị liệt vào danh sách chặn tạm thời, hoặc vĩnh viễn. Loại và tuổi của bẫy spam là những yếu tố ảnh hưởng đến mức độ quyết định ngăn chặn.

Có 2 loại bẫy spam:

  • Bẫy spam tái sử dụng (Recycled): địa chỉ từng thuộc về một người thật, nhưng đã được chuyển thành bẫy spam sau khi người dùng dừng sử dụng. Bẫy spam loại này thường chỉ ra là tập địa chỉ nhận email không được dọn dẹp thường xuyên.
  • Hũ mật (Honey pot): địa chỉ được lập ra với mục đích rõ ràng từ đầu nhằm chặn bắt các nguồn gửi xấu. Nhiều nhà cung cấp dịch vụ bẫy spam để địa chỉ “hũ mật” lên website hoặc các diễn đàn, trang mạng khác, ẩn so với người dùng, nhưng lại dễ dàng đọc bởi các robot chuyên đi thu thập địa chỉ email. Nguồn gửi tới các địa chỉ “hũ mật” này ngay lập tức bị đánh giá là spammer.

Các lưu ý cụ thể duy trì chất lượng tập địa chỉ nhận:

  • Cách li riêng các tập dữ liệu mới: chỉ gửi thư chào hỏi, nếu không nhận lại mã lỗi 5xx mới đưa vào tập địa chỉ chính thức.
  • Cung cấp lựa chọn cập nhật địa chỉ tiện lợi: mọi người thường thỉnh thoảng thay đổi địa chỉ email và mong muốn cập nhật thông tin liên hệ nếu được cung cấp công cụ tiện lợi.
  • Xác nhận khi đăng ký: khi người dùng đăng ký, cần gửi thư xác nhận, thường đơn giản là click vào 1 đường dẫn tạo sẵn.
  • Cẩn thận lựa chọn tập địa chỉ: thường xuyên kiểm tra tập địa chỉ được cung cấp bởi bên thứ 3, để ra các quyết định sử dụng hay loại bỏ một nhóm hoặc cả tập địa chỉ.
  • Gửi email thường xuyên: về nguyên tắc, càng ít gửi email, nguy cơ email bị trả lại (bounce), hay thậm chí bị gửi vào bẫy spam (dạng “tái sử dụng”) càng cao. Dĩ nhiên, tần suất ở đây phải hiểu là tần suất gửi thực tế hàng ngày, hàng tuần…, không phải kiểu bắn email hàng loạt, lặp đi lặp lại đến 1 tập địa chỉ.
  • Theo dõi hành vi của người nhận: như một luật bất thành văn, địa chỉ nhận không hoạt động hoặc không có phản hồi gì hơn 1 năm cần được loại bỏ khỏi tập địa chỉ. Quãng thời gian có thể là 6 tháng hoặc 3 tháng nếu tần suất gửi khá thường xuyên.
  • Dọn dẹp tập địa chỉ: thường xuyên dọn dẹp các địa chỉ dạng chức danh (role) như sales@domain.com, địa chỉ dạng thử nghiệm như test@domain.com hoặc địa chỉ lỗi như jane@gmal.com.

Địa chỉ không hoạt động (Inactive users)

Địa chỉ không hoạt động đại diện chi những người không mở, click, hoặc thực hiện bất cứ hành động gì trên email nhận được trong một khoảng thới gian xác định. Nhiều tập địa chỉ chứa đến 80% là địa chỉ không hoạt động.

Địa chỉ không hoạt động tồn tại bởi nhiều nguyên nhân. Chúng không tác động trực tiếp đến chất lượng Tập địa chỉ và Khả năng nguồn gửi bị đánh giá spam như Địa chỉ không tồn tại (Unknown users) hoặc Bẫy spam (Spam traps), nhưng chúng làm giảm tỷ lệ phản hồi của cả chiến dịch/chương trình, và gián tiếp ảnh hưởng xấu đến điểm tín nhiệm nói chung. Vì vậy, cách tốt nhất là kiểm soát các địa chỉ không hoạt động trong trên phần mềm gửi thư qua từng chiến dịch/chương trình.

Một số lưu ý cụ thể:

  • Sử dụng chức năng của phần mềm gửi thư theo dõi dữ liệu về phản hồi của người dùng qua từng chiến dịch/chương trình.
  • Theo dõi, thống kê số lượng mở, click và bị trả lại (bounce). Đặc biệt lưu ý khi tỷ lệ mở, click giảm, hoặc khi tỷ lệ bị trả lại tăng bất thường. Dùng chính dữ liệu này làm các mốc xác định Địa chỉ không hoạt động hay Hoạt động, sau đó chủ động thiết đặt giảm tần suất gửi thư tới các địa chỉ không hoạt động.
  • Kiểm soát nguồn cung cấp các địa chỉ không hoạt động (từ website, từ đối tác, từ giới thiệu…) xác định mẫu số chung phát sinh các địa chỉ không hoạt động của từng nguồn để phòng tránh, giảm bớt tập địa chỉ loại này.

Thực hành tốt các lưu ý trong bài viết này để kiểm soát tốt cả 3 loại địa chỉ đặc biệt: Địa chỉ không tồn tại (Unknown users), Bẫy spam (Spam traps) và Địa chỉ không hoạt động (Inactive users) sẽ giúp nâng cao chất lượng tập địa chỉ nhận, qua đó kiểm soát tốt nhất điểm tín nhiệm cho nguồn gửi (sender reputation), đảm bảo email deliverability luôn ở mức cao nhất.

Email Deliverability part 1: IP và Domain

Như đã hẹn, sau đợt hỗ trợ đồng bào miền Trung tạm ổn, tớ bắt đầu quay lại với series bài viết về Email Deliverability.

Email Deliverability là khả năng hệ thống deliver email tới được Inbox người nhận, giống như kiểu anh shipper chuyển được hàng đến tận tay bạn.

Đây là bài đầu tiên trong tuyến bài, nói về một trong các thành phần cơ bản nhất, và cũng là thành phần quan trọng nhất: Nguồn Gửi.

Mời mọi người đọc & comment & trao đổi thêm.

Nguồn: BigMailer

Một trong các thông tin quan trọng nhất được công cụ Spam filter phía đầu hệ thống email người nhận dùng để đánh giá một email có phải là spam hay không là nguồn gửi, được cấu thành bởi 2 thành tố: địa chỉ IP và tên miền.

Về địa chỉ IP:

  • Hệ thống email đầu nhận kiểm tra điểm tín nhiệm (reputation) của địa chỉ IP dùng để kết nối, chuyển phát thư tới (Sender IP) theo một số thuật toán tương đối phức tạp, kết hợp nhiều tham số khác nhau để tính toán ra một chỉ số chung gọi là SenderScore có điểm số từ 0-100; một số hệ thống sử dụng các thuật toán khác tính toán ra chỉ số SenderBase có giá trị từ -10 đến +10. Một số tham số chính có thể kể đến:
    • Complaints: số lượng thông báo “đây là spam” của người dùng (chỉ số quan trọng nhất – nên cần tìm cách giảm thiểu complaints của người dùng)
    • Spam Traps: một loại dịch vụ đặc biệt của các nhà cung cấp dịch vụ Internet, chuyên bẫy các loại Spam khác nhau.
    • Message Composition: cách thức thu thập/trộn thông tin tạo ra nội dung thư gửi đi.
    • Volume: số lượng thư gửi đi theo đơn vị thời gian.
    • Blacklists: một loại dịch vụ đặc biệt của các nhà cung cấp dịch vụ Internet chuyên kiểm tra, theo dõi và liệt kê các địa chỉ IP gửi spam (cố tình hoặc có lỗi vô ý) vào danh sách đen.
  • Một số lưu ý cụ thể:
    • Địa chỉ IP cho chuyển phát thư số lượng lớn nên dùng riêng, tránh chia sẻ với các dịch vụ khác. Mỗi địa chỉ IP cần được thiết đặt bản ghi ánh xạ ngược PTR.
    • Các tham số ảnh hưởng chính đến IP reputation như nêu ở trên cần được kiểm soát thường xuyên, đảm bảo luôn trong ngưỡng giá trị cho phép. VD: Volume nên giữ tương đối cân bằng, không nên tăng đột ngột trong một khoảng thời gian ngắn.
    • Tránh thay đổi địa chỉ IP, trừ trường hợp bất khả kháng. Trường hợp thêm địa chỉ IP mới vào hệ thống chuyển phát thư số lượng lớn, cần thêm vào các hàng đợi phụ, được kiểm soát tốc độ chuyển phát thư, trước khi đưa vào các hàng đợi tốc độ nhanh hơn và cuối cùng vào hàng đợi chính. Hệ thống email phía đầu nhận gọi kỹ thuật này là “email throttling”, chuyên dùng để loại trừ các địa chỉ IP mới, thường được các spammer dùng để phát tán spam.

Về tên miền:

  • Tên miền được đăng ký trên hệ thống DNS toàn cầu, và trong phạm vi, ngữ cảnh về email, thường gắn liền với kỹ thuật “ký tên miền” (signing domain) được sử dụng trong giao thức xác thực tên miền như SPF, DKIM…
  • Điểm tín nhiệm của tên miền (Domain Reputation) được tính toán từ các tham số chính sau:
    • Spam folder placement rate: số email từ tên miền này bị đưa vào Spam folder sau khi Spam filter đánh giá IP reputation và nội dung thư.
    • Inbox placement rate: số email từ tên miền này vào Inbox.
    • Complaint rate: số email từ tên miền này bị người dùng đánh dấu là Spam.
    • “This is not spam” rate: số email từ tên miền này bị đưa vào thư mục Spam (nhóm 1) hoặc từng bị đánh dấu spam (nhóm 3), nhưng sau đó lại được người dùng đánh dấu là Not Spam.
  • Một số lưu ý cụ thể:
    • Cần thiết đặt các bản ghi DNS chuyên dùng cho các giao thức xác thực tên miền như SPF, DKIM, DMARC. Hầu hết các hệ thống email phía đầu nhận đều kiểm tra xác thực xem liệu email nhận được có thực sự được gửi từ tên miền này không. Việc thiết đặt này còn tăng cường điểm tín nhiệm cho tên miền và rộng hơn là thương hiệu của doanh nghiệp, đảm bảo những nguồn gửi không được xác thực sẽ bị Spam filter phía đầu nhận chặn lại.
    • Một số bản ghi DNS cần được thiết đặt bao gồm:

Các thành tố cấu thành nguồn gửi (địa chỉ IP và tên miền) cần được thường xuyên kiểm soát theo thời gian thực, đảm bảo luôn duy trì điểm tín nhiệm tốt nhất. Một sai sót nhỏ có thể dẫn đến ảnh hưởng rất lớn đến khả năng chuyển phát của cả hệ thống.

Ngoài nguồn gửi, còn nhiều yếu tố khác ảnh hưởng đến khả năng thư được deliver tới Inbox người nhận (email deliverability). Tuy nhiên hầu hết các yếu tố đó nằm ngoài phạm vi của hệ thống chuyển phát thư số lượng lớn nên sẽ cần được xem xét riêng.

Email Delivery series

Lâu lâu để blog mốc meo quá 😀

Đợt này đang có hứng, tớ sẽ viết một series bài về email delivery cho email gửi ra từ hệ thống của các bạn (corporate email, marketing email, automation email…), cách thức kiểm soát để đảm bảo 100% email luôn vào inbox người nhận.

FAD APAC KL 2016

FAD APAC for budget planning has been happened during two days 9th-10th of July in Kuala Lumpur with a lot of exciting discusions (something really hot 😉

Day 0:

My flight was booked lately so I have to transit in HCMC (the direct flight fare from Hanoi to KL was increased so much) and I came to KLIA a bit late. After a almost 2 hours to pass through Immigration gate, I decided to take a taxi to the hotel. It was a bit late so I did not want to look for routes on the map (I also had not got Internet connection on my phone). Finally, I met Zsun, Prima and other participants at the hotel!

Day 1:

Day 1 started with our discussions about current issues in each APAC country.

The most important for me is leadership status in APAC region. I have worked as the only APAC regional leader for years. Sometimes, due by the day life, I could not respond in time to everything as others expected. Especially, since I decided to jump into another big new open source project, OpenCPS, a half year ago, my spare time have been less. That’s why I really liked to delegate APAC leadership to a group of active Fedora contributors in APAC, the ones attended three last APAC FADs for budget planning. I am still here to support everyone. However, I would like others to be more active to take the leadership to push APAC region toward.

The next interesting topic we discussed in the morning is how to do more activities within APAC, while keep the region connected to the world. We discussed the idea of running bi-annual FUDCons (proposed by gnokii). The ideas behind this is to save a half of money for running FUDCon every other year ($15k per year, at this moment) for supporting APAC people to attend Flock every year ($7.5k per year). Annual FAD can be organized as a separated event in a year and mixed to FUDCon another year. Some travel subsidy could be saved for other useful activities/events (or added to Flock support for APAC people – raised to ~$9k per year).

During the first day, we did review the whole APAC FY2017 budget to cut it down to the final allocated budget, $11,500. After a lot of adjustments, it was cut down to $12,200 ($700 difference). The updated budget table could be found on the wiki here with about $3k left for media and $4,200 left for events/activities in APAC budget until the end of FY2017.

Day 2:

During the day 2, we discussed about FY2018 budget for media, swag, events and activities.

Some of important fixed items were listed as below:

  • Swags ($1,000), DVD ($1,500), Release parties ($1,000) for 2 releases: $3,500 * 2 releases = $7,000
  • FAD for budget planning: $5,000
  • SEA translation sprints (for approx 10 teams): $3,000
  • SFD 2017: $1,000
  • Some events in India: $1,000
  • Some events impact to the whole region:
    • Hong Kong Open Source
    • Barcamp Bangkok
    • Barcamp Yangoon
    • COSCup
  • Then fianally, we decided to support COSCup with $4,000 to send gnokii there to re-connect Fedora community in China, Hongkong and Taiwan.
  • Total requested funds: $20,000

The whole budget table could be found here: https://fedoraproject.org/wiki/FAD_KualaLumpur_2016/APAC/Budget:2017-2018 not has been really updated (someone will surely upload our final spreadsheet onto that page).

We also have a lot of discussion about how to grow up the APAC community. Some of them are really hot 😉 but most of them are quite effective for the whole region.

The FAD was ended at about 3:00 PM for sending some people (include me) to the airport to catch the late flights back to our cities for a coming work week.

Thank you all for attending and continuously contributing to Fedora. Especially thanks Izhar for hosting us, for welcoming us to our home with that really nice local dinner.

See you all everywhere 🙂

Nha Trang ICT 2015

I came to Nha Trang this year to bring Fedora back there after the successful event last year. This year, the event was held in another university in Nha Trang, TCU with more participants from other universities in Nha Trang and nearby cities.

There was a academy/science conference in the morning with some talks from open source enterprises who sponsor the whole event. The afternoon was reserved for FOSS communities and I had a session to introduce about the Fedora project to all students and lectures. There were about 200 attendees join into a big classroom.

During the session, I talked to them about the benefit of contributing to FOSS and Fedora. I told participants what the employers need in general when they recruit new employees, especially young students. Basically, they need candidates to have critical thinking, group working, English speaking and technical skills. Students can study those skills during participating in a FOSS project like Fedora.

I also had got a table to put some Feodra 23 DVD and small pins there. People were really interested in those gifts and grabbed them all in less than half an hour. People asked a lot of questions about Fedora and FOSS and I tried my best to answer most of them.

The last session in the afternoon was for Q&A. I was appointed to answer most community-related questions.

Hope students and lectures in the university and nearby would be more interested in Fedora and FOSS after this event.

See some more pictures here.

FAD APAC Singapore 2015

We had decided Singapore as the location for FAD APAC 2015 in a discussion during FUDCon Pune. Following up the first FAD for APAC budget planning in Phnom Penh last year, we would like to make a plan for the events, activities in APAC and budget for them during next fiscal year (March 2016 – February 2017). This year, as suggestions from FPL, Council and other community members, we also added another main purpose to develop a strategy/plan for user and contributor growth in APAC which had been discussed a little last year.

We tried to invite at least a person from each country in APAC. Some people were from countries where Fedora events and activities had been happening last year, some others were from countries which we would like to get them more active. However, due to budget limitation and/or lack of contributions, some countries do not have any representatives finally. Before attending FAD, all participants had been asked to list events, activities and ideas to grow up Fedora community in their owned countries. I think it would save a lot of time for all of us to prepare something in advance but not all participants got that small exercise done.

The FAD was in two days. We started the first day with a short introduction from each country representatives. People introduced themselves and reported the situation of Fedora community in each country. Most of us mentioned to the issue of smaller (than Ubuntu) users community. It would be better to have a large number of users since people often contribute to an open source project after using it for a while. However, in some specific situations, the conversion rate (from users to contributors) is more important. Another common issue in APAC is lesser people’s attention to operating systems. In some countries, people now pay more attention to other *new* things like apps, data, etc. We agreed that our strategy to reach them needs to be changed, but it should be different from a country to the others. A common thing we could do together is to organize more interesting events, activities and distribute more media, swags to attract more attention from people. Beside that, since APAC is a large and cultural/language different area, each country should have a specific strategy/plan to grow up users and contributors community.

Also during the first day, we started discussing on the future Fedora events and activities next year. Each country described their scheduled events, activities then we tried to see if other countries/members can collaborate and to estimate necessary budgets to each of them. At the end of the day, after long discussions and (sometimes :)) debates, we made a list of scheduled events and activities in APAC next year and estimated budget for each.

See more: https://fedoraproject.org/wiki/FAD_Singapore_2015/Events

Also during the first day, we discussed about media and swag production and distribution process. We decided to improve our system to do producing them centrally then distribute to other countries. Indian community did a good job last two-three releases so we decided to continue that way. The best way for media distribution, especially to some strict countries like China, is via Red Hat channel. Media would be distributed to Singapore for all ASEAN countries via Red Hat offices too. The request, tracking, managing tools (e.g. Trac) also need to be changed to adapt the new process. We decided to think and discuss more to define that process and related tools as good and clear as possible.

During the second day, we discussed more about CC holder and reimbursement process in APAC. Since the current APAC CC holder, Izhar, is too busy, some reimbursements are not fast enough. People need to wait for a few months to get their prepaid money back. We decided to propose to have an additional CC holder for APAC (preferable in India/SL since that is a large area with a lot of Fedora contributors). We would send our proposal officially once we find a good candidate.

For better collaboration among countries in the whole region, we discussed more about tools (e.g. Trac, mailing lists), meetings and plans. Some Ambassadors in APAC do not know their job/tasks even common stuffs like Ambassadors’ plan in each release cycle. We decided to improve regional leadership as well as ourselves to do the Ambassador job better.

Later of the day, we tried to find out the candidates for new Budget.next roles. Once this new process is out officially, we will make the final decision based on those candidates.

Some other stuffs have been opened and need to be discussed more. However, for me, this FAD was success as we got almost main purposes done.

Please kindly checkout this pad for more information: http://piratepad.net/FAD-Sngapore-2015

Last but not least, you should also check out other interesting event reports and photos from other attendees.

FUDCon Pune 2015 – toward the future

FUDCon Pune 2015 has just been closed. My flight would be one of the earliest one after FUDCon leaving India ( I am the Mumbai airport now).

While Closing keynote shown a lot of impressing numbers, I personally want to share some thoughts from one of FUDCon participants’ point of view. I haven’t attended any more FUDCons since FUDCon KL 2012 (FUDCon APAC 2013 was cancelled by lack of bids and I myself missed FUDCon Beijing 2014) so it was really exciting to me to meet more people again and again. Some faces I have met several times before at Flock, FAD and many other events, some faces are quite new, but all of them are really friendly. Meeting and discussing with people face to face is still one of the best things in open source world.

During the FUDCon we participated in a lot of interesting talks and discussions. I loved the closing keynotes in day-1, Whats Going On In A FOSS Project by HarishPillay, and day-2, Achieving Community Goals with Fedora, by tnzchok. They contain a lot of ideas to push Fedora and open source projects toward. I also loved “”Selling” Open Source 101″ by my friend, Izhar as well as a lot of other interesting talks down there.

I myself actively participated in BoF discussions about budget planning, organizing events, media/swag production and distributing, etc. In the day-1, we had a BoF discussion to decide FUDCon location for 2016. As I reported to the mailing list, we decided to have more time for the Cambodian team to make their bid more ready. In the day-3, we had another BoF session to discuss about the location for Budget Planning FAD 2015, how to produce and distribute media and swag better and I also had a wrap-up for all to follow them up.

Everything is going on and I believe after the FUDCon with a lot of discussions and ideas, we can make the project better, toward the bright future.

Thanks all my friends. Hope to see you next times.

 

 

 

 

Vấn đề đăng nhập vào Zimbra webmail với Firefox mới

Vừa upgrade lên Firefox 37 sau một thời gian dài sử dụng Firefox 33, tôi gặp ngay vấn đề không thể đăng nhập vào Zimbra (8.6) webmail. Thử truy cập phiên bản HTML thấy vào được bình thường, như vậy lỗi xảy ra với thiết đặt nào đó khiến AjaxPackage không load lên được.

Lần ngược về các thay đổi chính trong Firefox phiên bản mới, một điểm quan trọng tôi thấy là từ phiên bản Firefox mới thay đổi cách thức thiết đặt tham số, trong đó có một tham số quan trọng, dom.indexedDB.enabled, theo hướng dẫn của Mozilla, là một browser API dành cho client-side storage. Điều đáng nói là sau khi nâng cấp, tham số này trên Firefox của tôi được đặt là false; đổi lại thành true (xem hình dưới), mọi thứ hoạt động ngay tắp lự 🙂

firefox-37-zimbra

Các bước thực hiện:

  1. Nhập địa chỉ “about:config” để mở phần thiết lập tham số cho Firefox
  2. Search từ “indexedDB”
  3. Double click vào “dom.indexedDB.enabled” để đổi từ false thành true

Chúc các bạn may mắn 🙂

The first OpenDay 2015 – key statistics

Chào các anh, các chị và các bạn,

OpenDay, sự kiện đầu tiên được VFOSSA tổ chức riêng cho các dự án, nhóm cộng đồng nguồn mở, đã diễn ra được hơn một tuần với rất nhiều cung bậc cảm xúc từ nhiều phía.

Trước hết, thay mặt BTC, xin gửi lời chân thành cảm ơn tới các cá nhân, nhóm cộng đồng, các công ty đã quan tâm tham dự. Không có sự tham dự này, dù là sự kiện dành riêng cho chính các bạn, OpenDay cũng khó có được bất kỳ kết quả gì, chứ đừng nói đến thành công hay không. Cảm ơn Trường đại học Thăng Long đã đứng ra hỗ trợ đang cai tổ chức. Cảm ơn các DN thành viên VFOSSA đã tích cực hưởng ứng sự kiện trong vai trò nhà tài trợ: D&L, Netnam, HaproInfo, eXoPlatform, VDC-IT, Geekpolis, EcoIT, DTT đã tài trợ cho sự kiện. Cảm ơn ITPlus, Vinades, iWay đã hỗ trợ công tác tổ chức và tư vấn về nội dung. Và đặc biệt cảm ơn Open Development Cambodia, nhóm cộng đồng quốc tế duy nhất, đã mang đến cho OpenDay một chủ đề rất mới mẻ và đầy hứa hẹn, OpenData.

Báo cáo này chủ yếu liệt kê một số dữ liệu cơ bản, không (hoặc ít) kèm theo các bình luận cảm tính cá nhân. Sau kỳ nghỉ lễ 30/4, chúng tôi sẽ dành thêm thời gian phân tích sâu hơn, đặc biệt là về mặt được và chưa được của sự kiện vừa qua để rút kinh nghiệm và tổ chức các sự kiện OpenDay tới được tốt hơn.

Đầu tiên, về tài chính, với sự hỗ trợ của các nhà tài trợ và công tác tổ chức, tổng thu – tổng chi sau sự kiện đã dương. Chi tiết thu/chi tài chính sẽ được thông báo cho các nhà tài trợ và BTC. Phần tiền dư sẽ được chuyển vào quĩ chung của VFOSSA để hỗ trợ tổ chức các sự kiện OpenDay sau cũng như các hoạt động khác của cộng đồng.

Khoảng 40 người (lúc đông nhất là gần 50, chưa kể đội ngũ các tình nguyện viên) đã tham dự tại hội trường trường ĐH Thăng Long và khoảng hơn 20 người đã tham dự online từ xa, qua dịch vụ TrueConf được hỗ trợ bởi HaproInfo.

Trong phiên buổi sáng, sau phát biểu khai mạc của ông Nguyễn Hồng Quang, Chủ tịch VFOSSA, 3 cộng đồng đã có dịp giới thiệu về dự án và các công việc đang thực hiện của mình, bao gồm: NukeViet (Mr. Hùng, NukeViet – Vinades), OpenData (Mr. Lê Trung Nghĩa và Mrs. Terry Parnell, OpenDevCam)  và OpenEC (Mr. Tuấn, OpenEC – iWay)

Khoảng 30 người đã tham dự ăn trưa và tiếp tục trao đổi các chủ đề cùng quan tâm.

Phiên buổi chiều tổ chức theo hình thức Birds of a Feather với chủ đề trọng tâm về OpenData, một khái niệm còn tương đối mới mẻ ở Việt Nam. Sau hơn 3h thảo luận, nhóm làm việc (đến cuối buổi còn khoảng 15 người) đã thống nhất chính thức khởi động thành lập cộng đồng OpenData Việt Nam, kết nối ngay với Campuchia, Thái Lan; chuẩn bị mời thêm Myanmar, Lào để hình thành OpenDevMekong, tiến tới kết nối toàn khối, hình thành cộng đồng OpenData ASEAN. Một mailing list OpenData mới và một Facebook page OpenData ASEAN đã nhanh chóng được lập ra để kết nối ngay cộng đồng, bắt đầu từ những người đã tham dự phiên buổi chiều, và ngay lập tức đã thu hút thêm nhiều người quan tâm.

Cộng đồng OpenData sẽ sớm tổ chức một số hoạt động như dịch sách OpenData Handbook, công cụ quản trị CKAN, tổ chức Video conference với một số nhóm cộng đồng đã và đang làm hoặc quan tâm đến OpenData để chia sẻ kinh nghiệm. Các bạn quan tâm có thể tham gia vào mailing list và/hoặc Facebook page để nhận được các thông tin mới nhất và cùng tham gia thảo luận.

Một số số liệu ngoài lề khác:

  • 85 lượt likes trên OpenDay Fan page trên Facebook tính tới thời điểm hiện tại.
  • Post Reach 1,641, Engagement 233 People Engaged, 15 Comments, 14 Shares, 2,632 post clicks.

Một số bài đã đăng:

P.S. cá nhân tôi xin chân thành gửi lời xin lỗi vì sự chậm trễ công bố báo cáo về sự kiện, phần vì muốn chờ thu thập tương đối đủ dữ liệu, phần vì công việc hàng ngày trước kỳ nghỉ lễ 30/4 quá bận.

Rgds,
Truong Anh Tuan

Vài nét về giấy phép nguồn mở mới của Zimbra Collaboration Suite

Giữa năm 2014, Zimbra Inc. chính thức công bố phiên bản 8.5 mới, phát hành theo giấy phép GPL v2 (phía server platform) và CPAL v1 (phía web application). Đây là một bước tiến lớn so với trước đây, khi Zimbra được phát hành theo giấy phép Zimbra Public License, không được cả Free Software Foundation lẫn Open Source Initiative thừa nhận, mang Zimbra CS tới gần với cộng đồng hơn, qua đó, mang lại cơ hội lớn cho người sử dụng, các nhà phát triển, tích hợp hệ thống và cung cấp dịch vụ.

Gần 1 năm trôi qua, phiên bản 8.6 đã được phát hành, sắp tới sẽ là các phiên bản 8.7, 9.0… chúng tôi hy vọng bài viết này sẽ giúp quí vị tìm hiểu những kiến thức cơ bản về CPAL v1 nói chung và áp dụng cụ thể trong trường hợp Zimbra. Qua đó, thực hiện đúng và đủ các quyền và nghĩa vụ của mình, tôn trọng những đóng góp của cộng đồng phát triển Zimbra nói riêng cũng như cộng đồng phần mềm tự do nguồn mở nói chung.

Một trong những nội dung quan trọng trong giấy phép CPAL v1 là cho phép (nhóm) tác giả có phần mềm phát hành theo giấy phép này được quyền yêu cầu người sử dụng, các nhà phát triển, tích hợp hệ thống và cung cấp dịch vụ cũng như toàn thể thành viên trong cộng đồng, khi tải phần mềm về sử dụng hoặc cung cấp dịch vụ, giữ lại nguyên trạng một số các thông tin quan trọng, liên quan đến tác giả gốc, bao gồm: tuyên bố về quyền tác giả (Attribution Copyright Notice), tuyên bố chung (Attribution Phrase) không quá 10 từ, đường link đến website của (nhóm) tác giả (Attribution URL) và logo kèm theo (Graphic Image provided in the Covered Code as file)

Trong trường hợp cụ thể của Zimbra, các thông tin này được yêu cầu như sau:

Các thông tin này được yêu cầu giữ nguyên trên giao diện người dùng cuối (GUI). Trong trường hợp đoạn chương trình chạy không thể hiện trên một giao diện người dùng cuối thì tên và đường link đến website công ty Zimbra Inc. phải được ghi trong từng file mã nguồn.

Bạn có thể tải toàn văn giấy phép phát hành của Zimbra tại: https://files.zimbra.com/website/docs/Zimbra-Open-Source-Edition-License.pdf