Блог им. SPU → Почему рядовые компании-разработчики не любят использовать Open Source.
После одного случая, о котором я расскажу ниже, у меня возник вопрос: каким образом можно повысить интерес небольших и средних компаний, занимающихся разработкой софта, к Open Source проектам? Под «интересом» я понимаю хотя бы использование продуктов Open Source в собственных разработках компаний, пусть даже в первозданном виде без модификаций.
Разумеется, гиганты вроде Google могут позволить себе доработку/разработку Open Source проектов для своих нужд, а что делать обычным компаниям?
Начну, собственно, с самой истории, которую постараюсь изложить максимально абстрактно, т.к. подробности истории являются коммерческой тайной и разглашать ее я не могу. В любом случае, думаю, что многие сталкивались с похожими ситуациями.
Итак:
1. Имеется небольшая группа достаточно квалифицированных программистов;
2. Имеется задача, которая очень хорошо знакома этим самым программистам, но требуется реализовать ее средствами, совершенно отличными от использовавшихся ранее (переход на кроссплатформенность, независимость от используемой СУБД и т.д.);
3. Стоит требование максимального удешевления конечной стоимости продукта для потребителя.
Естественно, решения о использовании тех или иных инструментов принимает начальство. Исходя из пункта 3, начальство сразу выбирает GNU/Linux или свободный *nix, Java с разными примочками (GlassFish и прочее) и открытую СУБД, т.е. клиент компании в идеале должен будет оплатить только стоимость серверов и самого разработанного софта.
Заказали сервера под разработки и тестирование проекта, начали выбирать ОС…
Тут вылезли первые грабли: компания не хочет сама отвечать за работу ОС (что потребовалось бы для большинства GNU/Linux и *nix), поэтому выбор сузился до RedHat и AltLinux, которые имеют коммерческую поддержку и гарантии. Для бизнеса решение весьма логичное, т.к. зачем иметь лишний геморрой, если можно заплатить немного денег (читай, содрать их с клиента) и свалить большинство проблем на третьих лиц.
В итоге с RedHat решили не связываться (из-за бОльшей удаленности) и остановились на отечественном производителе… о чем многие (кроме начальства) несколько пожалели, т.к. AltLinux на сервера устанавливался ужасно криво.
Разобрались с ОС, развернули кластер GlassFish, задумались о выборе СУБД…
Задача требовала хранение и обработки больших объемов данных, поэтому от MySQL решили отказаться сразу. В итоге, естественно, остановили свой выбор на PostgreSQL. Не знаю почему, но в данном случае начальство почему-то не озаботилось наличием коммерческой поддержки СУБД. В любом случае система должна была работать, как минимум, еще с MS SQL и, желательно, Oracle, т.е. имелось в виду, что у клиента могла быть уже куплена какая-то коммерческая СУБД и ему нет смысла разворачивать и поддерживать еще что-то.
Началась разработка… по началу все шло хорошо: на Java понаделали веб-сервисов и прочих веселых штук, предусмотрели независимость от СУБД. Вскоре последовал этап тестирования первых наработок…
То, что при проектировании казалось гибкостью и масштабируемостью превратилось в тормоза, но главное заключалось в том, что PostgreSQL начинал жутко тупить и даже падать, когда количество строк в таблице начинало превышать несколько миллионов (а требовались миллиарды), хотя по первоначальному замыслу от СУБД ничего сверхъестественного не требовалось: хранение данных, обеспечение их целостности и не очень сложные выборки, т.е. хватило бы и функционала MySQL 4.x. Однако PostgreSQL тупил даже на таблицах, в которые только писали и никаких выборок не делали вообще.
Дальнейшие приключения я опущу, но в итоге была выкинута PostgreSQL и заменена на MS SQL, был выкинут GlassFish и все веб-сервисы… от системы остались только несколько программ на Java, а вся логика была перенесена внутрь БД. Причем после такой переработки для полноценного функционирования системы хватает одной-двух средненьких машинки без всякого кластера. Зато стоить они будут вместе с серверной виндой и MS SQL ой сколько…
==========================================================
После этой «поучительной» :) истории возникает вопрос: что же дает Open Source для коммерческих разработок? В описанном выше случае дал только убытки.
Некоторые представители сообщества Open Source считают, что компании, желающие только использовать открытые наработки и ничего не давать взамен, нужно гнать поганой метлой… Можно было бы и согласиться с такой точкой зрения, но вот только где рядовой компании взять столько денег на грамотных специалистов, способных допилить напильником этот замечательный Open Source? (ну или хотя бы использовать его в первозданном виде, но чтобы он выполнял то, что ему положено).
В итоге получается, что развитие Open Source &mdash это не для всех и каждого, а только для одиночек специалистов/любителей и гигантов «софтостроения». Остальным же «намекают», что лучше использовать коммерческие решения, которым Open Source вроде как пытается составить конкуренцию. Заколдованный круг какой-то…
А что думают по этому поводу представители Open Source? Как выходить из данной ситуации?
P.S. Не знаю, в какой блог определить эту заметку, поэтому пока оставляю в персональном.
- +11
- SPU
- 06 июня 2009, 20:03
Ошибки 100% были. Я изначально предлагал совершенно другую архитектуру, которая была бы максимально масштабируема и более производительна, но, к сожалению, куда более сложна в реализации (хотя усложнять ее можно было бы и поэтапно). Но я не начальник, поэтому с моим мнением никто особо считаться не будет, тем более, что сроки установлены еще более высокими начальниками.
Что касается СУБД, то можно посмотреть
для ногтей, только потому что она у вас есть и выглядит красивее чем
бензопила, которой у вас нет? То же самое и с программами. Ни одному
профессионалу не придёт в голову использовать для вэб-сервера Windows +
IIS. Скорее всего там будет какой-то UNIX и Apache. И самое интересное,
что стоить это будет во много раз дешевле, потому что эти программы
распространяться бесплатно.
С теми же майкрософтовскими решениями все гораздо проще: клиент покупает лицензии, ему все устанавливается, настраивается, а дальше компания отвечает только за работу именно своего продукта, а не за все подряд. Дело не в том, что компания будет все валить на третьих лиц, она всегда готова помочь и разобраться, но в случае каких-то конкретных наездов часть проблем (если не все) можно спихнуть на производителя.
Тут дело даже не в open source. Хотели решение независимое от БД -> получили решение исключительно на windows и зависимое от БД.
Тут возникает куча вопросов. А сколько стоит ваша разработка, те есть ли смысл его покупать, если в довесок придется купить windows server + ms sql. А если есть уже купленная Oracle да еще и на unix стоит? Что теперь покупать БД поскромнее?
В общем хотели сделать хорошо, но времени\знаний\опыта не хватило и получилось как обычно.
Сама система стоит заметно дороже лицензий на винду и СУБД, но это в полноценной комплектации, а есть простенькие варианты, под которые хотели сделать «бюджетный» вариант с открытой СУБД, чтобы действительно не получалось, что собственно продаваемый софт стоит чуть ли не меньше, чем лицензии на необходимое для работы ПО.
Про структуру базы вообще смешно говорить. Пара таблиц без внешних ключей и с одним автоинкрементным полем + индекс по времени.
Но на лицо проблемы архитектуры.
Плюс работа в реальном времени, которая накладывает требования на используемые инструменты: это Scala/Erlang/JavaRT и, если запросы не сложные — нафига Вам вообще RDBMS, с их нелёгкой, неотключаемой и не нужной Вам функциональностью? Может — файлов хватит?