VS: Companies Contributing to Open Source

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема VS: Companies Contributing to Open Source
Дата
Msg-id 51494DB187D98F4C88DBEBF1F5F6D42312116F@edb06.mail01.enterprisedb.com
обсуждение исходный текст
Ответ на Re: Companies Contributing to Open Source  ("Joshua D. Drake" <jd@commandprompt.com>)
Ответы Re: VS: Companies Contributing to Open Source  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
<p><font size="2">Jonah Harris wrote:<br /> > We could also mention all the Ingres-based offshoots that were<br />
>commercial.  Let me think of some other examples... but there may not<br /> > be that many seeing as there
aren'treally that many PostgreSQL-like<br /> > communities.  I guess I could mention more if I had a clear<br />
>understanding of what we mean when we say, "community".<br /><br /> That's something that bothers me as well: The
articleand the discussions talks about the community, but what's The Community? There really isn't any clear
definition,the closest thing is the list of committers or core members, but I don't think anyone considers The
Communityto be just the committers, though that's the group of people whose opinions matter the most when trying to get
apatch accepted. I don't think it's fruitful to spend time on a precise definition, but it's important to realize that
thereisn't one and that the community consists of individuals with different priorities, opinions and points of view.
Thereforeit's a bit meaningless to say that The Community thinks this or The Community says that. On one topic, some
peoplemight have a very strong opinion one way, and others might just not care at all. On some topics, everyone agrees.
Andon some topics, people strongly disagree. And that's ok. Respecting all the different viewpoints leads to a
well-balancedproduct.<br /><br /> How does that affect a company trying to get a patch accepted? First, do no harm. If
you'reproposing something that for example brakes someone else's application, your proposal is likely to be rejected.
Orif you're proposing a patch that increases the performance of something, at a very high cost on some other things,
yourpatch is likely to be rejected. Another kind of harm that many people miss is the maintainability of the codebase.
Addingcomplexity for little gain is likely to be rejected, just because it'll make the code harder to read.<br /><br />
Secondly,getting a large feature accepted is easier if you're not just dumping a large patch to pgsql-patches, but
you'recommitted to maintainting it and developing it further. Remember, some  things you might have ignored as not
importantmight be crucial to other people.<br /><br /> Also, a note to all Members of The Community: people like to
workin different ways. Some might want to seek acceptance and commitment to a feature from others before starting
development.Some might want to write a large up-front design document before proposing something. Some might want to
writean experimental patch with a lot of quick hacks and no comments, and refine that according to feedback. And we,
TheMembers of The Community, if I may count myself as one, don't get to choose how others prefer to work.<br /><br />
--<br/>  Heikki Linnakangas<br />  EnterpriseDB   <a
href="http://www.enterprisedb.com">http://www.enterprisedb.com</a><br/></font> 

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kenneth Marshall
Дата:
Сообщение: Re: column ordering, was Re: [PATCHES] Enums patch v2
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: column ordering, was Re: [PATCHES] Enums patch v2