Как проектами с открытым исходным кодом управляют [закрытые]

Вы переназначаете свои параметры здесь:

test::test(int a,int b){
    a=a;  // You just set parameter a to its own value!
    b=b;
}

не совпадает с:

test::test(int a,int b){
    this->a=a;
    this->b=b;
}

и должно быть заменено:

test::test(int a,int b) : a(a), b(b) {}

вместе.

6
задан Matt J 6 April 2009 в 13:56
поделиться

6 ответов

Это - трудный вопрос для ответа, потому что "проекты с открытым исходным кодом" очень широкий выбор проектов. Я думаю, что характеристика определения является проектом, имеет единственную цель объединения (возможно, ряд связанных целей).

Вы находитесь в каких-либо списках рассылки с открытым исходным кодом? Я подписан на список рассылки своего любимого дистрибутива и электронное письмо разработчиков друг друга много раз день. Кроме того, существуют другие проспекты коммуникации, такие как IRC / Пейджер.

Я не разработчик RoR, но я предложил бы скользить посредством Возвращения к реальности для некоторого вдохновения.

2
ответ дан 8 December 2019 в 17:27
поделиться

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

Выбрать один пример. В сообществе Python они называют Guido van Rossum Доброжелательным диктатором для жизни (BDFL). Его слово является (более или менее) окончательным. Во многих случаях существуют люди, не соглашаются с ним - но ради сообщества Python - они, кажется, соглашаются на его суждение.

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

Назад в былые дни, Fred Brooks (Мифический Месяц Человека) описанные "команды главного программиста". То же понятие. Кто-то отвечает за техническое содержание. Акцент на тот. В наше время мы вызываем "архитектора" или некоторый такой термин.

4
ответ дан 8 December 2019 в 17:27
поделиться

Никакая реальная методология здесь, но я думаю, что 2 вещи важны:

  1. Имейте четко определенные цели и обязанности.
  2. Позвольте каждому разработчику иметь последнее, говорят в том, как их выделенная часть должна быть сделана.

В проектах с открытым исходным кодом единственная реальная и самая сильная мотивация является забавой, которая будет иметься, кодируя продукт. Касаясь № 2 выше, если людям говорят, что сделать, и они не соглашаются с ним, мотивация начинает недоставать. Конечно, всегда будет немного компромисса как в любом другом типе отношений.

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

3
ответ дан 8 December 2019 в 17:27
поделиться

Мое предположение - то, что Ваши частные проекты все выполняются и кодируются разработчиками. Разработчики, как известно... сохраняют разработку. Большая разница, по моему опыту, то, что компания испытала менеджеров, которые могут определить, когда вещи СДЕЛАНЫ. Я рекомендовал бы поместить кого-то на задачу определения целей и решил бы, когда вещи сделаны.

2
ответ дан 8 December 2019 в 17:27
поделиться

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

У Linus были некоторые довольно известные проблемы с той же проблемой. Примите во внимание этот поток с 2006: Разговор является дешевым. Покажите мне код.

Еще одна вещь. Так как Вы говорите в комментариях, что у Вас действительно есть код, просто много из переписывает, я высоко предположил бы, что Вы читаете Eric Raymond Собор и Bazzaar. Немного псих Eric на самом деле, но эссе является бесценным для любого желающего выполнять проект Бесплатного программного обеспечения.

2
ответ дан 8 December 2019 в 17:27
поделиться

У меня было бы думание о Ваш и Ваша мотивация помощника команды и цели в этом проекте. Они к:

a) Создайте потрясающий продукт

или

b) игра вокруг с программным обеспечением, и изучает некоторые новые вещи

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

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

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

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

Удачи.

1
ответ дан 8 December 2019 в 17:27
поделиться
Другие вопросы по тегам:

Похожие вопросы: