xmoonlight

и чьё мнение можно считать экспертным.

ни чьё, даже если Вы сами с "нуля" написали свой код от начала и до конца.

Есть много уровней защиты от "чужих": аудит исходного кода, профилирование важных участков кода и поиск утечек, сканер уязвимостей кода оффлайн и в момент исполнения, контроль среды исполнения, контроль сетевой активности.

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

Простое решение: "проксирование" запросов между вашим и чужим кодом в обоих направлениях и контроль данных регулярками.

Нужно брать код любого понравившегося репозитория, разбираться, дорабатывать, превнося более лучшее и более оптимальное (чем в существующей версии), и предлагать свой commit в ветку.

Мне говорили, что если в проекте есть монетизация, то это по факту не опен сорс проект. Верно ли это утверждение?

ДА, верно.

Если да, то почему проект в котором есть монетизация (коммерческий) просто не может быть с открытым кодом для всех?

Иначе - стырят!)

1. Ваш код на гите - это Ваше портфолио.
2. Работодатели чаще приглашают на собеседование тех, у кого есть что показать.
3. В плане оформления - оформляйте как требуют правила гита. (на отношение к продукту как к рабочему инструменту - это абсолютно никак не повлияет).
4. После того, как кто-то захочет доработать (или получить консультацию) Ваш проект под свои нужды не своими силами - они первым делом обратятся к Вам (как к автору).
5. Wiki - не забывайте оформлять как документацию по установке и т.д.
6. Почитайте тут о всех возможностях гита: https://github.com/features

другие хабы правилами запрещается это делать.

Их никто не соблюдает!

https://cryptpad.fr

Разработчик, не пишущий в опенсорс — плохой разработчик?

Он плохой лишь потому, что он не принесёт компании халявный код и мгновенную прибыль.

Эта "палка" о двух концах:
1. Не виден Ваш уровень и стиль кодирования (т.е., отсутствие портфолио).
2. С Вас нечего взять при подписании NDA (и/или договора) и "положить" код в компанию, сделав Ваш Open-Source код закрытым.
 
1. Выкладывайте то, что может показать Ваш уровень владения инструментом (ЯП).
2. Выкладывайте то, что не несёт потенциальной прибыли и не интересно бизнесу. Какие-то небольшие промежуточные, но законченные вещи в виде небольшой библиотечки или модуль.
Например, реализация простого школьного алгоритма, или что-то под CMS, или js/jquery-модуль и т.п.
Главное - чтобы это было востребовано хотя бы кем-то (чтобы минимальная полезность кода - присутствовала).

Я вот сам искал под Lazarus, но пока пришёл к одному: берётся граф. либа BGRABitmap и на ней всё делается вручную.
Бонус.

Посмотрел, код - нормально оформлен, но для капчи:
1. проверка капчи успешна при любом регистре
2. обрабатывайте похожие при написании символы одинаково (например, l и 1 - это одно и то же, и т.д.)
3. используйте динамическое искажение, а не статичное (как сейчас)
4. старайтесь генерировать слова-неологизмы (1-2 согласных и гласная), цифры используйте только вначале или в конце слова - это будет проще вводить для пользователя.
5. один неверный символ в любом месте - не считается ошибкой (а опечаткой)

Ковыряйте любую HTML5 игру с выбором уровней в формате SPA-приложения, написанную полностью вручную.

Вместе с исходным кодом на PHP есть у smspilot.ru

SPA + NWJS

Joomla

if (!(via SEOPro))
    if (!(via modules))
           die('Никак!');