Phần mềm dễ uốn nắn: Trao lại quyền kiểm soát cho người dùng trong thế giới ứng dụng bị khóa chặt

Trong thế giới vật lý, chúng ta có thể tùy chỉnh không gian sống và làm việc của mình một cách tự nhiên: dán một mẩu giấy ghi chú lên tường, sắp xếp lại ngăn kéo, hay xây dựng cả một xưởng mộc. Nhưng khi bước vào môi trường số, chúng ta dường như mất đi khả năng đó. Bài luận mới đây của Ink & Switch lập luận rằng phần mềm sản xuất hàng loạt đang ngày càng cứng nhắc, và đề xuất một tầm nhìn mới: phần mềm dễ uốn nắn (malleable software) — nơi bất kỳ ai cũng có thể điều chỉnh công cụ của mình theo nhu cầu với mức nỗ lực tối thiểu.

Khi môi trường số không còn uốn nắn được

Môi trường xung quanh chúng ta có vai trò quan trọng. Để làm việc tốt nhất và sống trọn vẹn nhất, chúng ta cần những không gian cho phép mỗi người phát huy tiềm năng riêng của mình.

Một người thợ làm đàn guitar sắp xếp xưởng của mình với cưa, búa, đục và giũa theo đúng ý họ. Họ cũng có thể tự chế tạo công cụ mới khi cần — một khối gỗ làm điểm tựa, hay một chiếc kìm được mài lại cho vừa tay. Một người nấu ăn tại gia dần dần tích lũy dao, thớt, nồi chảo, tìm ra những món phù hợp nhất với mình. Họ có thể gắn móc trên trần, di chuyển kệ để hỗ trợ quy trình nấu nướng.

Những điều này diễn ra hằng ngày trong thế giới vật lý, bởi vì thực tại vật lý vốn dễ uốn nắn. Nhiều thay đổi nhỏ — dán giấy ghi chú lên tường, sắp xếp lại ngăn kéo — có thể thực hiện tức thì mà không cần xin phép ai. Chúng ta cũng có thể thực hiện những thay đổi lớn hơn đòi hỏi nhiều công sức và kỹ năng, như xây xưởng hay cải tạo nhà bếp.

Khi làm việc và sống trong không gian vật lý do mình kiểm soát, chúng ta có xu hướng phát triển nó để phù hợp với nhu cầu. Stewart Brand viết trong cuốn How Buildings Learn: "Tuổi tác cộng với khả năng thích ứng là điều khiến một tòa nhà được yêu mến. Tòa nhà học từ người ở, và họ học từ nó."

Phần mềm sản xuất hàng loạt quá cứng nhắc

Ngày nay, chúng ta dành ngày càng nhiều thời gian trong môi trường được xây bằng mã lệnh thay vì vật chất. Chúng ta có thêm nhiều khả năng mới — cộng tác tức thì xuyên lục địa, tìm kiếm hàng nghìn tệp trong tích tắc. Nhưng chúng ta cũng đang đánh mất một điều quan trọng: khả năng điều chỉnh môi trường và biến nó thành của riêng mình.

Hãy lấy một ví dụ. Một thành viên của nhóm tác giả từng làm trong một đội phần mềm theo dõi công việc bằng thẻ ghi chú dán lên tường. Cả đội liên tục phát triển công cụ theo dõi này — đường kẻ di chuyển, danh sách kiểm tra xuất hiện, những vùng thẻ đặc biệt hình thành quanh lưới chính. Tính linh hoạt của công cụ thúc đẩy tính linh hoạt của quy trình.

Sau đó, đội chuyển sang một trình theo dõi vấn đề trên web để hỗ trợ cộng tác từ xa. Lúc này không còn cách nào mô hình hóa hay hiển thị vùng thẻ đặc biệt, nên đội bỏ luôn phần quy trình đó. Những thay đổi quy trình khác cũng đình trệ. Trước đây, ý tưởng mới chỉ mất vài phút để thử; giờ có thể mất hàng giờ vọc vạch cấu hình, nếu có thể làm được. Tin học hóa công việc dẫn đến mất quyền tự chủ.

