Làm ơn đừng hạ thấp tiêu chuẩn của bạn đối với phần mềm mã nguồn mở nữa

[T-X]

Chỉ vì nó "miễn phí" không có nghĩa là bạn được phép làm bất cứ điều gì mình muốn.

Tôi yêu thích phần mềm mã nguồn mở, và nó đã rất cần thiết cho nhu cầu của tôi trong nhiều năm qua. Tôi đã sử dụng GIMP khi không đủ tiền mua Photoshop, Scribus khi cần thiết kế sách cho đại học, và OpenOffice cho chiếc netbook chạy Linux giúp tôi hoàn thành chương trình sau đại học. Tôi mang ơn phần mềm mã nguồn mở rất nhiều, và nó quá quan trọng để có thể đánh giá thấp hơn so với các phần mềm mã nguồn đóng thương mại.

Có thể bạn cho rằng điều đó không công bằng, vì chúng ta thường có ấn tượng rằng tất cả phần mềm mã nguồn mở đều được tạo ra bởi những người đam mê đơn độc trong phòng ngủ của họ. Ở một mức độ nào đó, điều này đúng, và đó cũng là một phần lý do tôi cố gắng quyên góp cho các dự án FOSS. Tuy nhiên, các dự án mã nguồn mở lớn với hàng triệu người dùng không còn chỉ là những dự án vui vẻ trong phòng ngủ nữa, điều đó có nghĩa là chúng cần phải hoạt động tốt như phần mềm mã nguồn đóng mà chúng hướng đến việc thay thế.

1. Đừng giả vờ rằng trải nghiệm người dùng tệ hại là "ổn vì nó miễn phí"

Các dự án mã nguồn mở thường được hỗ trợ bởi những lập trình viên tài năng, nhưng tôi đoán các chuyên gia UX tài năng không thích làm việc miễn phí (hoặc nhận quyên góp), bởi vì so với phần mềm mã nguồn đóng thương mại, giao diện của phần mềm mã nguồn mở thường rất sơ sài và đôi khi hầu như không hoạt động được.

Một phần vấn đề nằm ở chỗ, trong một số trường hợp, giao diện và trải nghiệm người dùng của phần mềm này không phải là kết quả của sự chỉ đạo thống nhất, và rất nhiều người đang làm việc trên những phần nhỏ của bức tranh tổng thể mà không có cái nhìn toàn cảnh. Thậm chí có khi không có bức tranh tổng thể nào cả. Một số công cụ khó sử dụng, khó tìm, menu thiếu logic, và để thành thạo, bạn chỉ cần học tất cả những điểm kỳ lạ của ứng dụng.

Tôi nghĩ việc chỉ trích các vấn đề về khả năng sử dụng trong phần mềm mã nguồn mở là điều bình thường, và nếu bạn là người ủng hộ nó và muốn nhiều người sử dụng phần mềm mã nguồn mở hơn, thì nó phải dễ sử dụng. Nếu không, tất cả những nỗ lực tuyệt vời đã được đầu tư vào phần mềm sẽ trở nên vô ích.

2. Không phải mọi tính năng bị thiếu đều là "quan điểm triết học"—đôi khi đơn giản chỉ là thiếu sót mà thôi

Có sự khác biệt giữa việc cố tình giới hạn phạm vi và phần mềm chưa hoàn thiện. Nếu phần mềm mã nguồn mở của bạn được phát hành dưới dạng bản beta, hoặc có lộ trình phát triển tính năng và hình dung rõ ràng về những gì sắp ra mắt – điều đó rõ ràng là ổn. Đôi khi, đó thực sự là trường hợp một đối thủ cạnh tranh thương mại có quá nhiều tính năng thừa thãi và một ứng dụng mã nguồn mở lại cắt giảm những tính năng không cần thiết, nhưng việc sử dụng các tính năng bị thiếu như một loại "bộ lọc kỹ năng" thì theo tôi là không ổn.

3. Việc chỉ trích bằng cách "chấp nhận các bản vá lỗi" đang giết chết những lời phê bình mang tính xây dựng

