Koha: một trường hợp điển hình trong quyền sở hữu dự án nguồn mở

Koha: a case study in open source project ownership

By Mark Johnson, Published: 16 April 2013, Reviewed: 16 April 2013

Theo: http://www.oss-watch.ac.uk/resources/cs-koha

Bài được đưa lên Internet ngày: 16/04/2013

Lời người dịch: Rất nhiều điều thú vị về dự án Koha, một Hệ thống Thư viện Tích hợp - ILS (Integrated Library System) nguồn mở trong câu chuyện kể trong bài. Nhiều bài học được nêu lên từ đây khi làm việc với cộng đồng và với các công ty nguồn mở. Hiện Koha có 3 thương hiệu: (1) Koha được cộng đồng quốc tế đa dạng phát triển; (2) LibLime Koha được PTFS phát triển cho các yêu cầu của các khách hàng của nó; (3) LibLime Academic Koha được PTFS phát triển cho một nhóm các viện trường. Nếu đi theo Koha, bạn phải lựa chọn đấy!

Trong khi biên soạn danh sách của OSS Watch về Các lựa chọn Nguồn Mở cho Giáo dục, tôi đã phát hiện ra Koha, một Hệ thống Thư viện Tích hợp - ILS (Integrated Library System) nguồn mở. Tôi đã phát hiện, với một số sự lấn bấn, rằng dường như có vài hệ thống ILS được gọi là Koha. Nghiên cứu lý do cho điều này đã phát hiện một câu chuyện mà đưa ra các bài học có giá trị về quyền sở hữu dự án nguồn mở, bao gồm cả việc làm thương hiệu, nhãn hiệu thương mại, và giải quyết xung đột.

Koha đã bắt đầu cuộc sống của nó tại New Zealand (được phản ánh theo tên, mà nó là một từ Māori có nghĩa là món quà có đi có lại, hoặc một món quà với những mong đợi). Ban đầu nó từng được Horowhenua Library Trust (HLT) ủy quyền, được cong ty Katipo Communications Ltd. viết, và được phát hành theo giấy phép GPL. Quan trọng, Katipo đã giữ bản quyền về mã của Koha.

Như một trong số ít các lựa chọn nguồn mở trong một thị trường bị các hệ thống sở hữu độc quyền áp đảo, một cộng đồng các thư viện, các công ty, và các lập trình viên đã lớn lên xung quanh Koha. Khi thị trường của nó trở thành quốc tế, nó đã lôi được sự chú ý của Joshua Ferraro, người đã làm việc cho một thư viện công ở Mỹ.

Sát nhập

Ferraro bỏ công việc của ông ở thư viện để thành lập LibLime, một công ty cung cấp sự phát triển và hỗ trợ Koha. Liblime sớm cung cấp Koha tới một số thư viện tại Mỹ, và khi mà số lượng khách hàng của nó gia tăng, thì công ty cũng phát triển. LibLime đã mua Skemotah, một hãng tư vấn với bản quyền về nhiều tài liệu ban đầu của Koha, và bộ phận Koha của Katipo.

Với sự mua các công ty đó, LibLime đã trở thành chủ sở hữu của một phần lớn IP và các tài sản có liên quan của dự án Koha. Katipo cũng đã đặt chỗ website dự án, danh sách thư, bugzilla, và làm chủ tên miền koha.org. Sự kiểm soát của chúng bây giờ đã được chuyển sang cho LibLime. LibLime cũng đã đăng ký thương hiệu Koha ở Mỹ.

Cùng lúc đó, LibLime đã tham gia sâu vào cộng đồng Koha. Ferraro đã phục vụ như là người quản lý phát hành, giám sát phiên bản hàng đầu 3.0. Tuy nhiên, sớm sau đó vận may này của LibLime đã thay đổi.

Những chia rẽ

Một công ty khác đã cung cấp các hệ thống ILS tại Mỹ, Progressive Technology Federal Systems (PTFS), đã quyết định thay đổi hồ sơ của nó sang một chào hàng nguồn mở đầy đủ. Điều này bao gồm cả Koha, và ILS nguồn mở khác, gọi là Evergreen. Ferraro đã xem PTFS như là một đối thủ cạnh tranh và coi họ như là những kẻ xấu trong cộng đồng, bất chấp sự tham gia tích cực của họ. Ảnh hưởng của LibLime đối với cộng đồng có nghĩa là nhiều thành viên bên ngoài LibLime cảm thấy nằm ở hàng chống lại PTFS, tạo ra sự hiềm khích giữa 2 bên.