Sự cứng nhắc của phần mềm không chỉ là bất tiện nhỏ. Nó có thể cản trở nghiêm trọng những người đang làm công việc quan trọng. Bác sĩ kiêm nhà văn Atul Gawande đã viết về cách tin học hóa trong ngành y đang dẫn đến mức kiệt sức kỷ lục. Trước đây bác sĩ có thể bỏ qua những trường không liên quan khi điền biểu mẫu giấy; giờ phần mềm buộc họ phải điền, và họ không có quyền sửa các quy tắc đó. Gawande kể về một bác sĩ: "Việc phải dành thêm thời gian không khiến cô ấy tức giận. Chính sự vô nghĩa của nó mới khiến cô ấy bực bội."

Sổ kế hoạch trên tường — công cụ linh hoạt cho quy trình linh hoạt

Khi gặp tình huống phần mềm không đáp ứng nhu cầu, bạn có thể thử góp ý cho nhà phát triển — nhưng thường không dẫn đến hành động tức thì. Khi người dùng khác nhau có nhu cầu khác nhau, một đội phát triển tập trung không thể giải quyết vấn đề của tất cả mọi người. Và khi một nhà phát triển cố nhồi nhét quá nhiều giải pháp vào một sản phẩm duy nhất, kết quả là một mớ hỗn độn phình to. Để tránh cái bẫy này, các đội sản phẩm giỏi học cách từ chối phần lớn yêu cầu người dùng, để lại một chuỗi dài nhu cầu ngách không được phục vụ.

Nghe có vẻ không thể tránh khỏi việc phần mềm không phục vụ được yêu cầu cụ thể của chúng ta — nhưng đó chỉ vì chúng ta đã mặc nhiên chấp nhận rằng phần mềm do các đội phát triển tập trung kiểm soát. Điều gì sẽ xảy ra nếu chúng ta chuyển nhiều quyền kiểm soát hơn vào tay những người dùng hiểu rõ nhu cầu của chính họ?

Gawande kể câu chuyện về một bác sĩ phẫu thuật thần kinh đã làm việc với một chuyên viên phân tích CNTT để điều chỉnh hệ thống hồ sơ y tế của khoa mình. "Chẳng bao lâu, họ xây dựng được một giao diện nhanh hơn, trực quan hơn, thiết kế riêng cho các buổi khám phẫu thuật thần kinh." Các yêu cầu được định hình bởi nhu cầu của khoa cụ thể đó, chứ không phải nhu cầu của mọi bác sĩ trên cả nước. Ngoài lợi ích năng suất trực tiếp, các bác sĩ cảm thấy kiểm soát công cụ của mình hơn — một liều thuốc giải cho sự kiệt sức.

Định nghĩa phần mềm dễ uốn nắn

Nhóm Ink & Switch hình dung một hệ sinh thái điện toán mới trao cho người dùng quyền tự chủ như những người đồng sáng tạo. Họ gọi ý tưởng này là phần mềm dễ uốn nắn — một hệ sinh thái phần mềm nơi bất kỳ ai cũng có thể điều chỉnh công cụ của mình theo nhu cầu với mức nỗ lực tối thiểu.

Cụm từ "hệ sinh thái phần mềm" ở đây chỉ toàn bộ môi trường kỹ thuật và văn hóa xung quanh phần mềm và người dùng của nó. Tính dễ uốn nắn không phải là một bài toán kỹ thuật hẹp.

"Bất kỳ ai" nghĩa là khả năng tiếp cận rộng rãi là mục tiêu. Và "điều chỉnh công cụ" bao gồm cả một loạt tùy biến, từ chỉnh sửa nhỏ phần mềm hiện có, đến cải tạo sâu, đến tạo công cụ mới phối hợp tốt với công cụ sẵn có. Việc điều chỉnh không có nghĩa là phải làm lại từ đầu.

Cuối cùng, "nỗ lực tối thiểu" là then chốt. Việc chỉnh sửa công cụ nên diễn ra nhanh chóng, nhẹ nhàng. Tốt nhất là có thể làm ngay tại thời điểm phát sinh nhu cầu, để rồi quay lại công việc đang dang dở.

Các cách tiếp cận hiện có và giới hạn của chúng

Bạn có thể thắc mắc: còn phần cài đặt (settings) hay plugin thì sao? Thực tế có nhiều kỹ thuật tùy biến phần mềm đáng được tán dương, nhưng chúng cũng có những giới hạn khiến chưa đạt được mục tiêu đề ra.

Cài đặt là cách phổ biến để thay đổi hành vi ứng dụng. Nếu có cài đặt phù hợp, bạn chỉ cần bật một ô chọn rồi tiếp tục công việc. Nhưng cài đặt chỉ cung cấp những điều khiển mà nhà phát triển đã nghĩ đến, khiến bạn bế tắc nếu không có cài đặt nào làm điều bạn muốn. Cài đặt cũng dễ biến thành danh sách dài những ô chọn rời rạc, thiếu mô hình tư duy mạch lạc.

Plugin cho phép bên thứ ba mở rộng hành vi ứng dụng. Một hệ thống plugin tốt giúp người dùng dễ dàng bắt đầu tùy biến bằng cách cài đặt plugin do người khác tạo. API plugin cũng có lợi ích then chốt là ổn định hợp đồng giữa ứng dụng nền và các phần mở rộng. Tuy nhiên, hệ thống plugin vẫn chỉ có thể chỉnh sửa hành vi ứng dụng theo những cách được phép cụ thể. Nếu không có bề mặt plugin cho một tùy biến nhất định, người dùng đành chịu. Và thực tế, hầu hết ứng dụng không có API plugin nào cả, vì thiết kế một cái tốt là công việc khó.

Modding không cần cấp phép là khi người dùng tự kiểm soát thông qua các bản mod. Ví dụ, tiện ích mở rộng trình duyệt có thể can thiệp vào giao diện trang web và thêm hành vi mới mà không cần nhà phát triển gốc mở hook. Các bản mod áp dụng được trong nhiều tình huống hơn API plugin chính thức — thậm chí ngay cả khi nhà phát triển gốc phản đối, như trường hợp trình chặn quảng cáo ưu tiên lợi ích người dùng. Nhưng mod cũng có giới hạn: đòi hỏi kỹ thuật đảo ngược tốn công, khó bảo trì khi ứng dụng nền phát triển, và các mod khác nhau trên cùng ứng dụng thường không phối hợp sạch sẽ.

Mã nguồn mở thúc đẩy việc phân phối mã nguồn để người dùng sở hữu phần mềm, đóng góp lại, và nếu cần thì tạo phiên bản riêng phù hợp hơn. Đây là lực lượng tích cực cho thế giới và là thành phần quan trọng của tính dễ uốn nắn. Nhưng có quyền sửa mã không đồng nghĩa với nỗ lực tối thiểu. Việc sửa một codebase mã nguồn mở nghiêm túc thường đòi hỏi chuyên môn và công sức đáng kể, ngay cả với thay đổi nhỏ như đổi màu nút.

Lập trình hỗ trợ bởi AI là chủ đề nóng hiện nay. Liệu công cụ AI có tự động biến phần mềm dễ uốn nắn thành hiện thực? Mô hình ngôn ngữ lớn mang đến cách tiếp cận mới: biến ý tưởng mơ hồ diễn đạt bằng ngôn ngữ tự nhiên thành mã lệnh tự động. Hiện có những ví dụ mới mỗi ngày, từ một nhà báo tạo ứng dụng gợi ý bữa trưa học đường, đến một sinh viên ngành môi trường tạo website theo dõi nỗ lực trồng rừng.

Tuy nhiên, chỉ sinh mã bằng AI không giải quyết hết mọi rào cản. Ngay cả giả sử mọi người dùng máy tính đều viết và sửa mã hoàn hảo, vẫn còn những câu hỏi lớn: Làm sao người dùng tinh chỉnh công cụ đã cài thay vì chỉ tạo ứng dụng mới biệt lập? Làm sao các công cụ do AI tạo kết hợp với nhau để xây dựng quy trình lớn hơn trên dữ liệu chung? Và làm sao cho người dùng kiểm soát trực tiếp, chính xác hơn việc tinh chỉnh phần mềm mà không cần dùng đến AI cho cả thay đổi nhỏ nhất?

Đưa công cụ lập trình AI vào hệ sinh thái phần mềm hiện nay giống như đưa một đầu bếp phụ tài năng đến khu ẩm thực. Nếu bạn quen mua bữa ăn theo thực đơn, một đầu bếp giỏi cũng khó giúp được gì. Tương tự, nếu bạn dùng phần mềm đóng từ cửa hàng ứng dụng, trợ lý lập trình AI cũng không giúp được nhiều. Để tận dụng đầy đủ khả năng của AI, chúng ta cần vượt qua khu ẩm thực để đến một nơi giống như căn bếp — nơi của sự sáng tạo mở.

