Давайте подумаем о том, для каких сайтов или соцсетей было бы полезно организовать кросс-публикацию своих (или размножение чужих, строго в рамках приличия, конечно) статей. Кросс-публикация — это генерация исходного образца статьи в форматах, подходящих для публикации на двух или нескольких не связанных между собой ресурсах.

Это востребовано довольно часто по разным причинам: защита публикации от недоступности к прочтению на одном-двух ресурсах (из-за поломки сервера, бана администрацией или периода модерации), для повышения популярности своей публикации за счёт массовости (спама, но, конечно, добросовестно-дилетантского; о недобросовестном — чуть ниже), для экономии времени публикации, для сбора своих статей на каком-либо одном авторском ресурсе. Большой плюс будет и в том, что базу исходных образцов статей легко будет хранить в виде архива в копиях и восстановить при необходимости прочтения или повторных публикаций, даже если исчезли все другие прежние копии.

Несомненно, это нужно для каждого ресурса вообще, но никто (или почти никто) этим не «заморачивается», потому что чаще всего вопрос решается методом «как вывезет» — или автор хранит тексты статей в архиве, или надеется на проверенную надёжность места публикации (сайт, не предвещающий годами своего краха, Google Wave или что-нибудь попроще и малоизвестнее). Часто и сами статьи теряют актуальность. В любом случае, текстов в любом оформлении и картинок к ним в архиве бывает достаточно, чтобы вопросом дублирования публикаций не задаваться.

Как насчёт недобросовестного спама? Можно гарантировать, что у спамеров такие системы уже есть, но «заточены» не на популярные сайты со строгой модерацией, а на форумы, соцсети и почтовые рассылки. Поэтому об их благе можно не беспокоиться: ). Для остальных же авторов нужна возможность опубликоваться в 1-3 местах или чуть больше, при этом строго соблюдая правила и очерёдность публикаций, как требуют администрации ресурсов. Кроме того, коммерческие системы любого типа можно найти поиском по "размещение статей, article publishing".

Когда таких мест становится больше одного, а инструментов автоматического форматирования нет, система публикации автора сводится к простейшей и малозатратной — тексты в архиве или просто на диске одного из компьютеров.

Но рано или поздно, такой хаос начнёт самоорганизовываться и такая система появится, которая, как снежный ком (как Yeoman), будет набирать и поддерживать десятки и сотни шаблонов публикаций. В отличие от инструментов скаффолдинга, здесь преследуются 2 другие цели:

1) создать метаязык, подходящий для максимального охвата мест публикаций, или несколько вариантов сложности такого языка (скорее всего, на базе Markdown + HTML);
2) поддерживать публикацию на ресурсах с максимальным охватом особенностей конкретного ресурса, чтобы дополнительных действий был минимум (за счёт спецификации всех сайтозависимых особенностей в общем формате наподобие XML: <title site=«facebook»>Особое название статьи</title>).

Поддерживать нужно не только формат текста статьи, но и сопутствующие поля: заголовок, теги, что-либо специфическое (час публикации). Формат образца будет выглядеть как текст или как XML/JSON/INI с описанием полей, например:

<автор>Пупкинд Василий<автор>
<название>Моя первая супер-статья в системе публикаций</название>
<текст>Сидел я как-то в интернете...
</текст>
<теги><тег>примеры статей</тег><тег>система публикаций</тег></теги>

Системы подготовки проектов отличаются тем, что они создают начальные шаблоны для дальнейшей доработки их под нужды конкретного проекта. Они более похожи на шаблоны тех же спаммерских писем или низкосортных сеошных текстов, задача которых — начать строить нечто. У системы публикации статей задача — завершить оформление уже написанной статьи.

Технически публикация выглядит так, что в веб-интерфейсе нужно заполнить несколько (или много) полей и отправить созданное. Или, может быть, где-то сформировать письмо в определённом формате. Для публикаций через веб необходимо будет иметь актуальные шаблоны правил переформатирования образца статьи и заполнения полей, которые может выполнить скрипт на странице публикации.

Правила публикаторами меняются. Где-то есть капча, где-то — неоднозначности или недостаточность данных. Поэтому второе, что нужно — показать автору инструкцию с шагами для завершения публикации (мастер публикации). Скрипты для инструкций могут поддерживать в актуальном состоянии активные и авторитетные пользователи данного ресурса. Поэтому, сотни мест публикаций не означает, что за их исправностью будет следить один человек или команда. Поддержка каждого ресурса — силами энтузиастов, которые сами бы извлекали из этого пользу в быстрой публикации своих статей.

Теоретически, в скрипты публикации эти специалисты могут вставить спам-ссылки или шуточные тексты, поэтому их репутация имеет значение, а система публикации не может быть единым репозиторием для ряда ресурсов. В репозитории может находиться ядро системы и несколько общепризнанных мест публикации, за качество которых могла бы отвечать команда разработчиков ядра. Остальные сотни ресурсов подключаются к нему как «плагины», и не все сразу, а ровно те, которые нужны автору публикаций и качеству которых он мог бы доверять.

Этот момент, видимо, и создаёт препятсятвия для создания системы публикаций. Без системы автор сам отвечает за набранные тексты и их отправку. Но платит знанием правил публикации, вида тегов и багов движка. (Как, например, у Хабра, для тега H3, чтобы он смотрелся вертикально симметрично, нужно иметь одну пустую строку выше и 0 пустых строк ниже тега. И не меняют ничего годами, чтобы ничего не сломать :).)

Тем не менее, ведь можно начать, выбрав 2-5 постоянных ресурсов для публикации. За первые 2 могут сойти (с учётом специфики авторов) Github.io и Habr (или сателлиты).

Ресурсы в круге поддержки

Следующий вопрос — какие ещё ресурсы можно включить в этот круг избранных? Несложно обеспечить поддержку соцсетей (G+, ВК), но, наверное, мало кто в этом заинтересован из местных авторов. Может быть, LJ. В нём есть особенность — много возможных шаблонов публикации, поддерживать надо целую группу их. Есть технические сайты (ixbt, 3DNews), есть ряд сайтов с ограниченным числом авторов — в 3DNews авторов просто так не пускают, но пользователи часто могут публиковать хорошо оформленные статьи на форумах.

Если посмотреть на авторов другой тематики — публицистика, политика, психология (кулинария, дом, строительство, хобби), то им, как раз, такая система была бы полезна (часто одни сайты не разрешают публиковать то, что разрешено на других), но вопрос в том, много ли таких авторов освоит систему с образцом статьи и мастерами публикации? Они — вероятно, второй эшелон пользователей, которые пойдут в систему, когда её простота будет отработана.

Поэтому, для отработки системы стоит ограничиться вначале 2-5 сайтами и думать о «плагинах» для подключения других.

Вопросы читателям-авторам

1. Что, кроме Github.io (и соцсетей), вы бы предложили для ведения базы статей для произвольного автора? Какой ресурс предоставляет дружественный хостинг для публикации чего угодно с, возможно, шаблонами статей?

2. В каком порядке предпочтений идут сайты для повторных публикаций (habr не рассматриваем)? Например, G+, BK, OK, FB, LJ, liveinternet, slashdot, reddit, twitter?

Опрос ниже ни к чему не обязывает, но позволит выявить относительную популярность других ресурсов среди читателей статьи (по особенностям многих из них я сам не в курсе и доступ на запись, например, имею только к одному или двум; поддерживать публикацию в них могли бы совсем другие, заинтересованные люди). (Обновлять список не смогу, т.к. это будет приводить к сбросу голосов каждый раз.)