По ходу работы приходилось несколько раз подписывать OEM соглашения, пару раз даже чуть сами не стали чужой софт распространять по OEM соглашению. Всегда суть этих договоров была такой: OEM партнер платит заранее большие деньги, за что получает скидку на последующие покупки нашего продукта и фиксированную цену (как вариант - можно увеличивать не больше чем на X процентов в год). Чем больше денег партнер платит при заключении договора - тем больше скидка.
Но сегодня у одной известной компании обнаружил довольно странное OEM-соглашение, причем размеры/известность компании не позволяют подозревать их в неадекватности.
Условия:

• первоначального фиксированного платежа нет, партнер должен просто сразу купить X OEM-лицензий.

• скидок на приобретаемые продукты нет. Наоборот, OEM партнеру они достаются в 2 раза дороже максимальной цены. Т.е. если для обычного пользователя самая дорогая версия продукта стоит 5 тысяч, то OEM партнер сможет купить ее для перепродажи минимум за 10.

• если партнер продает свой продукт дороже какой-то фиксированной цены (скажем, дороже 30 тысяч), то вендор начинает хотеть половину. Т.е. если продукт ценой в 5 тысяч партнер включил в свой продукт и продал его за 50 тысяч, то он должен даже не 10 тысяч (цена*2), а 25.

• саппортом конечных пользователей OEM-партнер занимается сам, минорные апгреды - бесплатно.
  

• никаких гарантий цен нет, т.е. соглашение заключается на год, а через год цены могут стать другими.

В чем смысл этой бизнес-модели ? Какого рода компания может быть этим OEM-партнером ?

Хочу вывесить на trackstudio.ru список наиболее крупных клиентов - их с 2001 года накопилось уже довольно много, среди них много очень известных компаний, особенно иностранных. Но до прошлого года в договоре/лицензионном соглашении пункта о возможности публикации названия компании-клиента не было, это  просто никак не оговаривалось.

Посему вопрос: есть ли какие-то общепринятые правила по этому поводу или вопрос нужно согласовывать с каждым клиентом отдельно ?

У нас частенько спрашивают, почему у нас нет Live Demo, иногда даже указывают на отсутствие Live Demo как на недостаток TrackStudio. Тогда почему нет и, может быть, стоит сделать? Скажу сразу, технических проблем с Live Demo нет - ведь мы начинали как hosted issue tracker, так что live demo у нас появилась даже на год раньше первой "скачиваемой" версии.

Обычно компании делают Live Demo чтобы клиенты могли быстро ознакомиться с продуктом и решить, нужно ли его скачивать/инсталлировать. При этом в некоторых компаниях (fogbugz, rmtrack) каждому демо-пользователю заводится отдельный экземпляр системы и его можно полностью администрировать, а в других (Atlassian Jira) пользователь может лишь "поиграться" с общим экземпляром с точки зрения обычного пользователя - чтоб ничего не испортил :-)

Оба варианта плохие:

• в первом случае мы имеем большие проблемы с нагрузкой на сервера и администрированием. Легко подсчитать, что даже если каждый день на live demo регистрируется 30 человек (реально - значительно больше) и учетные записи действительны в течение 45 дней (как у FogBugz), то через 45 дней у нас будет 45*30=1350 экземпляров системы и столько же экземпляров БД. Как с этим справляются разработчики этих систем - понятия не имею, но мне идея держать одновременно 1000+ экземпляров системы в памяти, бекапить и апгрейдить их кажется довольно сложной задачей.

• во втором случае для разработчиков все сильно упрощается, но пользователи не могут почти ничего, как-то поменять "свою" конфигурацию нельзя.

Если взять hosted-багтрекеры - там ситуация аналогичная: либо для каждой компании отдельный экземпляр со всеми возможностями конфигурирования за большие деньги (ведь масштабируется этот подход плохо), либо большое количество пользователей делят один и тот же экземпляр и конфигурацию задешево. Когда мы начинали писать TrackStudio, то именно на эту проблему и нацелились: мы хотели создать систему, в единственном экземпляре которой тысячи команд разработчиков из разных компаний могли бы работать независимо, при этом все должно было работать на одном сервере, а с администрированием такой системы должен был справиться один человек на part time :-) Тогда (2001 год) эта идея "не пошла" по разным причинам, но продукт остался и разделился на TrackStudio Host и  "скачиваемый" TrackStudio Enterprise.

Как оказалось, для многих компаний проблема специфического конфигурирования багтрекера под каждую внутреннюю команду или крупного внешнего клиента весьма актуальна. Ведь обычно как бывает: разработчики багтрекера пишут, что поддерживают конфигурируемые категории/процессы. При этом отконфигурировать-то можно, но если в таком проекте нужна одна конфигурация, а в этом - другая, то нельзя. Многие поддерживают настраиваемые группы пользователей, но добавить еще одну группу пользователей именно для данного конкретного клиента - уже нельзя. Многие поддерживают настраиваемые шаблоны e-mail оповещений, но посылать разные уведомления разработчикам, менеджерам и клиентам опять нельзя.

Чтобы получить примерный список, что пользователи хотят настраивать для каждого проекта, пользователя или баги,  наберите в jira.atlassian.com в строке поиска фразы типы "per project" (204 баги), "per user" (87 багов) или "per issue" (86 багов). Задним числом исправлять эти проблемы для разработчиков багтрекеров весьма сложно (см переписку по JRA-1602), а для пользователей -  практически невозможно (даже при наличии плагинов и исходников). В такой ситуации пользователи обычно плодят экземпляры системы с индивидуальными конфигурациями, становятся важными клиентами и сурово мучаются с администрированием. Ситуация до смешного доходила - разработчики Seapine TestTrack в white paper гордились одним своим крупным клиентом, который на 200 пользователей и 20 проектов завел 60(!) экземпляров TestTrack.

В общем дело кончилось тем, что мы эту проблему решили, но TrackStudio стала не "просто багтрекером", а чем-то вроде виртуальной машины для багтрекеров (аналогично vmware или даже virtuozzo для операционных систем) - в рамках TrackStudio множество команд могут гонять самые разные процессы, при этом настройки конкретного процесса - это просто настройки, они не так интересны, и это не самое главное. Но как сделать Live Demo такой системы ?

• можно сделать простую и понятную конфигурацию TrackStudio и давать доступ в Live Demo к ней с точки зрения админа. Собственно, в таком виде у нас Live Demo и существовала длительное время, но у пользователей было массовое непонимание относительно возможностей и ограничений такой Live Demo по сравнению с полной версией. В итоге нам надоело отвечать на вопросы типа "а в полной версии можно будет поменять имя корневого проекта?", "а почему номера задач такие большие ?", "а я пользователя с логином john создать не могу, хотя в системе такого нету".

• можно сделать простую конфигурацию и давать к ней доступ в режиме пользователя, но работа в таком режиме не демонстрирует практически ничего.

• можно все объяснять и предлагать пустую конфигурацию, но тратить время на настройку удаленного экземпляра не имеет смысла, гораздо быстрее скачать и настроить свой.

Что бы вы стали показывать в live demo vmware, если бы такая была ? У меня хороших идей нет:

• если просто доступ к одной из виртуальных windows - это никому не интересно, обычная операционка со странными драйверами - что там смотреть ?

• если доступ к админскому интерфейсу, то проще скачать триал локально, чем ставить windows по internet-у через этот админский интерфейс.

И, самое главное: чтобы потенциальный клиент стал настоящим клиентом, он все равно должен будет скачать TrackStudio и настроить ее локально. Чем меньше времени у клиента уйдет на игры с live demo - тем быстрее он получит работающую систему. Зачем ему мешать ?