Вот родилась такая дикая, я бы даже сказал, сумасшедшая идея создания такой-растакой системы управления ресурсами предприятия на условиях GPL.

Навеяло проектом Nexus, который меня не устраивает из-за принципиальной зависимости от встроенного функционала и сложностью доработки на коленках.

Решаемые задачи
Чем больше - тем лучше. Начать с банального склада - кончить коллцентрами и визуальным мониторингом за поставками товара (но это уж точно не я буду делать). Главное ядро, а модули можно будет дописывать потом и через API.

Иструментарии проджекта
Принцип клиент-сервер.
Сервер - всё что можно поставить где угодно. Т.е. универсальный интерпретатор. Т.е. вёб-сервер (яву и прочие ДотНеты не предлагать по причине неGNUнутости).
Клиент - всё что можно поставить где угодно. Т.е. браузер.
Язык - Си, можно перл (перл даже лучше, поскольку его знают больше и %-ное соотношение трезвых людей его знающих больше чем пхп)
Технология АЙЯКС (терпеть не могу - но никуда не денешься)
БД - ессно, Постгрес
Обеспечение сукьюрности - ССЛ
Связи с бухгалтерией - на уровне экспорта/импорта документов (и вообще, пусть у буха стоит пневмопочта)

Вот такое предложение в кратце.

Собсно, откуда взялась такая идея.

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

guest_97324556Ну...ты эта... как кончишь колцентром - позови, посмотрим...
Шутишь? Я копыта отброшу в одиночку всё писать.

CalmГари Купер, отбросив в сторону такие малосущественный для идейного человека, как финансирование проекта и количество человеко лет, замечу, что для написания подобного софта
1. нужно быть глубоким специалистом в предментных областях
2. быть архитектором ПО очень высокого класса.
3. иметь большой опыт управления разработкой и людьми в больших проектах.
и т.д. и т.п.

Вы все еще уверены в своих силах?


Так и знал что мне зададут этот гадкий вопрос. Вот всё ж найдётся человек который всю романтику испортит. :-)

Нет и ещё раз нет. Я вообще сомневаюсь что такие уверенные специалисты в России существуют (по меньешй мере, я кричал, но молчание было мне ответом), поскольку "15 лет - не срок". В том плане, что большинство спецов по планированию в 90-х либо заплутали в коммунистических линиях (постарше), либо подались в челночный бизьнес (помладше), отчего потеряли квалификацию мыслить "сись_темно". Большинство хороших разработчиков софта: а) либо хорошие программисты; б) либо хорошие управленцы; в) либо хорошие бухгалтеры. Совмещать всё это в одном человеке или в одном организационном лице не получается. Продукт выходит откровенно фиговый.

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


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


По такому случаю, не грех и виртуальное предприятие смоделировать. Одновременно заюзав всех разработчиков в качестве работников этого предприятия. Но это так... по секрету всему свету: "Идея пущенная в народ сравни девке..."

Да я был бы просто рад если бы эти идеи кто-то "стащил" и реализовал. Так ведь нет...

sergey888 авторКлиент в большинстве случаев при приобритении проприетарной системы покупает кота в мешке.

А Вы что предлагаете уме купить, набор технологий?

Зачем? Просто будет проще изучить систему без возни с программистами чужой фирмы, подписывании соглашений о неразглашении и проч. Чем больше пользователей - тем лучше программа (это основная характерная черта GNUтого софта). В отличие от проприетарного софта, где увеличение пользователей не повышает вероятность улучшения софта.

АБДумаю, идея носится в воздухе.

Сам удивляюсь почему таких проектов ещё не расплодилось по всему миру.

АБ
- Может представлять интерес, если заложить в архитектуру связку BPM+SOA (OpenSource реализации есть). Слабосвязные модули.

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

Хочется отметить, что преимущество такого подхода ещё и в том, что такие конторы как 1C, Парус и т.п. можно было б вынудить постепенно входить в пространоство этих стандартов, заставляя их соблюдать транзитивность.

АБ- Без сервера приложений придется делать слишком много дурной работы -- заведомый проигрыш на старте. В чем проблема с Java, например в реализации JBoss?
Ява слишком капризна к аппаратной платформе.

АБ- Почему Постгрес, а не Мускуль, к примеру (мне в принципе все равно, просто интересуюсь)? В любом случае, опционально Оракл должен поддерживаться (будем реалистами).
Во первых, по Постгресу написаны толковые доки. Во вторых, Постгрес соблюдает стандарты SQL (в отличие от мускуля и МС Эс-кью-эль). А если где в нём и есть расширения стандартов, то об этом в любой доке подробно написано. Поэтому написав под Постгрес, сделать переход системы на Оракл будет не столь сложно. В конце концов, постгрес действительно стабилен.

