Что думать о при создании открытого исходного кода проекта? [закрытый]
Когда Вы сталкиваетесь с ошибкой во время бета-версии Вашего приложения и не можете воспроизвести его, Вы знаете, что необходимо было сделать чрезмерный вход. Тот же путь, если клиент сообщает об ошибке, но Вы не можете воспроизвести его чрезмерная функция входа, может спасти положение.
3 ответа
По моему очень скромному мнению:
1) Если вы настроены переходя на открытый исходный код, гордитесь своим кодом. Все мы знаем, что на пути встречаются ошибки и недоработки. Их тоже будет больше, так что не думайте, что вы не можете выставить их публично. Можно!
2) Определенно. Возможно, и в этом порядке, потому что именно в таком порядке люди, использующие ваш продукт, будут их читать. Им придется использовать ваше программное обеспечение, прежде чем они решат работать над ним.
3) Лучший совет, который я могу дать, - это иметь четкие инструкции по сборке, надеюсь, со сценариями, которые помогут людям настроить среду. Распространенная проблема программного обеспечения с открытым исходным кодом требует, чтобы новые разработчики загружали тонны библиотек и настраивали свои устройства для работы именно так , чтобы иметь возможность создавать программное обеспечение. Это меня очень расстраивает и может очень быстро отпугнуть.
Удачи!
Выбор полностью за вами, если только вы не использовали защищенный авторским правом код, на распространение которого у вас нет прав, или если возникла проблема, связанная с перераспределением, ссылкой и т. Д.
Трудно сказать, не зная, что это. Что вам понадобится для его использования? Что бы вы хотели увидеть в первую очередь? (Вероятно, учебник ...)
Возможно, пример от начала до конца, включая установку. Возможно, вам стоит попробовать запустить его в виртуальной среде или при установке новой ОС, чтобы вы были уверены, что ваши инструкции по установке справятся со всем.
- Должно быть достаточно легко объединить несколько коммитов, и усилия того стоят. Разработчики часто просматривают историю, чтобы понять, как создавался проект с нуля.
- Определенно. По крайней мере, вы можете получить какой-нибудь механизм документации, такой как Doxygen, для создания документации. В этом руководстве, вероятно, нет необходимости; сообщество напишет для вас учебные пособия при условии, что код хорошо документирован.
- Хорошая упаковка всегда помогает. Создавайте предварительно скомпилированные двоичные файлы для более чем одной архитектуры и, если возможно, создавайте пакеты RPM и DEB. Это значительно снижает входной барьер. Никто не вносит свой вклад в программное обеспечение, которое они не используют. Вы также можете использовать хороший трекер ошибок, такой как Bugzilla, или использовать интегрированное решение, такое как Launchpad или Trac. Также настройте список рассылки и канал IRC. Это поможет создать сообщество.