Galen C-harlton, một nhân viên của LibLime, được chỉ định như là quản lý phát hành cho chu kỳ phát hành của Koha v3.2. Khi đó, Koha đã không có lịch trình cho các phát hành, và chúng chỉ được thực hiện khi người quản lý phát hành nghĩ rằng chúng là sẵn sàng rồi.

Trong chu kỳ phát hành này, LibLime như một công ty đã thiết kế ngược từ cộng đồng, thay vì tập trung những nỗ lực phát triển của nó vào một sản phẩm gọi là LibLime Enterprise Koha. Sản phẩm này đã được triển khai khắt khe cho các đặc tả của khách hàng, đằng sau các cánh cửa đóng. Bất chấp các lý do của Ferraro là ngược lại, cộng đồng đã xem điều này như là một rẽ nhánh, và đã gặp phải sự căm phẫn. Vài nhân viên của LibLime đã rời bỏ công ty. Galen C-harlton đã chuyển tới Equinox, người đã cung cấp hỗ rợ cho Evergreen. Người khác, Nicole Engard, từng được LibLime thuê làm như một Người truyền bá Nguồn Mở, và khi hoạt động nguồn mở của công ty chấm dứt, bà đã chuyển tới ByWater Solutions, một nhà cung cấp khác của Koha.

Sự kết hợp

Vào thời điểm này, mọi điều đều đã trở nên phức tạp. Ferraro và những người sáng lập khác của LibLime đã quyết định rằng đã tới lúc đi tiếp và chuyển sự chú ý của họ sang các lĩnh vực khác. Họ đã tiếp cận PTFS và đã chào báo LibLime cho họ.

Trong thời gian này, các thành viên của cộng đồng mất sự truy cập soạn sửa tới koha.org và thiết lập koha-community.org như là nhà riêng của cộng đồng dự án Koha. Sau một số sự không chắc chắn, sự chào bán đã được đồng ý. PTFS bây giờ là chủ các tài sản của LibLime, bao gồm cả một đống IP của Koha và website koha.org.

Bất chấp kỷ lục của PTFS tham gia vào trong cộng đồng, sau khi mua LibLime đã được hoàn tất thì họ đã quá kéo ngược khỏi dự án cộng đồng. Khi Galen C-harlton bây giờ đã làm việc cho Equinox, thời gian ông có thể đệ trình cho phát hành v3.2 của Koha bị hạn chế. PTFS đã không hạnh phúc với tốc độ phát hành và đã rẽ nhánh dự án từ trong nội bộ, tạo ra một sản phẩm gọi là LibLime Koha, với nhà của nó ở koha.org.

Không may, điều này đã chỉ phục vụ cho sự tổn hại của các mối quan hệ với cộng đồng Koha. Koha.org trước đó từng là nhà của dự án Koha cộng đồng, và bây giờ đã quảng bá cho một dự án mà, trong khi là nguồn mở, đã được một công ty duy nhất phát triển.

Một cú đánh khác nữa cho mối quan hệ đó là cú đánh ngay trước khi có vụ bán LibLime, công ty đã đệ trình một đơn xin nhãn hiệu cho việc đánh dấu KOHA ở New Zealand. Vì PTFS bây giờ đã là chủ của tất cả các tài sản của LibLime, đơn xin đã được chuyển tới họ. Đã có một cơ hội thoáng qua trong sự hòa giải khi cộng đồng Koha đưa ra trước một chương trình nghị sự cho một cuộc họp với PTFS.

CEO của PTFS đã cố gắn đặt lịch cho một cuộc gọi hội nghị với các thành viên của Tiểu ban HLT Koha. Trong khi ban đó ban đầu đã chấp nhận ý tưởng đó, các cuộc thảo luận điều hành thường diễn ra trong các danh sách thư và các kênh chat IRC, nên họ đã quyết định họ chỉ có thể có thiện chí có những thảo luận như vậy theo một trong những định dạng đó. Các yêu cầu thảo luận diễn ra theo cách này không may đã bị từ chối. PTFS đã nhận được một vài hỏa lực từ các thành viên cộng đồng và đã đáp trả với một thông cáo báo chí chỉ ra rằng cộng đồng đã không nghiêm túc về việc có các cuộc thảo luận. Tiểu ban HLT Koha đã xuất bản một báo cáo từ quan điểm của họ.

Đơn xin thương hiệu ở New Zealand từng được trao từ IPONZ. Các cá nhân từ cộng đồng đã chống lại sự trao đó, nó bây giờ chờ quyết định cuối cùng.

Những bồi thường

Chúng tôi đứng ngày hôm nay với 3 thương hiệu có sử dụng tên Koha.

• Koha được cộng đồng quốc tế đa dạng phát triển.

• LibLime Koha được PTFS phát triển cho các yêu cầu của các khách hàng của nó.

• LibLime Academic Koha được PTFS phát triển cho một nhóm các viện trường.

Các công ty khác trong cộng đồng Koha sử dụng tên Koha, trong khi sản phẩm của họ được thiết kế từ kho mã của cộng đồng và có thể có những tùy biến bản địa.

Tôi đã thảo luận về tiềm năng đối với sự tham gia của cộng đồng trong LibLime Koha với Patrick Jones, Giám đốc Giải pháp và Dịch vụ Thư viện dựa vào Thương mại ở PTFS. Điều họ quan tâm là, tất cả và từng bản được chào đón để lấy, sử dụng và đóng góp cho kho mã của LibLime Koha, nó vẫn còn được phát hành theo GPL và là sẵn sàng trên GitHub. Họ đã ghi lại hơn 1.000 bản tải về mã nguồn mở trên đỉnh của các phát triển mà họ quản lý cho các khách hàng, và có vài bản rẽ nhánh của những người sử dụng GitHub. Tuy nhiên, bất kỳ sự thay đổi nào được các bên đó làm cũng đều được đóng góp ngược trở lại cho kho mã của LibLime.

Dự án LibLime Academic Koha tuân theo một mô hình khác. Các bên phải thực hiện một cam kết tài chính để trở thành một phần của nhóm điều hành sự phát triển, vào thời điểm nào mà họ còn có sự truy cập tới sản phẩm. Mã nhất thiết là GPL (bản dịch tiếng Việt), nhưng không được phân phối ra bên ngoài nhóm.

Điều này là tương tự như mô hình nguồn cộng đồng (bản dịch tiếng Việt) được dự án Sakai sử dụng trong các giai đoạn đầu của nó.

Người ta có thể viện lý vốn dĩ không là tồi cho một dự án để rẽ nhánh, nhưng có thể có những lợi ích nếu tất cả các phiên bản của Koha được thiết kế từ cùng kho mã nguồn. Trong khi chắc chắn là một dấu hiệu lành mạnh khi một dự án nguồn mở được đa dạng hóa và được tùy biến cho những yêu cầu cá nhân riêng rẽ, thì điều này neenn đảm bảo rằng toàn bộ cộng đồng đã hưởng lợi từ nỗ lực phát triển được chia sẻ. Trong khi một bên quyết định không đóng góp những thay đổi của họ ngược trở về vì bất kỳ lý do gì, thì một kho mã được chia sẻ ít nhất cũng cung cấp một đường cơ bản biết được cho các lập trình viên và các khách hàng.

Tuy nhiên, với các kho mã mà đã rẽ nhánh như với Koha và LibLime Koha, có thể cần một số nỗ lực đáng kể để tích hợp những thay đổi từ từng kho mã đơn nhất, và thỏa thuận về kho mã nào điều này sẽ là. Trong khi PTFS và các công ty trong cộng đồng Koha tất cả cùng có các nhân viên được trả tiền để làm việc về mã đó, tất cả chúng phải đáp ứng được các yêu cầu của các khách hàng của họ, sao cho có thể có nhu cầu để trở thành một trường hợp nghiệp vụ rõ ràng cho việc chuyên tâm thời gian cho để làm cho điều này xảy ra.

Có thể có nhu cầu thỏa hiệp ở cả 2 phía để chữa lành sự rạn nứt đó. Vấn đề là cộng đồng đã lôi cuốn được sự quan tâm chú ý nhất những năm gần đây về sự thuyết phục của PTFS đối với thương hiệu của New Zealand. Điều này được xem, đặc biệt với HLT mà cũng của các thành viên khác của cộng đồng quốc tế, khi một cuộc tấn công vào sự nhận diện của dự án Koha. Việc rút đơn xin có thể đi cùng với việc chữa sự rạn nứt hiện hành. Quan điểm của PTFS là vì sự mua LibLime của họ cho cho họ quyền sở hữu bản quyền đối với nhiều mã, tài liệu, logo của Koha và quyền sở hữu của vài website có liên quan tới Koha, nên cộng đồng nên thừa nhận vị thế và quyền của họ để sử dụng cái tên Koha.

