Комментарии 27
А как обеспечить приватность этих самих открытых данных?
Прекрасный вопрос! Криптографией. Также как HTTP начинался с нешифрованных данных и пришёл к шифрованным данным передаваемым всё по тем же открытым каналам связи. Это, естественно, требует определённого дизайна и в данной статье пока что говорится о нижележащем протоколе (в моей аналогии — HTTP лежит в основе HTTPS)
Столлман давно уже в черном списке западной общественности.
Выперли его и из MTI, и из FSF, разве что астероид 9882 забыли переименовать.
Говорить он конечно может, но интересно кто-нибудь его слушает?
Например, я предоставляю данные о своих покупках на OpenAmazon сервису OpenNike.com и таким образом позволяю OpenNike.com кастомизировать мой опыт покупки обуви, основываясь на истории прошлых покупок обуви, которая доступна на OpenAmazon.
проблема то данных в том, что они легко копируются и не оставляют след. Как только вы дали доступ opennike к ним — ничто не мешает ему продавать ваши данные налево. И нет эффективных способов уличить его в этом.
Разница в том, что Открытые Данные не открыты, да?
Не вижу экономических стимулов для корпораций переходить на такую модель. Власть = деньги, в данном случае; предлагается поделиться "властью" (информацией), и, следовательно, потерять деньги.
Только некоммерческие организации, или государства, могут такое позволить, имхо.
Ну и технический вопрос: как мерж отрытых состояний будет делаться? Как будут конфликты разрешаться? Имхо, это нетривиальная задача, и возложить её на пользователя… ну такое.
Действительно, выбирая между тем, чтобы строить открытый протокол и продукт в открытой экосистеме, или закрытый протокол, второе чаще всего будет выгоднее экономически.
К счастью, многие технологические компании начинаются программистами / людьми с техническим прошлым, и утверждается, что часть культуры программистов — это создание открытых взаимодействующих друг с другом систем.
Соответственно задача не сделать разработку приложений с открытым состоянием выгоднее приложений с закрытым. Задача — сделать разработку приложений с открытым состоянием в принципе выгодной.
Что касается мержа открытых состояний — можно строить приложения так, чтобы этот мерж не происходил.
Можно представить себе две модели. В одной у пользователя есть два похожих приложения, каждое из которых имеет свое состояние, и в какой-то момент времени пользователь хочет состояния объединить (например, я использую Evernote и OneNote, и теперь хочу использовать одно).
Вторая модель — это что два похожих приложения построены поверх одной библиотеки с открытым состоянием, которая хранит данные. То есть оба приложения уже оперируют на общем состоянии (и ни одно приложение не имеет монополии над этим состоянием), и соответственно мержить ничего не надо, оба приложения могут менять состояние только через endpoints которые библиотека определяет, и эти endpoints всегда поддерживают состояние в консистентном состоянии.
этот водитель мог бы перенести свою репутацию в OpenLyft, OpenInstacart, OpenDoorDash и другие веб-сервисы
А кто гарантирует достоверность переносимых данных? Пока данные относятся к самому пользователю и влияют только на него — всё сравнительно просто, пользователь сам заинтересован в их достоверности (хотя и тут возможны манипуляции), но репутация и прочие данные которые будут использоваться кем-то ещё — это уже совсем другая тема.
Гораздо логичней иметь некое независимое хранилище данных (append only) со всей историей изменений, где будет накапливаться и репутация и всё остальное (что может быть публичным) — а сервисы обязаны будут использовать это хранилище как основу. Но и тут возникает проблема — если сервис окажется не совсем честным и добавит туда что-то недостоверное, а удалить уже не получится, да и не будет большинство во всей этой истории копаться и разбираться кто прав а кто виноват.
Мало что-то открыть и дать всем пользоваться — есть очень много проблем которые не решаются без чего-то что мы называет "регуляторами" и "властью", равно как и без подобия "законов" и "судов", но наличие любого из этих компонентов противоречит самой идее.
Пример базы данных, которую не поддерживает никакая корпорация / регулятор, в которой нельзя переписать данные — это блокчейн.
В идеальном варианте OpenUber и OpenLyft не реализуют свою систему рейтинга, вместо этого существует общий для всех таких сервисов контракт, на котором поддерживается рейтинг водителей. OpenUber и Open Lyft могут через конкретный end-point submitRating(driver_id, passenger_id, rating, service) (пока что не будем решать проблему анонимности, но она тоже решается) добавить рейтинг.
Более централизованный сервис может вызывать submitRating напрямую, на основе своих проприетарных алгоритмов, более открытый реализует назначение водителей поездкам на цепи тоже, и вызов submitRating будет разрешен только пассажиром назначенным водителю.
На блокчейне легко настраиваются права, и настроить чтобы только OpenUber мог засылать рейтинги с service = OpenUber, и только OpenLyft мог засылать рейтинги с service = OpenLyft делается тривиально.
Затем каждый сервис может аггрегировать рейтинги засланные сервисами, которым конкретный сервис доверяет. Никто не может менять рейтинги, удалять или добавлять, в обход протокола. Если OpenUber использует проприетарную логику для submitRating, OpenLyft может решить не доверять ему, и не использовать для своих рейтингов.
Точно так же и свобода произведений = право использовать + изменять + копировать + тиражировать.
Чего же тут прибавить?
Чтобы лишить свободную программу её свободы, вы должны сделать с нею то же, что со свободой слова или свободой веры. Достаточно запретить эту программу.
Думая о других людях, мы приходим к выводу, что свобода должна быть объективной, не управляемой одним только человеком, не зависящей только от одного человека.
Человек может посадить в клетку себя, но не другого человека. Также можно сделать несвободной свою программу, но не чужую.
Ричард Столлман и будущее инноваций в ПО