Trong thế giới phát triển mã nguồn mở có một khái niệm gọi là "văn hóa hoan nghênh vá lỗi", về cơ bản có nghĩa là khi ai đó báo cáo lỗi hoặc yêu cầu tính năng, bạn sẽ được thông báo rằng các bản vá lỗi đều được hoan nghênh. Nói cách khác, bạn có thể tự sửa lỗi hoặc tự viết mã cho tính năng đó. Không biết lập trình? Vậy thì đừng đưa ra yêu cầu.

Rõ ràng là có những vấn đề với điều này, bởi vì người dùng ứng dụng là nguồn thông tin quý giá cho các nhà phát triển. Nhưng một số nhà sáng tạo phần mềm mã nguồn mở dường như coi đây là cộng đồng "dành cho lập trình viên, do lập trình viên tạo ra". Bản thân điều đó không phải là vấn đề, nhưng nếu bạn muốn phần mềm của mình được người dùng phổ thông sử dụng, hoặc cạnh tranh với một số ứng dụng thương mại, thì bạn không thể coi thường họ theo cách này.

Điều buồn cười là, trong thời đại " lập trình cảm xúc " bằng trí tuệ nhân tạo đang lên như diều gặp gió, tôi tự hỏi các bản vá lỗi sẽ còn được chào đón đến bao giờ.

4. Các dự án được các tập đoàn hậu thuẫn cho thấy tiêu chuẩn đã xuống thấp đến mức nào

Đôi khi phần mềm mã nguồn mở (FOSS) nhận được sự hỗ trợ và nguồn lực từ các tập đoàn, dù có hay không có vụ thâu tóm gây tranh cãi. Lấy Audacity làm ví dụ. Tôi rất thích trình chỉnh sửa âm thanh này và đã dùng nó để thu âm bản demo đầu tiên của ban nhạc mình khi còn là thiếu niên, nhưng khi Audacity được Muse Group mua lại vào năm 2021, đã có những lo ngại về việc thu thập dữ liệu người dùng và rằng phần mềm này, dù vẫn là FOSS, giờ đây thực chất là phần mềm gián điệp. Tôi không thể bình luận về mức độ chính xác của điều đó hay liệu phiên bản Audacity hiện tại có như vậy không, nhưng không thể phủ nhận sự gia tăng các bản cập nhật tập trung vào các tính năng và khả năng sử dụng tốt hơn, đưa nó ngang hàng với các phần mềm DAW hiện đại mã nguồn đóng.

Tôi chắc chắn không ủng hộ kiểu thâu tóm và thương mại hóa các dự án phần mềm mã nguồn mở này, nhưng điều đó cho thấy những vấn đề ít được quan tâm hơn thường bị bỏ qua trong một số dự án phần mềm mã nguồn mở do thiếu sự quản lý rõ ràng.

5. Phần mềm mã nguồn mở phát triển mạnh khi nó đòi hỏi sự xuất sắc

Tôi phải nhắc lại rằng tôi không nghĩ rằng người tạo ra một tiện ích hữu ích và phát hành nó miễn phí, mà lại không có thời gian, tiền bạc hay mong muốn duy trì nó, nên bị chỉ trích dưới bất kỳ hình thức nào nếu phần mềm của họ có một vài lỗi nhỏ. Những người này nên được tôn vinh. Tuy nhiên, khi phần mềm của bạn bắt đầu cạnh tranh nghiêm túc với các công ty trị giá hàng tỷ đô la, và mọi người bắt đầu phụ thuộc vào chúng, bạn không thể cứ giữ mãi tư duy của một lập trình viên nghiệp dư.

Ngay cả khi bạn làm điều gì đó vì sở thích, vì kiến thức cá nhân, hay vì bất kỳ lý do nào khác mà mọi người đóng góp mã nguồn cho các dự án FOSS, việc đánh giá những đóng góp đó theo cùng một tiêu chuẩn với phần mềm cạnh tranh là điều cần thiết và chính đáng. Quan trọng hơn, việc đối xử với người dùng như những khách hàng trả tiền và ngừng coi thường phản hồi của họ sẽ mang lại lợi ích cho dự án FOSS.