АБПроект может иметь практическую перспективу при условии серьезной поддержки. Например: государство декларирует поддержку, финансирует в объеме 10-30%, стимулирует коммерсантов своими методами, "рекомендует" бюджетным организациям (включая оборонку).

Надеяться на государство - дело заранее гиблое. Искать частных инвесторов тоже не выход - они в определённый момент попытаются заявить свои права на разработку и начнётся много трудностей. Поэтому придётся набирать энтузиастов. Даже без существенных денег капитальная база есть: это наш опыт, навыки, знания, желание оптимизировать свой собственный главный ресурс: время. Ведь никто по отдельности от проекта сразу не выиграет. Выигрыш всех будет потом, когда не будет лицензионных препонов с проприетарщиками, когда за 5 минут без всяких формальностей можно будет сделать подточку системы под конкретную организацию. Когда не надо будет тратить море времени на согласование действий с их программистами. Когда заказчик будет точно знать сколько потребутеся времени на внедрение, _точную_сумму_ затрачиваемых денег (99% из которых, скорее всего, уйдёт на ваш и только ваш гонорар) и дать правильную оценку эффективности внедрения (типа, столько было, столько стало).


Kamo2002Как же вы ее потом внедрять будете? C каких средств откаты платить?
Кому откаты? Да заказчики вас сами с руками оторвут если вы скажете им чётко что вы сможете оптимизировать и сколько будет это стоить. Даже если это обойдётся дороже решений на 1С. А если в госконторах начальникам выгоден бардак, то там уж никакая система не приживётся. Но это уже другой вопрос: как нам Россию обустроить.


Calm

Так мы про ЕРэПэ или про романтику?
А для чего ЁРП нужен? Чтобы людям дарить добро, делать им щастье. :-) Без романтики никак. :-)


sergey888Если система будет строиться на буржуйских технологиях, то все равно деньги за лицензии пойдут буржуям.
Где же отечественные технологии?
Что такое "буржуйские технологии" относительно Оупенсорс? Над сервером Apache трудятся разработчики из 40 стран (ну или примерно столько). В некоторых проектах участвуют даже программисты из Нигерии.


sergey888Что-то я не видел российского Линукса (не путать с русифицированным)
Вот когда все продукты будут написанв на языке Ы или Ы++,
тогда да, действительно это будет отечественная разработка.

Зачем изобретать велосипед? Английский язык объективно лучше всех остальных подходит для написания языков программирования. Ассемблер как был стандартом 30 лет назад, так им и остался. Есть и другие языки, есть другие процессоры. Но какой смысл тратить время и силы на лишние действия?

sergey888
Мне непонятен еще один вопрос - почему именно открытый код?
Чтобы любой ефрейтор (начинающий программер/хакер) в армии мог переписать программу наведения баллистической ракеты?

Или терапевт, прочитав компьютерный журнал подправил под себя программу диагностики пациента?
Вы путаете разные вещи: разработку платформы и её внедрение. После внедрения возможность доступа к системно-важным функциям есть только у ограниченного круга лиц. Точно так же как открытый Линукс не означает что все юзеры имеют право рута и ваще переписать конкретную систему.

Мне кажется, вы вообще несколько не в теме. Это не в обиду, поймите.



guest_20040621Gary Cooper, а начинать обязательно с ERP? Может, для стартапа чуть проще задачу выбрать? ;)

Какие есть предложения? Для начала можно вообще поскрести по сусекам и сделать список тех оупенсорс-программ, которые могли бы пригодиться для решения локальных задач. Затем постепенно всё сводить воедино.

Для начала следует решить каким методом идти:
1. Через создание открытого стандарта (языка).
2. Через создание ядра системы.
3. Через объединение разрозненных программ.


Клиент-серверное решение - это я тоже немного поторопился. На стороне клиента могут быть переферийные устройства с аппаратно-программным интерфейсом. Это значит, что одного браузера для всех случаев жизни не будет достаточно. Если "человеческая" совместимость решается брауером и обучающими курсами, то с аппаратной совместимостью всё несколько сложнее.

Это ещё один плюс в сторону разработки стандарта.


АБА как насчет найти хоть того, хоть этого специалиста, который согласился бы работать на энтузиазме (в его представлении -- цифру проставьте сами)? На самом деле шанс найти есть. Представим себе некоммерческий консорциум, существующий на деньги господдержки и спонсорский. В него можно привлечь и консультантов из того же IBS для участия в работе над ТЗ, и студентов в качестве кодеров, и архитекторов, и проектировщиков.
Конечно! А если и какой знакомый профессор попадётся, то многие задачи можно будет решить завалом курсовых работ. :-)



