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.
Đừng giả vờ rằng UX tệ là “ổn vì nó miễn phí”.
Các dự án mã nguồn mở thường được hỗ trợ bởi các 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.
Một phần của vấn đề là, 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ự hướng dẫn thống nhất, và rất nhiều người đang làm việc trên các phần nhỏ của vấn đề lớn mà không có cái nhìn tổng thể. Nếu thậm chí có một cái nhìn tổng thể. 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ĩ rằng 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 công sức tốt đẹp đã bỏ ra sẽ trở nên vô ích.
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ó chỉ đơn giản là thiếu sót.
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—thì đ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 và một ứng dụng mã nguồn mở đang 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.
Lý lẽ “hoan nghênh 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 thứ 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 được cho biết 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ở (FOSS) 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 người dùng 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, tôi tự hỏi các bản vá lỗi sẽ còn được chào đón trong bao lâu nữa.
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 FOSS nhận được sự hậu thuẫn 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à đã sử 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 từ xa và rằng phần mềm này, mặc 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ó đáp ứng được hay 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 tính năng và khả năng sử dụng tốt hơn. Điều này giúp nó tương đồ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ở như thế này, nhưng điều đó cho thấy những vấn đề ít hấp dẫn hơn thường bị bỏ qua trong một số dự án phần mềm mở nếu không có sự quản lý rõ ràng.
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 hoặc 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ữ 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, hoặc để học hỏi, hoặc 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 phần mềm mã nguồn mở, thì việc đặt ra cùng tiêu chuẩn cho những đóng góp đó như đối với phần mềm mà bạn đang cạnh tranh là điều cần thiết và chính đáng. Có lẽ 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ọ là điều có lợi cho một dự án phần mềm mã nguồn mở.