Вопрос поставлен не корректно — OpenSource это любой проект с исходным кодом и не важно как он распространяеться. Я, к примеру, пишу на РНР и мы выдаем заказчикам в основном исходный код. Вот вам и ответ «Да»…
Есть одна закрытая windows-софтина, которая под вайном работала хм… коряво в общем. Пользоваться можно, но очень неудобно. Шевелил разработчиков, тестировал, сообщал о багах.
Когда разработчики перестали реагировать на багрепорты стал учить C, изучать код вайна, изучать MSDN и фиксить баги. В коде вайна уже 11 моих патчей (исправляющих 9 багов), это, конечно, совсем немного, но для человека, который никогда раньше не писал на C и не использовал WinAPI это заметный результат.
P.S: когда начал заниматься этим делом, в голове крутились мысли: Си и WinAPI это всегда так страшно, или это так только в вайне? :)
>Ещё интерсный вопрос для тех, кто ответил «да»: Зачем вы это делаете?
Тут всё сложно :)
Началось как ответ одному товарищу в споре «да блин, на С++ гуй писать просто нереально, замучишься всё руками фигачить, а вот в Delphi....». В качестве ответа был за полчасика-час набросан простой текстовый редактор на Qt с функциональностью а-ля Блокнот из ВинХР. Потом случайно увидел пример, как в Qt делается подсветка кода и прикрутил чисто ради практики. Потом понял, что им вполне уже можно пользоваться, что я и начал делать. Ну и понеслась… :) Результат тут.
C++ — это язык программирования. При чем тут GUI? А дэлфи? Это просто VCL, где гуй лекго ваяется. Некоторые на чистом winapi и на дэлфи пишут, там что не запаришься гуй делать? Разве Borland C++ c VCL не работает? Тот же самый дэлфи… и в нем блокнот можно за 15 минут сделать.
С++ есть и в .NET. Разве нет? Там тоже нет заморочек с гуем.
Еще раз.
С++ — язык программирования, а легкость создания гуя к нему не привязывается, это скорее прерогатива Фреймворков, среды программирования и т.п.
Не хватает пункта «Да/нет, изредка посылаю патчи». Вроде и есть навыки, и нужно, но расходы времени на участие в команде не позволяют положительно ответить на первые три вопроса.
Недавно в рамках одновременно работы и учебы начал работать над аналогом Cucumber для Python.
Тулза для Behaviour Driven Development, призванная упростить и сделать приятным процесс написания unit-тестов.
Все будет в OpenSource.:)
Всё просто: нужно только взять и начать делать :) Как показывает практика, мучения на тему «как подступиться» могут тянуться практически до бесконечности, если не найти необходимость (существующую или придуманную) в работе над открытым проектом :)
А вы сначала решите для себя, чем хочется заниматься, и занимайтесь. Для начала я бы рекомендовал какой-нибудь молодой проект или подключиться к разработке какого-нибудь модуля для уже работающей системы. Так вы сразу же убьете двух зайцев:
1. быстрее вникнете в код, процессы, методы работы
2. поймете, нужно ли вам это все вообще
Писал пару патчей в один опенсорс проект, для него же писал багрепорты. Для другого писал только багрепорты и реквесты новых фич. Сейчас потихоньку пишу небольшой проект, который собираюсь выкладывать на code.google. Основная проблема — это нехватка времени.
Раньше как видел баг — писал багрепорты, с логами, с попыткой проанализировать ситуацию. Только годы идут, а баги, так и остаются непофиксенными, например в Файерфоксе. Причём периодически с багзиллы мне приходит спам, что добавлен новый коммент в ваш баг.
Как-то вышло до курьёза — описал кучу багов в одной ГУИшной софтине и, резюмируя, сказал, что надо использовать паттерн MVC для таких интерфейсов, иначе можно до опупения бороться с глюками. На что получил ответ, что, мол, развелось тут вумных, типа не нравится — не жри.
Простите за банальности, но, судя по некоторым комментариям, тут некоторые не знают базовых вещей, поэтому этот комментарий в основном для них.
В OSS никто никому ничего не должен. Фиксить баги отнюдь не так интересно, как добавлять фичи. Поэтому, когда нужно чтобы конкретно Ваш баг был исправлен нужно не просто отправить багрепорт, а принимать деятельное участие в его выявлении, отладке, тестировании, и вообще постоянно теребить общественность и напоминать, что есть ещё люди, которым судьба бага небезразлична. В частности, нужно тестировать новые версии продукта на наличие этого бага, тестировать версию с багом на разных платформах, пытаться уточнить описание бага насколько возможно используя утилиты вроде strace/ltrace/gdb, интересоваться наличием workaround-ов, etc. И ни в коем случае не использовать некорректный тон в стиле «ага, вы тут налажали!!!» или «ваше глюкало снова у меня упало на тривиальной операции» (хотя иногда сложно от этого удержаться).
Общее правило — если Ваши действия воспринимаются разработчиками как деятельная попытка помочь им улучшать продукт — вероятность что баг будет исправлен более-менее оперативно (или будет предложен workaround) повышается на порядок.
Вы специально именно про _опенсорс_ спросили или вы не видите разницы между свободным и открытым? Линукс вообще-то не просто открытый — он свободный. (К.О.)
Работаю над биндингом Qt для D. Багрепорты пишу редко, наверное потому что ленюсь или не всегда время хватает. Хотя если сталкиваюсь с багом или отсутствующей фичей возникает мысль, я наверняка не первый, и кто-то за меня это сделает :) Если и пишу баги — в основном в KDE или Ubuntu. Ну и конечно в разные D-related проекты тоже.
Хочется еще поучаствовать в написании компилятора, да и вообще интересных тем для проектов предостаточно, но времени на все катастрофически не хватает.
Вы приниаете участие в разработке OpenSource-проектов?