Ba mô hình thiết kế cốt lõi

Dốc thoải từ người dùng đến người sáng tạo

Phần mềm dễ uốn nắn không có nghĩa là mọi người tự tạo công cụ từ đầu. Cách hợp lý hơn là bắt đầu dùng công cụ có sẵn do người khác hoặc công ty xây dựng, nhưng có tùy chọn sửa đổi khi phát hiện chúng không đáp ứng nhu cầu. Bạn có thể khởi đầu là người dùng thụ động, rồi dần trở thành người chỉnh sửa và người sáng tạo.

Trong bài báo năm 1990 User-Tailorable Systems: Pressing the Issues with Buttons, Allan MacLean và cộng sự tại EuroPARC đề xuất một mô hình tư duy mạnh mẽ cho việc thiết kế hệ thống mời gọi người dùng dần trở thành người sáng tạo. Hãy tưởng tượng một biểu đồ với trục hoành là độ mạnh của tùy biến, trục tung là mức kỹ năng cần thiết. Theo mô hình này, khi ai đó đột ngột phải học nhiều hơn để đạt cấp độ tùy biến tiếp theo, ta thấy một "vách đá" thẳng đứng.

Để làm phẳng các vách đá, MacLean và cộng sự đề xuất mục tiêu thiết kế: mỗi bước tăng nhỏ về sức mạnh tùy biến chỉ nên đòi hỏi một khoản đầu tư nhỏ về học hỏi và kỹ năng. Một hệ thống tuân theo quy tắc này có thể hình dung như có một "dốc thoải" không vách đá.

Nhiều môi trường thành công cho tính dễ uốn nắn của người dùng cuối áp dụng mô hình này. Bảng tính (spreadsheet) là ví dụ điển hình. Khi ai đó gửi bạn một bảng tính phức tạp, bạn có thể bắt đầu bằng việc xem, hoặc sửa một ô được đánh dấu là đầu vào. Tiếp theo bạn có thể đổi định dạng hoặc thêm nhãn. Khi dùng sâu hơn, bạn có thể chỉnh công thức hoặc thêm ô mới. Bảng tính khởi đầu như một "ứng dụng" — sản phẩm do người khác ghép lại với vài nút điều khiển — nhưng khác ứng dụng ở chỗ bạn có thể tiến dần đến những tùy biến sâu hơn một cách mượt mà.

Bảng tính cho thấy vài phẩm chất hữu ích để đạt dốc thoải. Thứ nhất, chúng có bộ công cụ tại chỗ: mọi người dùng bảng tính đều đang chạy trình soạn thảo đầy đủ. Khi muốn đi sâu vào sửa bảng tính, không cần cài hay mở môi trường phát triển riêng. Thứ hai, bảng tính thường có thẩm mỹ mộc mạc. Cảm giác an toàn hơn khi thay đổi một bảng tính, so với độ bóng bẩy hoàn hảo từng pixel của ứng dụng thiết kế chuyên nghiệp.

Bảng tính mang lại dốc thoải từ sử dụng đến tùy biến sâu

Một cách khác để đạt dốc thoải là qua các chế độ rõ ràng. HyperCard, chương trình Mac từ thập niên 1980 cho phép người dùng tạo các chồng "thẻ", cung cấp các "cấp độ" quy định hành động nào khả dụng. Cấp 1 là chỉ đọc; cấp 2 và 3 hỗ trợ chỉnh sửa văn bản và đồ họa với tương tác thao tác trực tiếp; cấp 4 thêm tạo nút và liên kết; cấp 5 mở khóa lập trình đầy đủ bằng ngôn ngữ kịch bản HyperTalk. Các chế độ rõ ràng này đóng vai trò lan can, cho phép người dùng khám phá an toàn mà không gây hậu quả ngoài ý muốn.

Công cụ, không phải ứng dụng

Cho đến nay chúng ta tập trung vào sự cứng nhắc của từng ứng dụng. Nhưng còn một lý do khác khiến khó điều chỉnh phần mềm: chính ý tưởng về "ứng dụng". Hãy xem một phép so sánh từ nhà bếp.

