Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 51
Считаю, что ядро открывать не нужно если продукт (например CMS) коммерческий. А вот API, модули, очень даже стоит. Почему держать ядро закрытым? Потому что меньше вероятность, что сайты всех ваших клиентов положит какой-нибудь умник. Естественно, его нужно улучшать и совершенствовать, и выпускать обновления. Вот так думаю. В случае если продукт бесплатный открытость пойдёт только на пользу.
Есть множество способов, "убедить" пользователя платить за софт или за его поддержку даже если его исходники открыты, например, давать важные обновления "халявщикам" тока через несколько месяцев после покупателей, да и еще 1000 вариантов придумать можно, таких что тот кому продукт нужен его купит.
Вот какие есть еще способы убедить?
сделайте продукт лучше чем существующие альтернативы, напишите в лицензии что в коммерческих целях можно использовать только купленную версию. А дальше те кто могут купить - купят, на тех кто не хочет покупать закройте на время глаза - пусть "подсядут" на продукт. Ну а когда переходить на что то другое станет "дороже" чем стоит ваш продукт - вы тут как тут. Да и проблемы которые решить без вмешательства разработчиков нельзя всегда рано или поздно возникают и тогда "воришка" сам обратится к вам.
Еще если есть несколько функционально различающихся версий продукта неплохо бы дарить самую полную версию за какую нибудь доработку.
Еще если есть несколько функционально различающихся версий продукта неплохо бы дарить самую полную версию за какую нибудь доработку.
Если ваш проект достаточно серьезен, чтобы им заинтересовалось много народу, тогда есть смысл открыть код, т.к. будут разрабатываться плагины, находиться ошибки. Если это относительно небольшой проект, то ваш исходный код будут в основном использовать в своих интересах и отдачи вы не получите. В первом случае можно зарабатывать еще и на платной поддержке, но для этого необходимо большое число пользователей.
В первом случае будет потерян один из источников дохода: непосредственно продажа дистрибутива. К тому же, если продукт полностью открыт, то и отдача от техподдержки после некоторой "пиковой точки" может начать сильно снижаться, так как обязательно появятся сторонние специалисты (да хотя бы в штате наиболее крупных ваших заказчиков), хорошо разбирающиеся в продукте.
Открытый исходный код, noofiz, для коммерческого ПО все-таки не слишком хорошо подходит.
Открытый исходный код, noofiz, для коммерческого ПО все-таки не слишком хорошо подходит.
Не согласен со многими аргументами в пользу закрытого кода: Вас не кто не заставляет оставлять за клиентом право пользования тех. потдержкой в случае если он полез править код программы и так поступают многие:). Если программ закрыта но при этом популярна то её всеравно сломают(примеров масса, взять хоть тот же Виндоус), если она для узкого круга то тем не менее люди у которых не будет средств купить, найдут как это дело украсть... Сам, пока что, толкаю все с открытым кодом, но с ограничениями на тех.потдержку и на распространение кода. Никаких проблем пока не вижу, даже в тех совтинках где есть защита и её обойти элементарно(так как код открыт), люди все равно ее покупают
1. я бы (на своем продукте) закрыл ядро и некоторые особо важные модули.
2. Самым тщательным образом задокументировал API и принципы построения (написания) модулей(если таковые есть)
Что получаем:
1. Нельзя внести критических изменений, несанкционированно использовать и т.д. (по крайней мере это существенно затрудняется)
2. Сторонние разработчики (или админ (програмер) клиента) получают возможность без труда расширять и дополнять функционал.
2. Самым тщательным образом задокументировал API и принципы построения (написания) модулей(если таковые есть)
Что получаем:
1. Нельзя внести критических изменений, несанкционированно использовать и т.д. (по крайней мере это существенно затрудняется)
2. Сторонние разработчики (или админ (програмер) клиента) получают возможность без труда расширять и дополнять функционал.
Идея очень ГУД, мог бы поставил бы плюсик:)
можно еще ключик к системе привязать (на домен) дабы защититься от ситуации, в которой заказчик захочет еще один сайт и обратиться к стороннему разработчику(своему админу, програмеру и т.д.), а не к Вам.
Это у нас есть. Только при опен соурсе ключик превращается в совсем уж формальность. Или не совсем?
формальность... только не совсем. при договорных (официальных) отношениях с заказчиком,
грамотно продуманный и грамотно встроенный (чтобы юзер не нашел его через минуту беглого просмотра кода) ключик может являться достаточной основой для установления авторства и выявления случаев несанкционированного использования.
В дополнение к этому можно прописать продукту некоторую доп. функциональность(например заставить сайт клиента по определенному расписанию (допустим 1 раз в неделю) запрашивать сервисную страницу разработчика с использованием ключа).
Но, я думаю, что выражу общее мнение, любая защита обходится и ломается. При желании и необходимости.
грамотно продуманный и грамотно встроенный (чтобы юзер не нашел его через минуту беглого просмотра кода) ключик может являться достаточной основой для установления авторства и выявления случаев несанкционированного использования.
В дополнение к этому можно прописать продукту некоторую доп. функциональность(например заставить сайт клиента по определенному расписанию (допустим 1 раз в неделю) запрашивать сервисную страницу разработчика с использованием ключа).
Но, я думаю, что выражу общее мнение, любая защита обходится и ломается. При желании и необходимости.
Мне кажется что открывать код стоит почти всегда, но не всегда. Например это не стоит делать в случае антивирусов. В остальных же случаях выбор за вами, но в случае опенсорса вы получаете дополнительный бесплатный тест на безопасность (да, я считаю это плюсом а не минусом), и если ваш OS-продукт взломают — нужно быть к этому готовым и быстро внести исправления (а значит получить большой опыт).
Говоря открытый код, сегодня, мы все же подразумеваем OpenSource. Я вот лично изначально вашу статью так и понял опенсорсная модель против проприетарной. А оказалось у вас другая проблема, включать в поставку исходные тексты или нет. В принципе, даже у MS есть лицензии для партнеров, когда они предоставляют исходный код. Ну и в вашей ситуации, сделайте это отдельным пунктом, можно за отдельную плату.
Автор пишет об открытом коде применительно к скриптовым продуктам, в данном случае для WEBа. Не нужно сравнивать их с операционками и системным софтом. Слишком много принципиальных отличий.
Правильный ответ на вопрос сильно зависит от обстоятельств: от типа продукта, от способа его распространение, от стратегии развития бизнеса и т.д.
Открытость или закрытость кода влияет на цену продукта в случае коробочного решения, или является предметом торга при переговорах с заказчиком при индивидуальных проектах.
Но надо признать, что драматического значения этот фактор в большинстве случаев, не имеет.
Даже если продукт представляет из себя некую платформу для кастомизаций, все равно куда более важную роль будут играть подробная, актуальная документация, хорошо организованная служба поддержки и удобный API.
Насчет пиратства: заказчик, настроенный получить продукт бесплатно - скорее всего денег в любом случае не принесет (речь идет о корпоративном секторе).
Как заказчик, я бы в большинстве случаев предпочел иметь исходные коды.
Как разработчик, я постарался бы скрыть те части кода, которые дают мне конкурентное преимущество на рынке, в том случае если их легко вычленить и использовать повторно. Коробочные продукты, вокруг которых маловероятно формирование сильного комьюнити разработчиков, я бы поставлял с закрытыми исходными кодами.
В одном можно быть уверенным: этот вопрос находится в компетенции бизнеса и отдавать его на откуп техническим специалистам, категорически нельзя.
Открытость или закрытость кода влияет на цену продукта в случае коробочного решения, или является предметом торга при переговорах с заказчиком при индивидуальных проектах.
Но надо признать, что драматического значения этот фактор в большинстве случаев, не имеет.
Даже если продукт представляет из себя некую платформу для кастомизаций, все равно куда более важную роль будут играть подробная, актуальная документация, хорошо организованная служба поддержки и удобный API.
Насчет пиратства: заказчик, настроенный получить продукт бесплатно - скорее всего денег в любом случае не принесет (речь идет о корпоративном секторе).
Как заказчик, я бы в большинстве случаев предпочел иметь исходные коды.
Как разработчик, я постарался бы скрыть те части кода, которые дают мне конкурентное преимущество на рынке, в том случае если их легко вычленить и использовать повторно. Коробочные продукты, вокруг которых маловероятно формирование сильного комьюнити разработчиков, я бы поставлял с закрытыми исходными кодами.
В одном можно быть уверенным: этот вопрос находится в компетенции бизнеса и отдавать его на откуп техническим специалистам, категорически нельзя.
Дак и не отдаю! :) Технические спецы у нас сильно противятся открытию кода. Хотя в данном случае показать его совсем не стыдно. Но сопрут ведь сразу!
Нужно соотнести потенциальные потери от пиратства с потенциальными доходами от привлеченных открытыми исходными кодами клиентов.
В любом случае конкуренты украв вашу интеллектуальную собственность не смогут с вами конкурировать ни в чем кроме более низкой цены на продукт.
В любом случае конкуренты украв вашу интеллектуальную собственность не смогут с вами конкурировать ни в чем кроме более низкой цены на продукт.
Просто бизнес-модель с опенсорс другая. Здесь люди хотят получать деньги за продажу опенсорс ПО - это в корне неверно. Если опенсорс модель - это два основных варианта дохода, дополнительный суппорт или две версии ПО: комьюнити(опенсорс и бесплатная) и профессионал(опенсорс+проприетарный код). Конечно могут быть вариант, типа: продажа символики, доработка софта под нужды клиента за доп.финансирование и т.п. ;) - но это уже смотря какое ПО
имхо - жадничать не хорошо)
от того что стырят код вам лично ничего плохо не сделается. в любом случае - даже при закрытом коде - кому надо стырят так же точно. и в то же время - при открытом коде ее так же точно купят те же люди, что купили бы при закрытом.
имхо, опять же, по нынешним временам гораздо выгоднее иметь опен-сорс проект и зарабатывать на поддержке, установке и настройке. ну и некоторым другим "второстепенным" услугам - на вроде конвертации видео на своих сервверах, хостинг и реклама...
от того что стырят код вам лично ничего плохо не сделается. в любом случае - даже при закрытом коде - кому надо стырят так же точно. и в то же время - при открытом коде ее так же точно купят те же люди, что купили бы при закрытом.
имхо, опять же, по нынешним временам гораздо выгоднее иметь опен-сорс проект и зарабатывать на поддержке, установке и настройке. ну и некоторым другим "второстепенным" услугам - на вроде конвертации видео на своих сервверах, хостинг и реклама...
Проблема воровства подходов в PHP всегда была и, вообще говоря, всегда будет (во всяком случае пока он остается интерпретатором с нестрогой типизацией). Можно постараться закрыться зендом + внеджрив в ядро пару - тройку скомпилированных фрагментов - при здравом подходе затраты на взлом обгонят затраты на написание (был в свое время положительный опыт в этой области). Правда, от тыренья идей и воплощении этих идей под другим трейдмарком это не спасает (уже отрицательный опыт тоже имел место быть).
А вообще, если очень хочется закрыть какую-то часть кода, единственный, наверное, жесткий способ - делать свой хостинг. По нынешним временам покупка сервера под 20 - 30 (100 - 200 - тут, пожалуй, все зависит от качества кода и железяк) клиентских проектов вполне окупается где-то за год. При этом, ничего не мешает, оставив ядро закрытым для посторонних, открыть API, сделать общий репозиторий и наслаждаться всеми прелестями open-source подхода. В конечном итоге, 90% примочек, написанных под если не непосредсвтенно под unix, то под какую-нибудь юниховую фичу - юзают общий API и ни разу не заморачиваются на том, что в этот момент творится в ядре системы.
А вообще, если очень хочется закрыть какую-то часть кода, единственный, наверное, жесткий способ - делать свой хостинг. По нынешним временам покупка сервера под 20 - 30 (100 - 200 - тут, пожалуй, все зависит от качества кода и железяк) клиентских проектов вполне окупается где-то за год. При этом, ничего не мешает, оставив ядро закрытым для посторонних, открыть API, сделать общий репозиторий и наслаждаться всеми прелестями open-source подхода. В конечном итоге, 90% примочек, написанных под если не непосредсвтенно под unix, то под какую-нибудь юниховую фичу - юзают общий API и ни разу не заморачиваются на том, что в этот момент творится в ядре системы.
полностью согласен...
но мне просто как-то подумалось - ну вот стырят мою идею, мой скрипт, мой движок... и что? от меня-то не убудет. а если идея (скрипт/движок) хорошая - мир станет немножко лучше, когда ее буду использовать не только я. :)
ну если копирайты снесут, то обидно, конечно, но в целом - ну какая мне разница :) стоит ли из-за этого расстраиваться? :)
но мне просто как-то подумалось - ну вот стырят мою идею, мой скрипт, мой движок... и что? от меня-то не убудет. а если идея (скрипт/движок) хорошая - мир станет немножко лучше, когда ее буду использовать не только я. :)
ну если копирайты снесут, то обидно, конечно, но в целом - ну какая мне разница :) стоит ли из-за этого расстраиваться? :)
Если вы писали этот продукт как хобби, ради удовольствия, помощи ближнему и т.п., то, конечно, не убудет.
А если этим занималась контора и на это ушло несколько человеко-лет работы, то фирма должна получить компенсацию затрат, иначе она разорится и новые улучшенные версии программы не увидят свет. А вот от этого уже могут пострадать все пользователи.
А если этим занималась контора и на это ушло несколько человеко-лет работы, то фирма должна получить компенсацию затрат, иначе она разорится и новые улучшенные версии программы не увидят свет. А вот от этого уже могут пострадать все пользователи.
Я о коммерчееском варианте и говорил... Всех денег в любом случае не заработаешь... А если продукт хороший - то покупать его будут в любом случае. Ну вон, к примеру взять, форумные движки ИПБ - их же тырят направо и налево, но есть люди, которые покупают. И их достаточно много... А что тырят - так это даже может и хорошо - бесплатная реклама и повышение популярности движка... :)
Возможны и не столь радужные варианты. К примеру, ваш продукт в чем-то обгоняте конкурентов (а он скорее всего в чем-то да их обгоняет), потом у вас его тырят, потом стыренное появляется у кого-то, кто на вопрос зарабатывания всех денег смотрит иначе... Глядишь - и вы уже не имеете право пользоваться собственными наработками, поскольку они являются частью запатентованного другими. Илил какая-то подобная засада.
Я не говорю про все деньги :) А только про необходимые для развития продукта дальше.
Это еще может быть такой скрытый демпинг для завоевания рынка, как, например, винда 10 лет назад.
Это еще может быть такой скрытый демпинг для завоевания рынка, как, например, винда 10 лет назад.
имхо, модель «писать софт в надежде получить компенсацию затрат на его написание», которое порождает заключения «фирма должа получить компенсацию, она же вкладывала свои деньги и время в его написание» — _в_корне_ не верна. Альтернативные варианты уже озвучивали, и, собственно, дело автора — выбрать себе устраивающую его модель :)
off: Посоветуйте, пожалуйста, куда гуглить о том, как закрыть код php? Я думал, исходный код можно закрыть только компилированием...
Можно продавать две версии, версию с открытыми исходниками естественно дороже :)
Закрытый код + открытый API - лучшее решение, IMHO.
Все-таки открытые тексты программ и скриптов позволяют не изобретать велосипед заново, а заниматься действительно РАЗРАБОТКОЙ. Закрытые технологии и исходники "блокируют" развитие. Сегодняшнее развитие Web2.0 и всего с ним связанного - следствие того, что стали открываться хотя бы API приложений
Речь идет о коммерческих продуктах. Копирование и использование под свои нужды кода коммерческих приложений, как правило, запрещено лицензией на это самое приложение.
P.S. Развитие т.н. "Web 2.0" связано не только с тем, что стали появлятся открытые API. И, к слову, веб-сервисы вполне могут быть и приложениями с закрытым исходным кодом.
P.S. Развитие т.н. "Web 2.0" связано не только с тем, что стали появлятся открытые API. И, к слову, веб-сервисы вполне могут быть и приложениями с закрытым исходным кодом.
если за проект заплачены деньги, то имхо, код должен быть отдан в нормальном виде. Вы же брали деньги за время, которое потратили на его написание. Любой проект может морально устареть или потребовать вмешательства в код на разную глубину. Закрыв ядро, изменения(дальнейшая разработка) с другим программистом(ами) исключается, на что по сути вы не имеете права(говорить заказчику с кем работать и привязывать к себе).
Ситуация будет выглядеть вроде: купили машину и износилась подвеска(устарел проект, требует дорабокти или расширения), но о замене не может быть и речи — ваше авто - монолит. Разумеется жалко код и личные идеи, но все же не забывайте про взгляд со стороны заказчика.
Ситуация будет выглядеть вроде: купили машину и износилась подвеска(устарел проект, требует дорабокти или расширения), но о замене не может быть и речи — ваше авто - монолит. Разумеется жалко код и личные идеи, но все же не забывайте про взгляд со стороны заказчика.
Открытый код позволяет тем, кто его использует, найти причину непонятного/неправильного поведения продукта или прояснить какие-то моменты, недостаточно полно освещённые в документации. Т.е. мне, как разработчику, иметь исходники сторонних библиотек — крайне полезно.
Продаем, дорого. Но не сам дистрибутив, а готовые сайты на основе нашей CMS. Код открытый без каких либо ограничений. Как правило наши заказчики зарабатывают иным способом чем перепродажа открытого кода. Бывает что что-то допишут, иногда такой дописаный код возвращается обратно. Поскольку мы часть холдинга, у нас есть юридическая поддержка, и если какой-нибудь клиент будет борзо продавать CMS своего сайта - добро пожаловать в суд. Но врядли это будет, поскольку клиент прекрасно зарабатывает в своем собственном бизнесе, а сайт ему в этом помогает.
раньше кодировали зендом 3 файлика из ядра, где проверяется лицензия. сейчас оставили кодирование только в младшей линейке, бесплатных и trial дистрибутивах.
с точки зрения защиты кода зендование не спасет отца русской демократии, а проблемы от него бывают очень оригинальные (не считая проблемы наличия на хостинге, но она как раз легко решается).
на самом деле, открывать достаточно только прикладной код модулей. но разницы особо никакой, поэтому проще открыть все. кому-нибудь обязательно пригодится, "спасибо" скажут.
с точки зрения потери налички, лично я в этом опасности не вижу. покупают-то не код.
с точки зрения защиты кода зендование не спасет отца русской демократии, а проблемы от него бывают очень оригинальные (не считая проблемы наличия на хостинге, но она как раз легко решается).
на самом деле, открывать достаточно только прикладной код модулей. но разницы особо никакой, поэтому проще открыть все. кому-нибудь обязательно пригодится, "спасибо" скажут.
с точки зрения потери налички, лично я в этом опасности не вижу. покупают-то не код.
ТС: желаете знать, как заставить человека платить? :)
1. Мне недавно постучался человек с интересного форума (nulled.ws) и попросил докрутить к вашей CNCat возможность продавать ссылки в sape. Пару замечаний:
а. Я, как программер, который активно разрабатывает системы OpenSource, так и не смог заставить Вашу систему работать под исконным UTF8, о которой говорилось. Пришлось ставить в cp1251 и в htaccess прописывать Add default charset :)
б. Я, как программер, долго думал как заставить вашу систему выводить код. Нашел как - сделал. Только одно "НО" - почему этого не может сделать рядовой пользователь?
2. Кусок диалога:
Me > Мммм. ломает разбираться. Саппорт не судьба?
Чел < ни. чиловек обращался ани не ответили
Me > все ясно. Сделаем :)
О чем говорит? О том, что человеку не ответили у вас (за что я купил - за то продал).
Да и есть куча причин не продавать "закрытый код", намного весомее приведенных выше. Например? Например, возможность пользователю/клиенту самому дописывать код. Смотреть, как он работает... Править что-то. Разбираться, отправлять баг-репорты (с конкретными "узкими местами"). Такими, как {$_GET=cncatStripslashes((array)$_GET). Вы бы головой подумали, что есть $_GET :).. Если его внутри скрипта не модифицировать - GET так и останется массивом (((array)$_GET)). ПОтери при быстродействии не считали? :) Или, file_exists($CNCAT["system"]["dir_root"].$CNCAT["system"]["dir_config"]."config_ext.php")... Ну да ладно, а то пост в наезды превращается :)
ЗЫ: ничего личного. Но в конктретном скрипте много косяков. На его основе и делаю выводы.
Например, мну нафиг не нужно будет дезендить (nulled.ws), разбирать код руками (обфускация), геморрой с eval (вы бы хоть головой подумали над одной вещью: если чел полезет нуллить скрипт - ему пофиг есть там eval с base_encode или нет :))...
Пока конкретно Вы используете шаблоны на глобальных переменных - вас не спасет никакая обфускация.
Самое главное - открытый код. Открытый "качественный" код. А так да вам в зенде нада его продавать... Дезенд, хотя бы, выравнивает его. Логику "распрямляет" :)
------------
Так вот вам - очевидный плюс закрытого программирования (скрыть свои косяки). И он же- минус. Что делать - выбирать каждому программисту. Опять же, от задачи зависит.
Продаешь штучный продукт - продавай закрытым. Ибо это - штучное. Не найдется одного из 100 клиентов, который за идею OpenSource выступит.
Продаешь открытым - продавай открытым (обычно, с невысокой стоимостью). Но обеспечивай поддержку "на высоте". Я уверен, что еслиб вы отвечали и помогали - человек использовал бы именно вашу копию. А не скачанную с известного ресурса ;)
1. Мне недавно постучался человек с интересного форума (nulled.ws) и попросил докрутить к вашей CNCat возможность продавать ссылки в sape. Пару замечаний:
а. Я, как программер, который активно разрабатывает системы OpenSource, так и не смог заставить Вашу систему работать под исконным UTF8, о которой говорилось. Пришлось ставить в cp1251 и в htaccess прописывать Add default charset :)
б. Я, как программер, долго думал как заставить вашу систему выводить код. Нашел как - сделал. Только одно "НО" - почему этого не может сделать рядовой пользователь?
2. Кусок диалога:
Me > Мммм. ломает разбираться. Саппорт не судьба?
Чел < ни. чиловек обращался ани не ответили
Me > все ясно. Сделаем :)
О чем говорит? О том, что человеку не ответили у вас (за что я купил - за то продал).
Да и есть куча причин не продавать "закрытый код", намного весомее приведенных выше. Например? Например, возможность пользователю/клиенту самому дописывать код. Смотреть, как он работает... Править что-то. Разбираться, отправлять баг-репорты (с конкретными "узкими местами"). Такими, как {$_GET=cncatStripslashes((array)$_GET). Вы бы головой подумали, что есть $_GET :).. Если его внутри скрипта не модифицировать - GET так и останется массивом (((array)$_GET)). ПОтери при быстродействии не считали? :) Или, file_exists($CNCAT["system"]["dir_root"].$CNCAT["system"]["dir_config"]."config_ext.php")... Ну да ладно, а то пост в наезды превращается :)
ЗЫ: ничего личного. Но в конктретном скрипте много косяков. На его основе и делаю выводы.
Например, мну нафиг не нужно будет дезендить (nulled.ws), разбирать код руками (обфускация), геморрой с eval (вы бы хоть головой подумали над одной вещью: если чел полезет нуллить скрипт - ему пофиг есть там eval с base_encode или нет :))...
Пока конкретно Вы используете шаблоны на глобальных переменных - вас не спасет никакая обфускация.
Самое главное - открытый код. Открытый "качественный" код. А так да вам в зенде нада его продавать... Дезенд, хотя бы, выравнивает его. Логику "распрямляет" :)
------------
Так вот вам - очевидный плюс закрытого программирования (скрыть свои косяки). И он же- минус. Что делать - выбирать каждому программисту. Опять же, от задачи зависит.
Продаешь штучный продукт - продавай закрытым. Ибо это - штучное. Не найдется одного из 100 клиентов, который за идею OpenSource выступит.
Продаешь открытым - продавай открытым (обычно, с невысокой стоимостью). Но обеспечивай поддержку "на высоте". Я уверен, что еслиб вы отвечали и помогали - человек использовал бы именно вашу копию. А не скачанную с известного ресурса ;)
Спасибо со комментарий. Напишите если можно на support@cn-software.com или в личку. Хотелось бы пообщаться поподробнее насчет критики Ката.
Поймите правильно, я директор. И сильно в код не лезу разбираться, отдаю на откуп разработчикам.
Насчет потерь на быстродействии - считали. Наш скрипт и так самый быстрый из всех при существующем функционале. Но оптимизация хороша в меру, некторые вещи нет смысла убыстрять.
Поймите правильно, я директор. И сильно в код не лезу разбираться, отдаю на откуп разработчикам.
Насчет потерь на быстродействии - считали. Наш скрипт и так самый быстрый из всех при существующем функционале. Но оптимизация хороша в меру, некторые вещи нет смысла убыстрять.
Насчет поддержки. Действительно было такое обращение. Посыпаю голову пеплом. Наш косяк. Человек писал на форум, а сейчас лето, время для суппорта сложное :) упустили, исправимся.
Хороший у вас обфускатор. шифрация ерунда, без проблем разбирается.
А вот обфускатор классный, обозвать все переменные комбинацией символов 0 (ноль) и О (буква "о") это отличная идея, многие шрифты спотыкаются и показывают одинаковые символы. Даже если шрифт не спотыкается очень сложно разобраться.
А вот обфускатор классный, обозвать все переменные комбинацией символов 0 (ноль) и О (буква "о") это отличная идея, многие шрифты спотыкаются и показывают одинаковые символы. Даже если шрифт не спотыкается очень сложно разобраться.
Свой фреймворк, который интенсивно разрабатываю уже лет пять, держу исключительно открытым :)
Код должен быть открытым.
Кредо.
Код должен быть открытым.
Кредо.
Vass, идея "игр со шрифтами" впервые была реализована в PHP Defender. Там они игрались с 1,I,l - очень неприятно разбирать такие штуки. И плюсов у дефендера выше - поскольку вариаций из трех символов больше - имена переменных можно делать короче. А про рост производительности с "укорачиваниями" имен переменных можете почитать в сети / поставить сами эксперимент ;)
dalv, отписать-то отписал на мыло. А толку? Тут ведь речь не идет о качестве вашего продукта (каюсь - зря начал разносить скрипт, ибо в сторону начали уходить). Идет речь о концепции продаж и распространения.
Вот тут вы глубоко заблуждаетесь. Быстродействие вам не помешает только потому, что быстрый код, в основе своей, имеет правильную структуру (за некоторыми исключениями на валидацию - но к вашему продукту это не относится). Имеете правильную архитектуру - имеете расширяемость и правильную логику ;)
dalv, отписать-то отписал на мыло. А толку? Тут ведь речь не идет о качестве вашего продукта (каюсь - зря начал разносить скрипт, ибо в сторону начали уходить). Идет речь о концепции продаж и распространения.
Наш скрипт и так самый быстрый из всех при существующем функционале. Но оптимизация хороша в меру, некторые вещи нет смысла убыстрять.
Вот тут вы глубоко заблуждаетесь. Быстродействие вам не помешает только потому, что быстрый код, в основе своей, имеет правильную структуру (за некоторыми исключениями на валидацию - но к вашему продукту это не относится). Имеете правильную архитектуру - имеете расширяемость и правильную логику ;)
есть Дебиан. а есть *бунты всех мастей и их производные. имхо, Дебиан не пострадал от их появления.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Открытый исходный код — благо или троянский конь?