Author: vlad.shcherbakov
Date: Fri Oct 10 11:42:51 2008
New Revision: 1520
Log:
some more translation of first chaper
Modified:
trunk/ru/ch01.xml
Modified: trunk/ru/ch01.xml
==============================================================================
--- trunk/ru/ch01.xml (original)
+++ trunk/ru/ch01.xml Fri Oct 10 11:42:51 2008
@@ -1,4 +1,4 @@
-<chapter id="introduction">
+<chapter id="introduction">
<title>Введение</title>
@@ -41,11 +41,8 @@
</para>
<para>Эта книга посвящена тому как избежать провала. В ней описано не только
-как нужно правильно делать что-либо, но и как <emphasis>не</emphasis> нужно,
так чтобы
+как нужно правильно делать что-либо, но и как <emphasis>не</emphasis> делать,
так чтобы
вы научились распознавать и разрешать проблемы на раннем этапе их появления.
-В моих надеждах, что по прочтению этой книги, вы станете обладателем широкого
репертура
-методов не только избежания наиболее частых подводных камней свободного ПО, но
и как
-считаться с ростом и поддержкой успешного открытого проекта.
Успех проекта это не игра со счетом в ничью, и эта книга вовсе не о том как
выйграть
или выйти вперед в конкуренции. Наоборот, важной частью ведения открытого
проекта
является крепкое сотруднечество с остальными, связанными или похожими(!)
проектами.
@@ -58,35 +55,32 @@
<para>
Было бы заманчивым(tempting) сказать, что причины неудач свободного ПО те же
-что и у коммерческих проектов.
-
-Разработка свободного ПО не означает отсутствие таких проблем, как завышенные
требования, расплывчатые спецификации, неэффективное управление кадрами и
других
-сложностей давно известных индустрии разработки.
-
- На эти темы уже написаны горы литературы и, в своей книге, я постараюсь
избежать повторений ранее известного.
-
+что и у коммерческих проектов. Я надеюсь, что после прочтения этой книги, вы
обзаведетесь
+ большим арсеналом методов, которые позволят вам не только не наступать на
наиболее частые
+ грабли разработки свободного ПО, но и как считаться с ростом и поддержкой
успешного открытого проекта.
+ На эти темы уже написаны горы литературы и, в своей книге, я постараюсь
избежать повторений
+ ранее известного.
+
+Вместо этого, я хочу
+описать проблемы характерые только для свободного ПО.
+
+Когда свободный програмный проект начинает рушиться, это часто потому что
разработчики
+(или мененджеры) не учли уникальных проблем открытого програмного обеспечения,
даже будучи
+ основательно подготовленными к более известным проблеммам присущим лишь
коммерческому ПО.
+</para>
-Об этом уже написано достаточно много и я не
-хочу повторяться в своей книге. Вместо этого, я хочу
-описать проблемы характерые только для свободного ПО. Часто сложности
-при разработке свободного ПО возникают из-за того, что разработчики или
руководители
-недооценили проблемы характерные для открытого ПО,
-хотя возможно достаточно хорошо подготовились к
-хорошо известным проблемам закрытого ПО.
-(development ???).</para>
-
-<para>Одной из наиболее общих ошибок является слишком большие надежды
возлагаемые
-на достоинства открытого ПО. Использование открытой лицензии
-не гарантирует того, что над проектом сразу начнут работать много
разработчиков,
-которые будут тратить на него своё свободное время. Также открытие исходных
текстов
-само по себе не поможет решить проблемы пректа.
- Более того, открытие исходных текстов может принести дополнительные
сложности, которых может стать
-<emphasis>больше</emphasis>, чем до открытия проекта. Для открытия проекта
необходимо
-сделать код понятным для новах разработчиков, создать и поддерживать веб-сайт
и рассылки(email lists),
-а также написать документацию. Это достаточно долгая и трудная работа.
-И если разработчики заинтерисуются проектом появится необходимость
-некторое время отвечать на их вопросы до того как они принесут какую либо
пользу. (Jamie Zawinski) сказал о проблемах
-проблемах на раннем этапе развития проекта Mozilla:</para>
+<para>Одной из наиболее распрастраненных ошибок является слишком большие
надежды возлагаемые
+на достоинства открытого ПО. Использование открытой лицензии не гарантирует,
что орды активных
+разработчиков неожиданно изволят потратить свое драгоценное время на ваш
проект, не решить
+проблем затрудненного проекта и простым открытием его исходников. Как раз
наоборот: раскрытие проекта
+может принести целую кучу дополнительных сложностей, и дороже стоить, с
расчетом на короткий срок,
+чем было бы, оставайся он закрытым. Раскрыть проект означает переорганизовать
код так, чтобы он был
+понятен новым разработчикам, не знакомым с вашим проектом, создать официальный
веб сайт проекта и настроить
+списки рассылки(email lists), а также нередко первый раз взяться за написание
документации. Все это
+много работы. И если и появятся заинтересованные разработчики, еще к этому
добавится и бремя отвечать на
+кучи их вопросов, прежде чем от них будем какая-то польза от их присутствия.
+Как выразился Jamie Zawinski о ранних турдных временах проекта Mozilla:
+</para>
<blockquote>
<para><emphasis>Концепция свободного ПО и вправду работает, но не
является лекарством от всех болезней. Если здесь и есть слово предосторожности,
лишь можно сказать что нельзя просто взять чахнущий проект, присыпать его
волшебной пылью "открытого ПО" и по волшебству разрешить все проблемы.
Програмное обеспечение трудно. Проблемы(issues) не так просты.
</emphasis></para>
@@ -95,6 +89,32 @@
url="http://www.jwz.org/gruntle/nomo.html"/></emphasis>)</para>
</blockquote>
+
+<para>
+Также схожей ошибкой является экономия на презентации и комплектации, наивно
полагая
+что это всегда можно оставить на потом, запозно после начала проекта.
Презентация и комплектация
+заключают в себе широкий круг задач, посвященных теме упростить вступление в
проект потенциальным
+разработчикам.
+Сделать проект более привлекательным можно при помощи написания руководств для
пользователей,
+документации разработчикам, созданием сайта проекта содержащего информацию для
новичков, насколько
+возможно автоматизировать процессы компиляции установки и т.д.
+Многие программисты к сожалению считают это второстепенной задачей после
написания кода.
+Есть несколько причин почему. Во первых, это может показаться трудной работой,
потому что
+преимущества от этого заметны(ощутимы) лишь тем, кто менее знаком с проектом и
наоборот.
+
+В конце концов, людям написавшим код не нужна ни какая комплектация.
+Им уже известно как устанавливать, администрировать и использовать их
+собственное ПО.
+Во-вторых, умения необходимые для того чтобы создать презентацию и
комплектацию,
+далеко отличны от тех что нужны для написания кода.
+Люди склонны концентрироваться на том, что они лучше знают, даже
+если немного времени проведенного над тем, что им кажется менее важным,
помогло бы проекту гораздо больше.
+ <xref
+linkend="getting-started"/>
+Презентация и комплектация обсуждаются в подробностях, объясняется почему так
важно чтобы они были приоритетом
+с самого начала проекта.
+</para>
+
<para>Так же распространённой ошибкой является недостаточное (presentation and
packaging, figuring) которыми которые всегда можно сделать позже, в процессе
разработки проекта. (Presentation and packaging) включает в себя множество
_______________________________________________
Producingoss-translators mailing list
Producingoss-translators@red-bean.com
http://www.red-bean.com/mailman/listinfo/producingoss-translators
