Koha:
a case study in open source project ownership
By Mark Johnson,
Published: 16 April 2013, Reviewed: 16 April 2013
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 Charlton, 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 Charlton đã 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 Charlton 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.
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.
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 from outside LibLime fell into rank
against PTFS, creating bad blood between both parties.
Galen
Charlton, 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 from 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 Charlton 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.
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 from the community
project. As Galen Charlton 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 from 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 from their point of view.
The
application for the New Zealand trademark has been provisionally
granted by IPONZ.
Individuals from the community opposed the grant, which now awaits a
final ruling.
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, where their
product is drawn from 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 from 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 from the shared
development effort. Where 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 from 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.
There
are some key lessons that can be learned from 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 from 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. Where 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
Thanks nguồn tài liệu này
Trả lờiXóa