Một cách để cắt quả bơ là dùng "dụng cụ cắt bơ": thiết bị 3-trong-1 kết hợp dao nhựa cùn để cắt đôi, vòng tròn để lấy hạt, và hàng thanh nhựa tạo 7 lát cùng lúc. Ai cũng dùng được dụng cụ cắt bơ mà không cần luyện tập, lại không có rủi ro an toàn. Nhưng vì nó chỉ tập trung vào một việc, nó vô dụng cho mọi việc khác. Nếu dùng dụng cụ chuyên biệt cho mọi tác vụ, bạn sẽ có cả núi nhựa.

Cách khác là dùng con dao. Một con dao xử lý được mọi bước cắt quả bơ, và còn hơn thế: nó cắt được ức gà, thái hạt hành, hay đập tép tỏi. Bạn cần học cách dùng dao an toàn và khéo léo, nhưng đáng công vì dao là công cụ tổng quát.

Con dao tổng quát so với dụng cụ chuyên biệt — phép so sánh cho thiết kế phần mềm

Áp dụng phép so sánh này vào phần mềm: nhiều ứng dụng là "dụng cụ cắt bơ". Chúng là một gói chức năng nhắm vào một trường hợp sử dụng cụ thể: lên kế hoạch chuyến đi, theo dõi tập luyện, tổ chức công thức nấu ăn. Vì ứng dụng cần xử lý nhiều việc liên quan đến một trường hợp sử dụng, đôi khi nó không xử lý việc nào thật tốt. Bạn có thể từng gặp tình huống ứng dụng thiếu chức năng quan trọng với bạn, đồng thời chứa thêm phần bạn không cần. Hơn nữa, giải quyết một tác vụ lớn bằng nhiều ứng dụng thường đòi hỏi phối hợp thủ công — đặt cửa sổ cạnh nhau, sao chép dán dữ liệu, chứ không hơn.

Điều này không có nghĩa mô hình ứng dụng không có lợi ích. Người dùng có trải nghiệm mạch lạc trong khuôn khổ ứng dụng, vì nhà phát triển có thể tinh chỉnh mà không lo tương tác với công cụ khác. Việc cô lập dữ liệu theo ứng dụng là câu trả lời tiện lợi cho một số lo ngại về bảo mật và riêng tư. Trả tiền cho ứng dụng là mô hình tính phí hợp lý. Đây là những lợi ích quan trọng không thể bỏ qua.

Nhưng khi bạn cố giải một vấn đề phức tạp hoặc xây dựng quy trình sáng tạo trải khắp nhiều ứng dụng, sự cô lập gây vấn đề nghiêm trọng. Làm sao định hướng lại phần mềm quanh những công cụ tổng quát, có thể kết hợp hơn — cảm giác giống dao hơn là dụng cụ cắt bơ? Có hai vấn đề con cần giải quyết: chia sẻ dữ liệu giữa các công cụ, và kết hợp công cụ trong giao diện người dùng.

Trên các nền tảng đám mây và di động hiện đại, mỗi ứng dụng quản lý dữ liệu riêng trong silo riêng. Kế hoạch chuyến đi nằm rải rác giữa ứng dụng ghi chú, danh sách Google Maps, lịch. Sự phân mảnh này cản trở tính dễ uốn nắn. Khi dữ liệu được chia sẻ giữa các ứng dụng, nó trao quyền cho người dùng cuối kết hợp công cụ theo cách linh hoạt hơn. Một ví dụ nổi tiếng là hệ thống tệp trên desktop: khi thông tin lưu trong tệp, bạn có thể chỉnh cùng tệp bằng nhiều công cụ khác nhau.

Ý tưởng dữ liệu chia sẻ cũng mở rộng đến các đối tượng chia sẻ có hành vi. Trong Smalltalk, người dùng làm việc với một "image": kho chứa các đối tượng không chỉ đại diện trạng thái lưu trữ mà còn cả mã lệnh gắn với trạng thái đó. Cuối cùng, cộng tác thời gian thực trên dữ liệu chia sẻ cho phép nhiều người làm việc trực tiếp trong các công cụ khác nhau. Webstrates, một nền tảng phần mềm dễ uốn nắn cho cộng tác trên trình duyệt, là một ví dụ: hai người dùng có thể cùng chỉnh một bài nghiên cứu, một người dùng trình soạn WYSIWYG, người kia dùng giao diện văn bản thuần.

Sáng tạo cộng đồng