miksoft Gary CooperВот родилась такая дикая, я бы даже сказал, сумасшедшая идея создания такой-растакой системы управления ресурсами предприятия на условиях GPL.
уже было :)
там даже 300k$ обещали за 80% готовности :):):)
Там совершенно другое дело. К тому же, не GPL. Это раз.

Во вторых, то что российские айтишники зажрались - факт. Пока из страны течёт нефть, а в страну текут доллары, программисты будут считать что принятие участия в любом проекте должно начинаться с фразы "сколько мне за это заплатят". Так вот когда нефти не будет, окажется что реального-то продукта создано программистами не было. И такие граждане как sergey888 будут задаваться вопросом: sergey888Где же отечественные технологии?

guest_20040621
;) Зайдите на sf и убедитесь, что Вы ошибаетесь. Они есть. Только вот качество... хм...

Вот именно. Поэтому считаю что их нет.

guest_20040621
> Ява слишком капризна к аппаратной платформе.

В смысле? ;)
В прямом. На абы какую машину не поставишь: подавай ей свежеиспечённые процессоры. Нет, конечно...на яве можно и эмулятор ОС написать, но... :-)))

guest_20040621
> Какие есть предложения?

У меня? Никаких, собственно. ;) Просто хотел заметить, что дорога в тысячу миль начинается с одного шага. ;)
Легко отделались. Ответ не принимается. :-)


Модератор: отредактировано

АБ Gary CooperНачать можно с разработки унифицированного языка разметки, который бы был связующим звеном между различными модулями и подсистемами. Уже есть: BPEL, XPDL, BPMN.
Нет-нет. Это языки БП, они слишком узки. К примеру, понятия МТЦ для них не существует.

АБ Gary CooperЯва слишком капризна к аппаратной платформе. Ха! А Вам известен язык, который не был бы капризен?
В той или иной мере. Против "открытой" явы ничего не имею. Но, всё же, ява как ветвь технологии мне кажется тупиковой ветвью. Как и .НЕТ.

В дополнение хотелось бы отметить, что "скопировать" опыт других продуктов - не проблема. Т.е. ваще приницпиально не проблема - можно сделать копию за весьма короткие сроки.

Подходить же к вопросу надо более системно, задумавшись: насколько она будет жизнесопособна при измненении программно-аппаратных мод? Как много существует программистов энского языка? Стоит ли выбирать конкретный вариант БД или ограничиться стандартами? Какой тип API будет наиболее удобен внедренцам? На каком уровне обеспечить модульность в условиях _распределённой_ разработки?

И т.д. и т.п. Вопросов возникает море. И решать проблему методом копирования тут ну никак нельзя.

АБ CalmНо, всё же, ява как ветвь технологии мне кажется тупиковой ветвью. Как и .НЕТ. Слушайте, ну у Вас и захват: платформы Java/.NET тупиковые, языки БП слишком узки. Процессоры существующие, подозреваю, Вас тоже не устраивают, об операционках даже и не заикаюсь. Может хотя бы транзисторы оставим как есть, или...? ;)
Оставим. Языки БП вполне себе пригодны для выполнения своих функций. Но в целом, БП - частный случай организации производственного процесса. Корень многих проблем ЁРП -систем - неправильно организованная база данных. Стандарт - это инструмент, позволяющий избежать избыточности нформации и, в то же время, недостаточности. В большинстве организаций информация неоднократно дублируется, на что уходит и время, и силы. Да и стабильность такой работы подрывается - нестыковки происходят постоянно.

guest_20040621> Корень многих проблем ЁРП -систем - неправильно организованная база данных.

Помедленнее, пожалуйста, я буду конспектировать. ;) Итак, в чем, по-Вашему, эта "неправильность" баз данных? Как эту ошибку следует исправлять?

Опциональный вопрос: Вы структуру данных той же Compiere видели?

Структуру данных Compiere я не видел.

В чём "неправильность" я уже написал. Это проблема не конкретной структуры БД, это проблема организации всего процесса получения, хранения и выдачи информации на предприятии.

И исчо раз.

Фиг с ней, с базой. Можно было бы использовать хоть какую, если бы на фирме работали только с одним программным комплексом. Задача состоит в том, чтобы организовать такую систему хранения информации, которая бы не зависила от конкретных решений. Для этого и нужен стандарт.

guest_20040621Видите ли, в чем дело: производство коммерческого ПО - это просто обычное производство.
Нет, это не обычное производство. Если я покупаю Бентли, то делаю с ним всё что хочу. Если я покупаю проприетарщину, я с ней нихрена не могу сделать, чтобы вы там ни гвоорили. Это уже неоднократно обсуждалось на форумах типа "Win vs Lin"