Các bài học

Có một số bài học chính có thể học được từ câu chuyện này, cả cho các dự án nguồn mở và cho các công ty tham gia vào với các dự án đang tồn tại.

Trước hết là vấn đề các tài sản. Một khi một dự án được thiết lập, bạn có thể muốn xem xét chuyển quyền sở hữu của các tài sản sang một quỹ phi lợi nhuận. Có một số quỹ phần mềm tồn tại cho mục đích này. Làm cho các tài sản của bạn được giữ theo cách này đảm bảo rằng việc mua và bán các công ty không dẫn tới chuyển giao các IP dự án của bạn.

Bạn nên làm việc với giả thiết (và quả thực ý định) rằng các tổ chức thương mại sẽ có quan tâm trong việc cung cấp các dịch vụ xung quanh sản phẩm của bạn. Việc thu hút các công ty tới sản phẩm của bạn là con đường chủ chốt cho tính bền vững, khi mà nó cung cấp sự hỗ trợ tài chính cho sự phát triển liên tục.

Tuyệt vời để cảm thấy được là các công ty đó sẽ muốn làm những điều giống như việc đăng ký thương hiệu mà gắn liền với chào nhãn hàng của họ. Để tránh sự lẫn lộn, là thông minh để đảm bảo nhãn hàng mà bạn muốn thúc đẩy dự án được bảo vệ càng rộng rãi càng tốt (như, bằng việc đăng ký một thương hiệu), và đảm bảo có những chỉ dẫn rõ ràng điều chỉnh sự sử dụng của nó.

Đối với một công ty phải hỗ trợ dự án của bạn, nó sẽ cần có khả năng cung cấp một dịch vụ được đảm bảo để cho các khách hàng. Một chu kỳ phát hành biết được trước sẽ giúp làm cho điều này có khả năng, khi nó cho phép một công ty lên kế hoạch cho các dịch vụ của nó xung quanh một lịch được biết của các phát hành.

Nếu bạn tham gia vào với một dự án đang tồn tại, thì nó luôn hướng tới tiếp cận tình huống một cách khiêm nhường. Một dự án được thiết lập tốt rồi sẽ có một cấu trúc điều hành mà cộng đồng có sự tin tưởng. Hãy làm việc trong các cấu trúc được thiết lập đó, và một khi bạn đã đóng góp cho dự án, thì bạn có thể ở trong một vị thế giành được ảnh hưởng và sử dụng nó cho các lợi ích tiếp theo của bạn.

Mâu thuẫn liên tục là không tốt cho bất kỳ bên nào có quan tâm. Không bao giờ đánh mất một cơ hội thảo luận một vấn đề và tìm cách giải quyết. Nếu 2 bên bản thân họ không thể đồng ý về các khoản, thì có thể giúp tìm người trung gian từ một bên thứ 3 mà có thể đưa ra sự thỏa hiệp.

Khi cảm xúc xung quanh một vấn đề lên cao, có thể là khó để dừng lại và nắm lấy một quan điểm khách quan của một tình huống. Ở những nơi có những sự không đồng ý trong quá khứ, xin lỗi cá nhân vì những bình luận được xuất bản trong sự cáu giận có thể là chỗ tốt để bắt đầu.

OSS Watch duy trì một loại bài tóm tắt (bản dịch tiếng Việt) và các bài báo về điều hành dự án, tính bền vững và sự tham gia của cộng đồng. Nếu muốn thông tin và huấn luyện về việc áp dụng chúng cho dự án của bạn, xin liên hệ.

Tôi muốn cảm ơn Patrick Jones và Nicole Engard vì bỏ thời gian để kể câu chuyện Koha cho tôi. Nếu bạn muốn tìm nhiều hơn, có một danh sách đọc các tin bài và bài viết trên blog về dự án này.