Dù thú vị khi hình dung mỗi người tự tạo trải nghiệm điện toán riêng, quan điểm cá nhân chủ nghĩa về phần mềm dễ uốn nắn chỉ đưa bạn đi được đến đâu đó. Chắc chắn cá nhân nên có thể điều chỉnh phần mềm theo nhu cầu theo những cách nhỏ trong khoảnh khắc. Nhưng khi thay đổi họ muốn ngày càng lớn, phần mềm sẽ đòi hỏi nhiều thời gian và kỹ năng hơn. Nếu ai cũng buộc phải tự làm những thay đổi này như việc riêng lẻ, lợi ích có lẽ không xứng với chi phí.

Và có lý do cơ bản hơn để nhìn tính dễ uốn nắn qua lăng kính cộng đồng: chúng ta dùng máy tính cùng nhau! Một đội sản phẩm cần một hệ thống theo dõi dự án duy nhất. Một khoa bệnh viện cần một hệ thống biểu mẫu tiếp nhận bệnh nhân duy nhất. Những cộng đồng này chắc chắn không được phục vụ tốt bởi ứng dụng một-cỡ-cho-tất-cả mà họ không kiểm soát được. Nhưng giải pháp cũng không thể là mỗi-người-tự-lo. Chúng ta nên giúp các cộng đồng xây dựng và duy trì giải pháp chia sẻ cho vấn đề của họ.

Với hạ tầng phù hợp, chúng ta có thể cùng nhau tạo phần mềm. Những người có nhu cầu tương tự trên khắp thế giới có thể trao đổi công việc và xây dựng cộng tác, như đã thấy trong các cộng đồng phần mềm tự do. Và các cộng đồng địa phương — từ công ty đến gia đình đến tổ chức dân sự — có thể xây dựng và duy trì phần mềm phù hợp nhu cầu địa phương.

Xây phần mềm cho bối cảnh "địa phương" đôi khi dễ hơn xây cho toàn cầu. Bạn không cần phần mềm cấp công nghiệp kín kẽ nếu tiếp xúc trực tiếp với người dùng và có thể phản hồi tình huống họ gặp. Bạn không cần lường trước nhu cầu của mọi người trong thiết kế, chỉ cần của cộng đồng mình. Clay Shirky gọi mô hình này là "phần mềm tình huống" (situated software), mô tả cách sinh viên của ông nhanh chóng xây phần mềm cho cộng đồng bằng cách "tận dụng hạ tầng xã hội hoặc thông tin nhạy cảm bối cảnh". Ở mức thân mật hơn, Robin Sloan mô tả sinh động cách một ứng dụng làm cho gia đình mình có thể là một "bữa ăn nấu tại nhà".

Các nguyên mẫu nghiên cứu của Ink & Switch

Tại Ink & Switch, nhóm đã dành nhiều năm xây dựng các nguyên mẫu nghiên cứu khám phá các khía cạnh khác nhau của phần mềm dễ uốn nắn. Đây không phải sản phẩm thương mại, mà mục tiêu của mỗi nguyên mẫu là phát triển hiểu biết về các kỹ thuật cho phép tính dễ uốn nắn, rồi học hỏi từ việc sử dụng sâu. Thực tế, bài luận này được viết trong một môi trường phần mềm dễ uốn nắn tự phát triển.

Công việc của họ trải khắp toàn bộ ngăn xếp điện toán, chia thành hai nhánh. Một nhánh khám phá hạ tầng nền tảng — kỹ thuật lưu trữ dữ liệu, tải mã lệnh, định nghĩa giao diện người dùng theo cách hỗ trợ trải nghiệm dễ uốn nắn xây trên đó. Nhánh còn lại tập trung vào một loại trải nghiệm người dùng cụ thể: tài liệu động nơi phương tiện tĩnh có thể được làm phong phú dần bằng hành vi tương tác.

Một trong những nguyên mẫu nổi bật là PushPin, một canvas phương tiện cộng tác trên web. Ý tưởng then chốt trong dự án này là "lập trình phản ứng chức năng dựa trên tài liệu" (DFRP): đại diện một công cụ như thành phần UI viết bằng React, được hậu thuẫn bởi tài liệu JSON tự động lưu trữ và đồng bộ qua Automerge. DFRP giúp việc mở rộng giao diện ít công hơn so với ứng dụng truyền thống, vì chỉ cần thêm thành phần UI mà không phải lo về cơ sở dữ liệu