Author: vlad.shcherbakov
Date: Wed Oct 15 14:44:10 2008
New Revision: 1522
Log:
still translating first chapter
Modified:
trunk/ru/ch01.xml
Modified: trunk/ru/ch01.xml
==============================================================================
--- trunk/ru/ch01.xml (original)
+++ trunk/ru/ch01.xml Wed Oct 15 14:44:10 2008
@@ -42,8 +42,9 @@
<para>Эта книга посвящена тому как избежать провала. В ней описано не только
как нужно правильно делать что-либо, но и как <emphasis>не</emphasis> делать,
так чтобы
- вы научились распознавать и разрешать проблемы на раннем этапе их появления.
-Успех проекта это не игра со счетом в ничью, и эта книга вовсе не о том как
выйграть
+ вы научились распознавать и разрешать проблемы на раннем этапе их появления.
Я надеюсь, что после прочтения этой книги, вы обзаведетесь
+ большим арсеналом методов, которые позволят вам не только не наступать на
наиболее частые
+ грабли разработки свободного ПО, но и также, как считаться с ростом и
поддержкой успешного открытого проекта. Успех проекта это не игра со счетом в
ничью, и эта книга вовсе не о том как выйграть
или выйти вперед в конкуренции. Наоборот, важной частью ведения открытого
проекта
является крепкое сотруднечество с остальными, связанными или похожими(!)
проектами.
В конечном счете, каждый успешный проект делает вклад в благополучие
всецелого, мирового фонда свободного програмного обеспечения.
@@ -54,19 +55,16 @@
<simplesect>
<para>
-Было бы заманчивым(tempting) сказать, что причины неудач свободного ПО те же
-что и у коммерческих проектов. Я надеюсь, что после прочтения этой книги, вы
обзаведетесь
- большим арсеналом методов, которые позволят вам не только не наступать на
наиболее частые
- грабли разработки свободного ПО, но и как считаться с ростом и поддержкой
успешного открытого проекта.
- На эти темы уже написаны горы литературы и, в своей книге, я постараюсь
избежать повторений
- ранее известного.
-
+Было бы заманчивым(tempting) сказать, что причины неудач свободного ПО те же
что и у коммерческих проектов.
+Разработка свободного ПО не означает отсутствие таких проблем, как
+завышенные требования, расплывчатые спецификации, неэффективное управление
кадрами и других сложностнй давно известных индустрии
+разработки ПО.
+ На эти темы уже написаны горы литературы и, в своей книге, я постараюсь
избежать повторений ранее известного.
Вместо этого, я хочу
описать проблемы характерые только для свободного ПО.
-
Когда свободный програмный проект начинает рушиться, это часто потому что
разработчики
(или мененджеры) не учли уникальных проблем открытого програмного обеспечения,
даже будучи
- основательно подготовленными к более известным проблеммам присущим лишь
коммерческому ПО.
+ основательно подготовленными к более известным проблеммам присущим
коммерческому ПО.
</para>
<para>Одной из наиболее распрастраненных ошибок является слишком большие
надежды возлагаемые
@@ -75,8 +73,8 @@
проблем затрудненного проекта и простым открытием его исходников. Как раз
наоборот: раскрытие проекта
может принести целую кучу дополнительных сложностей, и дороже стоить, с
расчетом на короткий срок,
чем было бы, оставайся он закрытым. Раскрыть проект означает переорганизовать
код так, чтобы он был
-понятен новым разработчикам, не знакомым с вашим проектом, создать официальный
веб сайт проекта и настроить
-списки рассылки(email lists), а также нередко первый раз взяться за написание
документации. Все это
+понятен новым разработчикам, незнакомым с вашим проектом, создать официальный
веб сайт проекта и настроить
+списки рассылки(email lists), а также нередко впервые взяться за написание
документации. Все это
много работы. И если и появятся заинтересованные разработчики, еще к этому
добавится и бремя отвечать на
кучи их вопросов, прежде чем от них будем какая-то польза от их присутствия.
Как выразился Jamie Zawinski о ранних турдных временах проекта Mozilla:
@@ -91,8 +89,8 @@
<para>
-Также схожей ошибкой является экономия на презентации и комплектации, наивно
полагая
-что это всегда можно оставить на потом, запозно после начала проекта.
Презентация и комплектация
+Также распространённой ошибкой является экономия на презентации и
комплектации, наивно полагая
+что это всегда можно оставить на потом, уже задолго после начала проекта.
Презентация и комплектация
заключают в себе широкий круг задач, посвященных теме упростить вступление в
проект потенциальным
разработчикам.
Сделать проект более привлекательным можно при помощи написания руководств для
пользователей,
@@ -100,127 +98,124 @@
возможно автоматизировать процессы компиляции установки и т.д.
Многие программисты к сожалению считают это второстепенной задачей после
написания кода.
Есть несколько причин почему. Во первых, это может показаться трудной работой,
потому что
-преимущества от этого заметны(ощутимы) лишь тем, кто менее знаком с проектом и
наоборот.
-
-В конце концов, людям написавшим код не нужна ни какая комплектация.
+преимущества от этого заметны(ощутимы) лишь тем, кто меньше всего знаком с
проектом и наоборот.
+В конце концов, людям написавшим код не нужна никакая комплектация.
Им уже известно как устанавливать, администрировать и использовать их
-собственное ПО.
-Во-вторых, умения необходимые для того чтобы создать презентацию и
комплектацию,
+собственное ПО. Во-вторых, умения необходимые для того чтобы завершить
презентацию и комплектацию,
далеко отличны от тех что нужны для написания кода.
Люди склонны концентрироваться на том, что они лучше знают, даже
если немного времени проведенного над тем, что им кажется менее важным,
помогло бы проекту гораздо больше.
- <xref
-linkend="getting-started"/>
-Презентация и комплектация обсуждаются в подробностях, объясняется почему так
важно чтобы они были приоритетом
-с самого начала проекта.
+
+В главе
+<xref
+linkend="getting-started"/>, презентация и комплектация обсуждаются в
подробностях и объясняется почему так важно чтобы они были приоритетом
+с самого начала проекта.
+
+</para>
+
+
+<para>
+Следующим идет заблуждение, что свободному проекту нужно мало либо не нужно
+совсем никакого руководства, или наоборот, что теже принципы управления,
используемые
+для разработки впределах коммерческой организации, могут быть применены с тем
же
+успехом и в открытом проекте. Управление внутри свободного проекта не всегда
+так уж заметно, но в успешных проектах, оно обычно происходит за сценой
+в той или иной форме. Достаточно небольшого мысленого эксперимента, чтобы
увидеть почему.
+Типичный свободный проект состоит из произвольного набора
программистов—что уже заведомо
+непредубежденная группа людей—, скорее всего незнакомых лично друг с
другом,
+каждый из которых, возможно преследует собственные личные цели в работе над
проектом.
+Представьте себе чтобы произошло с такой группой людей <emphasis>безо
всякого</emphasis> руководства.
+Если только не чудо, они бы претерпели крах либо разошлась кто куда довольно
быстро.
+Дела не будут вестись сами собой, насколько нам того бы ни хотелось.
+Но руководство в открытом проекте, даже будучи активным, зачастую лишь
информотивно, неуловимо и неброско.
+Единственное, что держит группу разработчиков вместе так это их раздельное
+убеждение, что они могут достигнуть большего согласованной группой, нежели по
отдельности.
+Таким образом целью руководства, по большей мере является, поддерживать это
+убеждение, устанавливая стандарты коммуникации, следя чтобы полезные
разработчики <emphasis>не</emphasis>
+оказывались изолироваными вследствии личных особенностей их характеров, и
вообщем просто делая
+проект таким местом, куда бы хотелось возвращаться снова и снова. Конкретные
способы достижения
+этого и рассмотрены на протяжении всего остатка этой книги.
</para>
-<para>Так же распространённой ошибкой является недостаточное (presentation and
-packaging, figuring) которыми которые всегда можно сделать позже, в процессе
-разработки проекта. (Presentation and packaging) включает в себя множество
-задач, направленных на уменьшение порога вхожнения(?).
-Для того, чтобы сделать проект привлекательным для новичков(uninitiated means)
необходимо (.........)
-написание документации для пользователей и разработчиков, создание веб-сайта
проекта,
-содержащего достаточно информации для (newcomers), максимальная автоматизация
компиляции и установки и т.д.
-К сожалению, многие программисты считают эту работу второстепенной по отношению
-к написанию кода программы. Для этого есть несколько причин.
- Во-первых, it can feel like busywork, из-за того, что benefits are most
-visible to those least familiar with the project, и наоборот.
-Кроме того, для людей занимающихся разработкой кода не нужно (packaging).
-Они уже знают как установить, настроить и использовать программу
-потому что они её написали. Во вторых, для (presentation and packaging)
-нужен более высокий уровень подготовки, чем для написания написания кода.
-Люди уделяют наибольшее внимание тому, что они хорошо умеют делать,
-даже если для проекта былобы лучше, еслибы они уделяли немного времени
-тому, что им кажется менее важным. <xref
-linkend="getting-started"/> более подробно рассмотриваются (presentation and
packaging),
-и объясняется почему им очень важно уделять внимание с самого начала
проекта.</para>
-
-<para>Next comes the fallacy that little or no project management is
-required in open source, or conversely, that the same management
-practices used for in-house development will work equally well on an
-open source project. Management in an open source project isn't
-always very visible, but in the successful projects, it's usually
-happening behind the scenes in some form or another. A small thought
-experiment suffices to show why. An open source project consists of a
-random collection of programmers—already a notoriously
-independent-minded category—who have most likely never met each
-other, and who may each have different personal goals in working on
-the project. The thought experiment is simply to imagine what would
-happen to such a group <emphasis>without</emphasis> management.
-Barring miracles, it would collapse or drift apart very quickly.
-Things won't simply run themselves, much as we might wish otherwise.
-But the management, though it may be quite active, is often informal,
-subtle, and low-key. The only thing keeping a development group
-together is their shared belief that they can do more in concert than
-individually. Thus the goal of management is mostly to ensure that
-they continue to believe this, by setting standards for
-communications, by making sure useful developers don't get
-marginalized due to personal idiosyncracies, and in general by making
-the project a place developers want to keep coming back to. Specific
-techniques for doing this are discussed throughout the rest of this
-book.</para>
-
-<para>Finally, there is a general category of problems that may be
-called "failures of cultural navigation." Ten years ago, even five,
-it would have been premature to talk about a global culture of free
-software, but not anymore. A recognizable culture has slowly emerged,
-and while it is certainly not monolithic—it is at least as prone
-to internal dissent and factionalism as any geographically bound
-culture—it does have a basically consistent core. Most
-successful open source projects exhibit some or all of the
-characteristics of this core. They reward certain types of behaviors,
-and punish others; they create an atmosphere that encourages unplanned
-participation, sometimes at the expense of central coordination; they
-have concepts of rudeness and politeness that can differ substantially
-from those prevalent elsewhere. Most importantly, longtime
-participants have generally internalized these standards, so that they
-share a rough consensus about expected conduct. Unsuccessful projects
-usually deviate in significant ways from this core, albeit
-unintentionally, and often do not have a consensus about what
-constitutes reasonable default behavior. This means that when
-problems arise, the situation can quickly deteriorate, as the
-participants lack an already established stock of cultural reflexes to
-fall back on for resolving differences. </para>
-
-<para>This book is a practical guide, not an anthropological study or
-a history. However, a working knowledge of the origins of today's
-free software culture is an essential foundation for any practical
-advice. A person who understands the culture can travel far and wide
-in the open source world, encountering many local variations in custom
-and dialect, yet still be able to participate comfortably and
-effectively everywhere. In contrast, a person who does not understand
-the culture will find the process of organizing or participating in a
-project difficult and full of surprises. Since the number of people
-developing free software is still growing by leaps and bounds, there
-are many people in that latter category—this is largely a
-culture of recent immigrants, and will continue to be so for some
-time. If you think you might be one of them, the next section
-provides background for discussions you'll encounter later, both in
-this book and on the Internet. (On the other hand, if you've been
-working with open source for a while, you may already know a lot of
-its history, so feel free to skip the next section.)</para>
+
+<para>
+Наконец, существует общая категория проблем, которые можно классифицировать
+как "ошибки культурного значения"(навигации). Лет десять назад или даже
+пять, было бы преждевременно говорить о всемерной культуре свободного
програмного
+обеспечения, но не теперь. Постепенно возникла значительная культура
+свободного ПО, и даже не будучи единой и монолитной, она все еще имеет единый
общий
+фундамент(!core) и по меньшей мере настолько же склонна к внутренним
разногласиям и партийным расколам как и любая
+географически основанная(привязанная) культура.
+Большинство успешных открытых проектов проявляют кое-что или все из этих
фундаментальных
+характеристик. Они вознаграждают определенные типы поведений и наказуют другие;
+создают атмосферу, которая поощряет внеплановое участие, иногда в ущерб
+центральной координации; у них есть понятия грубости и вежливости, которые
+могут значительно разниться с общепринятыми где-либо еще. И важнее всего,
+долгосрочные учасники усвоили основы этих неписанных(+) стандартов и
+пришли к взаимному единодушию о моральных принципах, которые следует ожидать
от
+остальных учасников. Безуспешные проекты обычно,хотя и не намеренно,
отклоняются в
+значительной степени от этих фундаментальных стандартов, и зачастую не имеют
+единогласного соглашения о том, что же представляет собой допустимое поведение.
+Это означает, что когда возникают проблемы, ситуация может быстро ухудшиться,
из-за что
+учасники не обладают запасом общекультурных знаний(рефлексов) на которые бы
можно было положиться в разрешении
+сложностей.
+</para>
+
+<para>
+Эта книга практическое руководство, а не курс антропологии или истории.
+Тем не менее, понимание истоков современной культуры свободного ПО необходимо,
+чтобы подкрепить любой практический совет. Человек, который понимает эту
культуру,
+пойдет далеко и широко в мире свободного ПО, встречая на своем пути местные
+различия в обычаях и диалекте, и не смотря на это быть способным быстро и без
+проблем втянуться в любой проект. Для контраста, человек, который эту культуру
не
+усвоил, найдет для себя процесс организации или участия в проекте сложным и
полным
+сюрпризов.
+Так как количество людей разрабатывающих свободное ПО все еще растет
+скачками и рывками, многие из них находятся в этой последней категории—
+это по большинству культура недавних имигрантов и будет продолжать оставаться
таковой
+некоторое время. Если вы считаете себя одним из них, следующий раздел послужит
+вам уроком истории и подготовит к дальнейшим дискуссиям, которые вы встретите
позже,
+как в этой книге, так и в интернете. (С другой стороны, если вы уже работали
над
+свободным проектом достаточно долго, вам уже наверно известна большая часть
истории,
+и вы можете пропустить следующий раздел.)
+</para>
</simplesect>
<!-- ========================== SECTION =========================== -->
<sect1 id="history">
-<title>History</title>
+<title>История</title>
-<para>Software sharing has been around as long as software itself. In
-the early days of computers, manufacturers felt that competitive
-advantages were to be had mainly in hardware innovation, and therefore
-didn't pay much attention to software as a business asset. Many of
-the customers for these early machines were scientists or technicians,
-who were able to modify and extend the software shipped with the
-machine themselves. Customers sometimes distributed their patches
-back not only to the manufacturer, but to other owners of similar
-machines. The manufacturers often tolerated and even encouraged this:
-in their eyes, improvements to the software, from whatever source,
-just made the machine more attractive to other potential
-customers.</para>
+<para>
+Обмен програмным обеспечением существовал столько же долго сколько и
+сами програмы. В первые дни компьютеров, производители считали, что
+конкурентноспособные преимущества главным образом быть могут лишь извлечены
+от совершенствования аппаратных средств и следовательно не относились(уделяли
+внимания) к программному обеспечению как к корпоротивному имуществу.
+Множество пользователей тех первых машин были учеными или техниками,
+способными изменить или расширить, поставляемое вместе с компьютерами,
+програмное обеспечение самостоятельно. Иногда пользователи отправляли
+свои програмные патчи не только обратно изготовителю, но и другим
+владельцам совместимых компьютеров. Компании изготовители очень часто
+дозволяли это и даже поощряли:
+в их глазах, усовершенствования сделанные над их ПО, без разницы чьи и откуда,
+только делали машину более привлекательной для потенциальных покупателей.
+</para>
+
+<para>
+Хотя этот ранний период и напоминает современную культуру свободного
+програмного обеспечения, он отличялся в двух ключевых моментах.
+Прежде всего на тот момент не существовало почти никакой
+стандартизации среди аппаратных средств—это было врменем
+процветающей инновации в компьютерном дизайне, но разнообразие
+компьютерных архетектур значило, что все было несовместимо
+со всем остальным. Таким образом, програмы написанные для одной машины
+обычно было не возможно использовать на другой. Программисты были склонны
+специализироваться в одной какой-либо архетектуре или семействе архетекрур
+(также как сегодня програмисты скорее специализируются в определенном
+языке прогаммирования или их семействе,)
-<para>Although this early period resembled today's free software
+Although this early period resembled today's free software
culture in many ways, it differed in two crucial respects. First,
there was as yet little standardization of hardware—it was a
time of flourishing innovation in computer design, but the diversity
_______________________________________________
Producingoss-translators mailing list
Producingoss-translators@red-bean.com
http://www.red-bean.com/mailman/listinfo/producingoss-translators
