0,0
рейтинг
11 января в 01:00

Разработка → Почему и зачем писать open-source код?

image

Под катом интересный опрос

Возможно, заголовок этой статьи покажется Вам не корректным, ”Как можно писать open-source код? И что это за код такой?” — спросите Вы.

Чем open-source код отличается от “просто-кода”? Open-source проект — это ответственность за качество кода, за покрытие его тестами, за документацию, за своевременные ответы на вопросы и реагирование на bug репорты, за обработку pull-request’ов. Ваше поведение и мысли во время написания open-source кода, который увидит мир будут другие, соответственно и код на выходе получается другой.

Open-Source проект живет своей жизнью — жизнью сообщества, которое образуется вокруг проекта. Идеи, отзывы, bug репорты, обсуждение и благодарности от других членов сообщества влияют на Вас и проект напрямую, и стимулируют написание кода — понятного, документированного и покрытого тестами.

Про опыт:


Однажды, выложив свой код на GitHub, я уже не смог остановится. Первым моим публичным репозиторием был PHP-код, предназначенный для интернализации на основе MySQL таблицы. Этот репозиторий не собрал звезд и сомнительно, что был кем-то замечен. Не в звездах дело, дело в том что Ваш код доступен всем. Ваш код не скрыт на сервере, не минифицирован/аглифицирован в браузере и не скомпилирован на жестком диске пользователя — он выставлен всем на показ. Осознание данного факта просто обязует Вас писать код в общепринятой манере (в соответствии с тем языком на котором Вы пишите), соблюдать отступы, добавлять описание к методам и классам (как минимум к публичным), адекватно именовать переменные, классы, методы и функции, соблюдать правило do-not-repeat-yourself.

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

Писать общедоступный код — это как посещать светские мероприятия. Вы выглядите, разговариваете и соответствуете высшим стандартам IT-индустрии, или как минимум стремитесь к ним. Писать общедоступный код — это как обсуждать функционал IT-коллективом равным по масштабу всему IT-сообществу планеты. Любой из членов open-source сообщества может предложить изменения, сообщить о bug’е и вынести на обсуждение дальнейшее развитие проекта.

Приятное в open-source проектах — это эмоции и ощущения, испытываемые от понимания, что твой проект полезен. Когда количество скачиваний растет вверх, когда вы получаете отзывы, когда к проекту присоединяются люди со всего света и Вы вместе делаете проект лучше — это то, ради чего стоит писать код. В этот момент простое написание кода для решения поставленных задач перерастает во вклад в IT-сообщество.

Про опасения Студий и Компаний:


Ваша компания пишет код? Вы считаете, что написанный код принадлежит только Вам и Вашим клиентам, которые за него заплатили? Если Ваш ответ — ”да”, подойдите к Вашим разработчикам и попросите посчитать, сколько строк кода написано за стенами Вашей компании третьей стороной, скачено с SourceForge, GitHub, установлено через NPM, apt-get, aptitude, и других источников дистрибуции кода.

Когда речь идет об open-source, многие руководители (не все, но такие есть) считают что на GitHub лежат целые проекты, готовые к использованию и зарабатыванию денег. Когда Ваши сотрудники предлагают опубликоваться на GitHub, они собираются “слить” весь код, за который разработчики получили зарплату, а кто-то другой (нехороший) соберет клон Вашего продукта и будет зарабатывать деньги. Или хуже того, обнаружит эксплойт и будет его тайно использовать. Это абсолютно не так. Во-первых, никому не нужен Ваш проект целиком кроме Вас и Вашего клиента, во вторых, — не нужно выкладывать проекты целиком. Маленькие кусочки, классы, методы, адаптеры и т.п., из которых Ваш проект состоит, могут оказаться полезными не только Вам. На Ваш вклад IT-сообщество ответит поиском и исправлением ошибок и уязвимостей, дополнением функционала и улучшением производительности. Возможно, Вы найдете нового сотрудника в лице активного контрибьютора.

Open-source проект это:


  1. Живые эмоции, общение с людьми по всему миру.
  2. Доступ к накопленным знаниям и предыдущему накопленному опыту.
  3. Максимально-требовательный подход к написанию кода, документации и тестов.
  4. Совместная работа над задачей.
  5. Открытость перед конечными пользователями.