While compiling OSS Watch’s list of Open Source Options for Education, I discovered Koha, an open source Integrated Library System (ILS). I discovered, with some confusion, that there seemed to be several ILS systems called Koha. Investigation into the reason for this uncovered a story which provides valuable lessons for open source project ownership, including branding, trademarks, and conflict resolution.

Koha started its life in New Zealand (reflected in the name, which is a Māori word meaning reciprocal gift, or a gift with expectations). It was originally commissioned by the Horowhenua Library Trust (HLT), written by Katipo Communications Ltd, and released under the GPL. Crucially, Katipo held the copyright on the Koha code.

As one of the few open source options in a market dominated by proprietary systems, a community of libraries, companies, and developers grew around Koha. As its market became international, it came to the attention of Joshua Ferraro, who worked for a public library in the USA.

Acquisitions

Ferraro left his job at the library to found LibLime, a company providing Koha development and support. LibLime was soon providing Koha to a number of libraries in the USA, and as its customer base grew, so did the company. LibLime bought Skemotah, a consulting firm with copyright over a lot of Koha’s early documentation, and Katipo’s Koha division.

With the purchase of these companies, LibLime became owner of a large proportion of the IP and related assets of the Koha project. Katipo also hosted the project’s website, mailing list, bugzilla, and owned the koha.org domain name. Control of these now transferred to LibLime. LibLime also registered the trademark of Koha in the US.

At the time, LibLime was deeply engaged with the Koha community. Ferraro served as release manager, overseeing the flagship 3.0 release. However, soon after this LibLime’s fortunes changed.

Divisions

Another company who provided ILS systems in the USA, Progressive Technology Federal Systems, decided to change its portfolio to a fully open source offering. This included Koha, and another open source ILS called Evergreen. Ferraro viewed PTFS as a competitor and set to paint them as the bad guys in the community, in spite of their positive record of engagement. LibLime’s influence over the community meant that many members f-rom outside LibLime fell into rank against PTFS, creating bad blood between both parties.

Galen C-harlton, a LibLime employee, was appointed as release manager for the 3.2 Koha release cycle. At the time, Koha had no fixed schedule for releases, and they were made only when the release manager deemed them to be ready.

During this release cycle, LibLime as a company drew back f-rom the community, instead focusing its development efforts on a product called LibLime Enterprise Koha. This product was developed strictly to client specifications, behind closed doors. Despite Ferraro’s arguments to the contrary, the community viewed this as a fork, and met the announcement with indignation. Several LibLime employees left the company. Galen C-harlton moved to Equinox, who provided support for Evergreen. Another, Nicole Engard, was employed by LibLime as an Open Source Evangelist, and as the company’s open source activity ceased, she moved to ByWater Solutions, another Koha provider.

Conglomeration

At this point, things took a complex turn. Ferraro and the other founders of LibLime decided that it was time to move on and turn their attentions to other areas. They approached PTFS and offered to sell LibLime to them.

During this time, members of the community lost editing access to koha.org and set up koha-community.org as a community-owned home of the Koha project. After some uncertainty, the sale was agreed. PTFS now owned LibLime’s collective assets, including the amassed Koha IP and the koha.org website.

Despite PTFS’s record of engaging in the community, after the LibLime purchase was completed they too pulled back f-rom the community project. As Galen C-harlton now worked for Equinox, the time he could commit to the 3.2 release of Koha was limited. PTFS was unhappy with the speed of releases and forked the project internally, creating a product called LibLime Koha, with its home at koha.org.

Unfortunately, this only served to the detriment of relations with the Koha community. Koha.org was previously the home of the community Koha project, and now promoted a project which, while open source, was developed by a single company.

A further blow to the relationship was struck when it became apparent that just before the sale of LibLime, the company had filed a trademark application for the mark KOHA in New Zealand. As PTFS now owned all of LibLime’s assets, the application was transferred to them. There was a fleeting chance at reconciliation as the Koha community put forward an agenda for a meeting with PTFS.

The CEO of PTFS attempted to schedule a conference call with members of the HLT Koha Subcommittee. While the committee was initially receptive to the idea, governance discussions typically took place on mailing lists and IRC channels, so they decided they would only be willing to have such discussions in one of these formats. Requests for discussions to take place in this way were unfortunately declined. PTFS recieved some flak f-rom members of the community and responded with a press release indicating that the community wasn’t serious about having discussions. The HLT Koha Subcommittee published a report f-rom their point of view.

The application for the New Zealand trademark has been provisionally granted by IPONZ. Individuals f-rom the community opposed the grant, which now awaits a final ruling.

Reparations

We stand today with three brands using the name Koha.

• Koha is developed by a diverse international community.

• LibLime Koha is developed by PTFS to the demands of its clients.

• LibLime Academic Koha is developed by PTFS for a consortium of institutions.

Other companies on the Koha community use the name Koha, whe-re their product is drawn f-rom the community’s codebase and may have local customisations.

I discussed the potential for community engagement in LibLime Koha with Patrick Jones, Director of Commerce-based Library Solutions and Services at PTFS. As far as they are concerned, all and sundry are welcome to take, use, and contribute to the LibLime Koha code base, which is still released under the GPL and is available on GitHub. They have recorded over a thousand downloads of the open source code on top of the deployments they manage for clients, and there are several forks by GitHub users. However, any changes made by these parties have yet to be contributed back to the LibLime codebase.

The LibLime Academic Koha project follows a different model. Parties must make a financial commitment to become part of the consortium governing the development, at which point they also get access to the product. The code is necessarily GPL, but not distributed outside the consortium. This is similar to the community source model employed by the Sakai project in its early stages.

One could argue it’s not inherently bad for a project to fork, but there would be benefits if all versions of Koha drew f-rom the same codebase. While it’s certainly a healthy sign when an open source project is diversified and customised to individual requirements, this would ensure that the whole community benefited f-rom the shared development effort. Whe-re a party decides not to contribute their changes back for whatever reason, a shared codebase at least provides a known baseline for developers and for customers.

However, with codebases that have diverged as with Koha and LibLime Koha, there would need to be a considerable amount of effort to integrate the changes f-rom each into a single codebase, and agreement over which codebase this should be. While PTFS and companies in the Koha community all have employees paid to work on the code, they all have to meet demands of their customers, so there would need to be a clear business case for dedicating the time to make this happen.

There would need to be compromises on both sides to heal the rift. The issue that the community has drawn most attention to in recent years is PTFS’s pursual of the New Zealand trademark. This is viewed, particularly by HLT but also by other members of the international community, as an attack on the Koha project’s identity. Withdrawing the application would go a long way to healing the current rift. PTFS’s view is that since their acquisition of LibLime gives them copyright ownership over much of the Koha code, documentation, logos, and ownership of several Koha-releated websites, the community should acknowledge their position and right to use the Koha name.

Lessons

There are some key lessons that can be learned f-rom this story, both for open source projects and for companies engaging with existing projects.

The first is an issue of assets. Once a project is established, you may want to consider transferring ownership of assets to a non-profit foundation. There are a number of software foundations which exist for this purpose. Having your assets held in this way ensures that the buying and selling of companies doesn’t lead to transfer of your project’s IP.

You should work with the assumption (and indeed the intention) that commercial organisations will be interested in providing services around your product. Attracting companies to your product is a key path to sustainability, as it provides financial support for ongoing development.

It’s perfectly sensible that these companies will want to do things like registering trademarks that pertain to their brand offering. To avoid confusion, it’s wise to ensure the brand you wish to promote the project under is protected as widely as possible (e,g. by registering a trademark), and ensure there are clear guidelines governing its usage.

For a company to support your project, it will need to be able to provide a guaranteed service to customers. A predictable release cycle will help make this possible, as it allows a company to plan its services around a known schedule of releases.

If you do engage with an existing project, it always pays to approach the situation humbly. An established project will have a governance structure which the community have trust in. Work within the established structures, and once you’ve contributed to the project, you may be in a position to gain influence and use it to further your interests.

Ongoing conflict isn’t good for any parties concerned. Never turn down an opportunity to discuss an issue and seek a resolution. If two parties can’t agree on terms by themselves, it may help to seek mediation f-rom a third party who can broker a compromise.

When emotions around an issue run high, it can be hard to stand back and take an objective view of a situation. Whe-re there are past disagreements, personal apologies for comments published in anger may be a good place to start.

OSS Watch maintains a series of briefings and articles about project governance, sustainability and community engagement. If would like information and training on applying these to your project, please get in touch.

I’d like to thank Patrick Jones and Nicole Engard for taking the time to tell me the story of Koha. If you’d like to find out more, there is a reading list of news articles and blog posts about the project.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com