Во вселенной, где люди не научились работать в open-source сообществе, нет возможности использовать предыдущий накопленный опыт IT-индустрии и аккумулировать его. В свою очередь, IT-компании выделяют большую часть бюджета на платный софт. И в целях экономии на покупке и подписках на софт — пишут свои решения, что вызывает рост штата разработчиков в десятки раз, готовый выполнять задачи от написания ОС и фреймворков до текстовых редакторов, в которых этот код пишется. Хорошо что в нашей вселенной open-source сообщество активно развивается и нам это не грозит.

Выкладывайте Ваш код. Выкладывайте код, написанный в стенах компании (с соглашения всех руководителей). Сделайте вклад в развитие IT-индустрии. Читайте чужой код. Улучшайте чужой код. Всегда пишите bug репорты. Задавайте вопросы владельцам проектов и не забывайте отвечать на вопросы, заданные Вам. Спасибо.
Есть ли у Вас личные (персональные) Open-Source проекты?

Проголосовало 995 человек. Воздержалось 198 человек.

Есть ли в Вашей компании корпоративные Open-Source проекты?

Проголосовало 863 человека. Воздержалось 285 человек.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Dmitriy Aristarkhovich @drdimitru
карма
11,2
рейтинг 0,0
Full Stack
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (65)

  • +9
    Это всё идеологически правильно, а конечный результат полезен, но зачастую инициатива не остаётся безнаказанной:

    1. Как и любое другое сообщество, опен-сорс сообщество может быть достаточно токсичным, чтобы пропало желание контрибьютить. Достаточно вспомнить вечную драму вокруг GNU/Linux. А ваш пулл-реквест никогда не закрывали фразой «ты тупой идиот»? :)

    2. Зачастую чтобы открыть исходник какого-то компонента надо его сильно порефакторить — убрать специфичные для проекта хаки, выделить точки расширения, добавить тестов и доков. Это всё занимает большое время.

    3. Открытый код компонента — это ещё и обязанность его постоянно поддерживать, что постоянно занимает время разработчиков.

    4. В какой-то момент компания может осознать, что работа с третьесторонним фреймворком, который она использовала много лет, обходится дороже, чем написание собственного. И опен-сорсный фреймворк забрасывается в пользу нового, проприетарного. Заметьте, какое огромное количество библиотек за последнее время появилось, например, от Facebook.

    5. Компания делает продукт для конечного пользователя, которому достаточно наплевать, открыт ли код какого-то компонента продукта, которым он пользуется, или нет.


    Ну а это вовсе глупость:
    В свою очередь, IT-компании выделяют большую часть бюджета на платный софт. И в целях экономии на покупке и подписках на софт — пишут свои решения
    Время собственного разработчика стоит гораздо больше, чем чужой софт или железо. Иначе бы мы сейчас код оптимизировали, а не гигабайты памяти покупали.
    • 0
      Время собственного разработчика стоит гораздо больше, чем чужой софт или железо. Иначе бы мы сейчас код оптимизировали, а не гигабайты памяти покупали.

      Дороже при схеме деньги-продукт.
      В случае долговременных подписок на сервисы с малым функционалом, порой (не всегда) безопаснее и дешевле развернуть in-house решение. Благо в нашей вселенной имеется баланс между Open-Source и платными решениями, и почти всегда есть Free-функционал в платных решениях. И платные подписки на поддержку и дополнительный функционал в Open-Source решениях. Плюс аналоги платных решений имплементированные Open-Source сообществом. Одним словом — выбор у нас есть.
    • +2
      1. Нет. А если напишут, желание не пропадет, в любом случае нет запретов открыть свой форк с блекджеком и всем прилагающимся.
      2. Да, согласен. Open-Source — это работа и ответственность, и это отнимает время.
      3. см.п.2.
      4. Не совсем понял данный пункт. Facebook создают новые решения и делятся с миром, так же принимают pull-request'ы. Когда забрасывают старые проекты — дают жизнь чему-то новому.
      5. Смотря кто является конечным пользователем. Для меня (и нашей компании) это в основном разработчики.
      • 0
        Чем вам поможет форк онлайн игры или виртуальной машины .NET?
        • 0
          или виртуальной машины .NET?

          Спросите у контрибуторов Моно
          • 0
            Моно — не форк.
    • +2
      В какой-то момент компания может осознать, что работа с третьесторонним фреймворком, который она использовала много лет, обходится дороже, чем написание собственного. И опен-сорсный фреймворк забрасывается в пользу нового, проприетарного. Заметьте, какое огромное количество библиотек за последнее время появилось, например, от Facebook.


      Как-то противоречиво звучит. Огромное количество библиотек от Facebook как раз опенсорсные. Это компания решила сделать свои внутренние разработки открытыми, а не заменить открытые на закрытые.
      • 0
        До этого они долгое время оставались закрытыми.
        • +2
          Осознали стратегическую ошибку и исправились.
  • +16
    Однажды, выложив свой код на GitHub, я уже не смог остановится. Первым моим публичным репозиторием был PHP-код

    Сперва это «просто issue», но затем это переходит в серьезные пулл-риквесты… Каждый программист хоть раз пробовал коммитить код в опенсорс… Ты что, хочешь добиться того, чтобы гитхаб полностью стал зеленым?.. Все эти стары и вотчи — прямой путь в активные контрибьютеры… Он снова пытался контрибьютить в опенсорс… Да я сам видел, как ты пушил код! Я нашла твой новый форк в нотификейшенах. Нам нужно поговорить…
  • 0
    Вы спрашиваете про проекты, хотя сами пишете про выкладывание маленьких кусочков. Мне кажется про них и релевантней было бы спрашивать.
    • +1
      Позволил себе назвать маленькие кусочки — «Проектами». Связанно это с большими объемами работ по поддержке репозиториев с любым количеством строк кода — это issues, документация, pull-request'ы и публикация в package-менеджеры.
      P.S. Ваш предыдущий комментарий — я не понял.
      • +4
        Это юмор на тему сравнения опенсорса и наркотиков)
  • +30
    Open-source проект — это ответственность за качество кода, за покрытие его тестами, за документацию, за своевременные ответы на вопросы и реагирование на bug репорты, за обработку pull-request’ов.

    Нет. Opensource-проект — это просто публично выложенный код под соответствующей лицензией.

    У меня нет ресурсов и мотивации отвечать за его документацию, своевременные ответы, и так далее. Я выкладываю код именно что в надежде, что он будет кому-то полезным, но не более того. Ответственности и прочего счастья на работе хватает за глаза, а вне работы хочется что-то для души поделать.
    • +1
      Нет. Opensource-проект — это просто публично выложенный код под соответствующей лицензией.

      У меня нет ресурсов и мотивации отвечать за его документацию, своевременные ответы, и так далее. Я выкладываю код именно что в надежде, что он будет кому-то полезным, но не более того. Ответственности и прочего счастья на работе хватает за глаза, а вне работы хочется что-то для души поделать.


      Полностью согласен. В копилку добавлю от себя историю megamozg.ru/company/profishop/blog/22752
      • –1
        Нет. Просто публично выложенный код под соответствующей лицензией — это просто открытый код.
        А не opensourсe-проект, хотя он может им стать при наличии «ответственности»(поддержки/документации/сообщества и тп).
        • +7
          Это вы сами только что придумали. Открытый код это буквальный перевод словосочетания «open source». А open source — это вовсе не размытое понятие, а вполне определенный термин с четкими критериями, что под него попадает, а что нет: en.wikipedia.org/wiki/Open_source
    • –5
      Ужас какой, вы для души говнокодите?
      • +3
        Ну почему же сразу «говно-»? Неужто нежелание обеспечивать оперативные ответы, документировать софт и код (я стараюсь документировать только публичные API), собирать пакеты под распространённые дистрибутивы или поддерживать какие-то более старые версии компиляторов (это я уже отсебятины добавил по мотивам различных дискуссий) — говнокод?
        • –4
          Ну если это не говнокод, то он как минимум документирован, тестирован и форматирован. Если ваши open source проекты такие, то собсно это же и говорит автор.
          • +1
            Форматирован — да. Документирован — ну, так себе. Уровня doxygen-комментариев в хедерах API.

            Тесты — считайте, эффективно нет их, не везде они применимы (как написать тесты к коду для вычислительного эксперимента вроде такого?), а кое-какие проекты начинались тогда, когда я про тесты особо и не слышал. Да и сейчас я не сказать чтоб фанат тестирования.

            И автор говорит не только это.
            • 0
              По сути автор говорит именно про это + взаимодествие с сообществом.
              • 0
                И какая-то там ещё ответственность.

                Против этой ответственности и взаимодействия я и возражал же.
                • 0
                  это ответственность за качество кода

                  ну если вы будете взаимодействовать с обществом, то конечно на вас ложиться ответственность за качество кода. Общество будет запрашивать, решать будете вы.
                  • 0
                    если вы будете взаимодействовать с обществом, то конечно на вас ложиться ответственность за качество кода

                    Не вижу оснований для такой импликации, если честно.
                    • 0
                      Ну а кто будет кроме вас править ваш проект?
                      • +1
                        Никто, и мне вполне комфортно с этой мыслью.

                        Когда-то давно я тоже задумывался и беспокоился об ответственности, старался побыстрее отвечать на вопросы, испытывал чувство вины и угрызения совести, если вопрос в конференции, скажем, задали, пока меня не было, и ответить я не успел, и так далее. Раньше я переживал, что у меня нет мейнтейнеров под Debian и Ubuntu, что я слишком редко делаю релизы, что сайт у проекта какой-то непонятный, и надо бы до ума довести, и так далее.

                        А потом я как-то этим переболел, и всё это стало совершенно неважно. Я просто пишу код, я делаю это для души, не думая о пользователях, мейнтейнерах и документации, и это весьма положительным образом сказалось на моих ментальных ресурсах.
                        • 0
                          не думая о пользователях, мейнтейнерах и документации, и это весьма положительным образом сказалось на моих ментальных ресурсах

                          На ваших ресурсах то может и положительно сказалось, но комьюнити такой проект может и не получить. Да, это все еще Open Source.
                          • 0
                            Не получит — и ладно. Не вижу поводов для (моего) беспокойства.
                            • 0
                              Ну видимо автор о «популярном» Open Source.
    • 0
      Любая публичная деятельность — это ответственность (которая частично закреплена законодательно в частных случаях), например:
      • Текст в статье выше накладывает на меня ответственность за достоверность и актуальность информации, за качество передачи моих мыслей через текст, так же как и на обсуждение данного текста в комментариях, ответы на вопросы, уточнения.
      • Речь произнесенная по теле/радио-эфиру.
      • Текст напечатанный в прессе.
      • Текст в комментариях под интернет-контентом.
      • Слова произнесенные в кругу коллег/друзей (Вы же думаете что говорите? Сказав что-то некорректное вы понесете ответственность в виде потери друзей или рабочего места).


      Другой момент — многие не понимают отвественности. К любому виду деятельности можно подойти безответственно. Есть люди которые все в течение своей жизни делают безответственно, — это вовсе не означает, что следует делать так же.

      Никто не осудит Вас, если в readme.md Вы укажете что проект только для Вашего личного пользования и другим он не будет интересен, так как несет в себе пользу только для Вас. Или на проекте который был заброшен — что он больше не поддерживается Вами, кто-то другой может увидеть интерес в проекте, и возродит его, уже без Вашего участия.
      • 0
        Вероятно, корректнее было бы говорить не об ответственности, а о наличии последствий.

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

        Если я не буду оперативно предоставлять ответы и далее по тексту, то какие последствия меня ждут? Если у моего проекта совершеннейше уродливый UI, какие последствия меня ждут? Если я не пишу документацию, какие последствия меня ждут? Я себя не позиционирую как техсаппорт, дизайнер, юзабилист или technical writer, если что.

        Иными словами, почему это всё входит в сферу моей ответственности как программиста?

        Никто не осудит Вас, если в readme.md Вы укажете что проект только для Вашего личного пользования и другим он не будет интересен, так как несет в себе пользу только для Вас.

        Зачем это указывать? Что плохого случится, если я это не укажу? Да и пусть люди сами решают.
        • 0
          Нет, просто п. 2, 3, 4 законодательно регулируются.
          А остальные пункты регулирует окружающая Вас аудитория.
          Да и пусть люди сами решают

          Согласен, люди сами решат. Но это не означает, что в обществе не существует, общепринятых норм и стандартов.

          Вы можете написать код именуя переменные, классы и методы как Вам угодно, не соблюдая отступов и забывая ставить терминаторы, которые не обязательны в Вашем языке — и он может одинаково работать как «правильно» и «красиво» написанный код.
          • 0
            Нет, просто п. 2, 3, 4 законодательно регулируются.

            Таки потому, что они законодательно регулируются, я и сказал, что это отдельная история.

            Но это не означает, что в обществе не существует, общепринятых норм и стандартов.

            А где эти общепринятые нормы и стандарты почитать? А то мне вот совершенно неочевидно, что ваша версия ближе к истине, чем моя, например.

            Ну и опять же, про последствия вы не ответили. В чём именно-то ответственность заключается?

            Вы можете написать код именуя переменные, классы и методы как Вам угодно, не соблюдая отступов и забывая ставить терминаторы, которые не обязательны в Вашем языке — и он может одинаково работать как «правильно» и «красиво» написанный код.

            Могу, но я так почему-то не делаю. А вот некоторые иные обязанности из перечисленных вами в исходном посте я не хочу на себя брать.
            • 0
              А где эти общепринятые нормы и стандарты почитать?

              У общества спросить, которое Вас окружает (Честно, не знаю где почитать).

              Для Вас неочевидно присутствие ответственности за ведение open-source проекта, ровно на столько же, на сколько неочевидно зачем писать «правильно» и «красиво» код, для тех кто его пишет «не правильно» и «не красиво» — но он же работает (этот код), зачем тратить время на придумывание «правильных» имен переменным, и т.п.

              Ну и опять же, про последствия вы не ответили. В чём именно-то ответственность заключается?

              Заранее извиняюсь что отвечаю вопросом на вопрос, но — «В чем ответственность заключается при «правильном» написании кода?»
              • 0
                Но при этом я могу попытаться аргументированно объяснить человеку, пишущему «не красиво», почему писать «красиво» — хорошо.

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

                А, ну и ещё эстетика, да, но это субъективно. Мне просто неприятно писать некрасивый код, не для души это.

                О, у меня тут тоже вопрос родился. Вы, судя по профилю, на JS пишете, или около того. А почему вы пишете на JS, а не на каком-нибудь «правильном» «красивом» типобезопасном языке вроде Haskell?
                • 0
                  В основном пишу на «правильных» и «красивых» CoffeeScript и TypeScript («типобезопасном»).
                  По факту мне удобно писать на любом языке, благо документации и рекомендаций по стилистике и «правильному» написанию кода имеется в избытке. Опыт был с Go, PHP, C#, Objective-C, совсем немного Java и другие классические языки как Bash, Basic и т.д.
                  В моей истории был период с написанием «не правильного» и «не красивого» кода, но в какой-то момент мозг переключился и отказался писать и воспринимать «говно-код». Подобная история произошла и с Open-Source.
                  • 0
                    Видимо, у меня просто ценности какие-то не те, раз тот социальный аспект опенсорса, о котором вы говорите, мне не доставляет удовольствия.
                    • 0
                      Мы должны научится не только потреблять, но и отдавать обществу.
                      • +2
                        Выкладывать свой код под какой-нибудь BSD-лицензией — уже достаточно «отдавать», ИМХО.
  • +9
    Открытый код — это сохраненное время. В нашей жизни мало уникальных задач, многие задачи решаются многократно разными умами с разных сторон. Возможно, тот способ, которым вы сегодня реализовали сортировку окажется достаточно быстрым, удобным и понятным, чтобы другой человек смог его просто взять и использовать. Или осознать его и переделать под свои нужды. Таким образом он съэкономит свое время не реализуя повторно эту самую сортировку.

    Открытый код — это открытая реализация идеи. Кто-то сел и сказал: а клево вот так делать сортировку. А затем кто-то сел и написал на каком-то языке программирования реализацию этого метода сортировки. А кто-то взял и переписал то же самое на другом языке программирования. А еще кто-то увидел это и написал заметку на Хабр как на языке программирования работает алгоритм сортировки и как его использовать в проектах. При этом каждый не тратил столько времени, сколько ему бы потребовалось если бы он делал все сам: и придумывал метод сортировки и реализовывал его алгоритм на языке программирования и затем еще всем ходил и рассказывал какой метод клевый и используйте его в своих проектах.

    Когда я выкладываю код в открытый доступ — я выкладываю свое время, свои часы, минуты, дни, потраченные на решение какой-то задачи для других. При чем это необязательно все придумал сам, а взял там и там, написал, собрал, обернул, добавил опций. Чтобы другие не тратили свое время, а взяли то, что есть у меня и попробовали использовать: получилось — отлично, не получилось — жаль, надеюсь они найдут свое решение за приемлемые сроки.

    Должен ли я поддерживать, обучать, вести документацию? Должен себя и семью кормить. А всё остальное зависит от мотивации. Если это актуальный проект, у меня есть интерес и я рад вопросам, то могу и статью написать, и на вопросы ответить. Если я охладел к проекту, то, возможно, интерес подогреть может материальный стимул. А если я совсем потерял интерес к проекту, то уж, извините, это моя жизнь — и так немало моего времени уже лежит в открытом доступе, а я может быть хочу еще чего-то сделать и достичь, кроме этого «метода сортировки».

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

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

    Иногда люди выкладывают проекты, которые «не взлетели». Достойное решение. Ибо кто-то из обломков старых холодильников выдирает рабочие компрессоры, а кто-то может выдернуть из такого проекта полезные скрипты, структуры, сделать выводы и запилить свое решение, опять же экономя свое время.
  • 0
    Максимально-требовательный подход к написанию кода, документации и тестов.


    Возможно, вы к этому пришли поизучав код критически важных для мироздания проектов типа kernel, gcc. Это проекты production уровня, там все на уровне. А сколько еще в open source существует всего другого, криво понаписанного? Про документацию все то же самое. Даже некоторые либы высокого качества исчерпывающей документации по фичам не содержат.
    • +1
      Криво написанное или спроектированное обычно долго не живёт — его никто кроме автора поддерживать не захочет, а автор скорее всего забьёт в итоге на своё «детище».
  • +1
    Люди, которые отвечают «Да» в первом опросе — где вы?
    Я по совместительству на работе провожу техническую часть собеседований, и еще ни разу никто не сказал, что он имеет свой Open-Source проект, а человек 100 точно было в сумме.
    • 0
      Тоже интересно.

      Ну и кажется, автор слабо себе представляет, что такое поддержка проекта даже от 1К звезд, радости увы там мало, а времени требует много.
      • 0
        Константин, поделитесь опытом по поддержке Sortable и FileAPI
        • +1
          Да не чем особо делится, могу сказать только одно, Issue радуют только первый год, но после набора критической массы, они превращаются в головную боль (в среднем от 1 в день и это не баги). Многие даже не хотят читать ваши доки или подумать, как можно на основе текущих возможностей, решить свою задачу и лепят очередной issue, в котором хотят, чтобы вы решили задачу. Конечно можно ответить на словах «как нужно сделать», но это тоже самое, что и спрограммировать, вы уже потратили время на задачу, её осмысление и решение, так что обычно решение, это готовый код.

          Но в целом, OpenSource (настоящий, не для себя, а для других) очень сильно помогает вырасти как вам, так и вашему проекту. На ранних этапах он поможет улучшить качество кода, переосмыслить api, увидеть альтернативные пути развития и применения, которые просто не пришли вам в голову, да и в целом можно посмотреть, как люди использую ваше детище (Например на Sortable, один чувак сделал игру крестики-нолики 0_o, а это ведь всего лишь либа для сортировки).

          Вот с FileAPI всё проще, инструмент с самого начало задумывался низкоуровневым, а не очередным плагином к jquery и подобным коробочным решением, поэтому его в основном используют опытные разрабы, которые в случае чего, могу грамотно описать проблему.

          P.S. Да, и возможно я не везучий, но настоящих PR крайне мало, либо это правки README.md ;]
          • 0
            Ох уж эти правки README.md Даже удивительно, что те, кому нравится ваш продукт не хотят сами в него вложить ничего. Найти бы какой-либо способ замотивировать слать стоящие PR.
            • 0
              Сделать проект (которым ты сам пользуешься) «лучше и быстрее» — не достаточная мотивация?
              RubaXa видимо создал идеальный проект «по коду», который не требует изменений
              • 0
                Ха-ха, если бы, 100+ задач говорят об обратном :]
                — 12 требуют помощи;
                — 43 по Метеору (а поддерживать его некому);
                — 38 тупа не разобраны, либо не понятно что это такое?!;
                — и т.д.

                А вы говорите «идеальный».
                • 0
                  Это был <sarcasm />, идеальных проектов просто — нет.
                  Не знаю почему, но я уверен, что пережитые эмоции связанные с данным проектом, Вы бы не променяли, ни на что.
    • 0
      Люди, которые отвечают «Да» в первом опросе — где вы?

      Здесь. Вот для примера мой проект. github.com/forramil/profishop
    • 0
      Присоединяюсь, вот мой проект: TARS
    • +2
      Не повезло вам с кандидатами ) Нас много, очень много.
      Кстати, у меня другая проблема — Open Source проектов много, но ни один работодатель ни разу не посмотрел ни один из этих проектов. Просто услышали что проекты есть и забыли.
      • 0
        Имеет место быть проблема с работодателями, которые не придают значения open-source или категорически против таких течений.
        Нередко в крупных компаниях (как в России так и в других странах) боятся брать на работу разработчиков поддерживающих популярные open-source проекты. Так как по их мнению они могут использовать код (или его часть) написанный в стенах компании внутри своих open-source проектов, что будет приравнено к разглашению коммерческой тайны. Только вот вопрос где грань? Если я объявляю переменные с одинаковым названием?

        По поводу поиска работы — 50/50 где-то с интересом (или обязательно) рассматривают все репозитории во время собеседования, а где-то могут ответить, что им все равно и это баловство, а не программирование.

        По поводу поиска сотрудников (по своему опыту говорю только про Москву) — только каждый 4 собеседуемый кандидат за последние 3 года имел свой полезный репозиторий (рабочие репозитории есть почти у всех).
        • 0
          Скорее, не берут по другой причине. Недооценивающий или не умеющий продать себя инженер может работать примерно так же (а то и лучше, иногда может и по ночам), а стоить в два раза дешевле.
          • +1
            Данный аспект характерен для СНГ и России — экономия на IT-персонале ни к чему хорошему не приводит, вот известный пример: habrahabr.ru/post/273249
            • +2
              Я бы сказал даже, экономия на любом квалифицированном персонале к хорошему не приводит. С другой стороны, собрать команду звёзд тоже надо не всем и не всегда, гигантам вроде гугла это под силу, стартапам не особо, и не очень-то и надо, когда можно найти неплохого среднего программиста и платить ему нормальную зарплату.
        • 0
          А что есть «полезный» репозиторий?
          • 0
            «Полезный» репозиторий в моем понимании — это репозиторий содержащий код и/или текстовую информацию из которой можно получить пользу.

            Проще описать «не полезный» репозиторий — это репозиторий без документации, без описания, содержащий нечитаемый код или код который не возможно или не имеет смысла повторно использовать.
            • 0
              Ну многие считают, что ВУЗ дает достаточно знаний для работы, затем приходят с дипломом в руках и мыслями в голове — я закончил ВУЗ, сейчас мне будут платить
              • 0
                Сколько людей, столько и мнений.
                Уверен что бывшим студентам новые коллеги быстро объяснят как все устроено, — жизнь всех научит.
    • 0
      Мои успехи на этом поприще достаточно скромны, но тем не менее…

      Тренажёр для подготовки к ЕГЭ: github.com/nickkolok/chas-ege
      Подробности
      Если не пилить — владельцы reshuege.ru окончательно вобьют в головы абитуриентов фразу «копирование = воровство», пруф: reshuege.ru/about
      В настоящее время используется не то чтобы очень активно, но трепыхается (хотя даже Яндекс уже сдался). Статистика: www.liveinternet.ru/stat/math.vsu.ru/chas-ege/referrers.html, где ege_ok.referrer — это ege-ok.ru
      Кроме собственно заданий, кто-то может найти полезными склонялку существительных и математические библиотеки (типа умножения многочленов).
      Школьники и студенты, желающие контрибьютить — велкам, nickkolok@mail.ru, есть инструкция.
      Также как вариант — для организации лаб по JS.


      «ЧАС-коррект»: github.com/nickkolok/chas-correct, была статья на Хабре.
  • +7
    Спасибо за статью, как по мне на немного идеалистична получилась.

    Есть хорошая картинка на тему стереотипов в open-source разработке
    image
    • 0
      На популярных проектах почти как на первой зарисовке, только каждый в своей комнате в своем одиночестве,

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Интересные публикации