Author: alekseyilyin
Date: Sun Sep 16 04:25:38 2007
New Revision: 1190
Log:
Продолжение перевода ch01.xml
Modified:
trunk/ru/ch01.xml
Modified: trunk/ru/ch01.xml
==============================================================================
--- trunk/ru/ch01.xml (original)
+++ trunk/ru/ch01.xml Sun Sep 16 04:25:38 2007
@@ -48,35 +48,32 @@
<simplesect>
-<para>It would be tempting to say that free software projects fail for
-the same sorts of reasons proprietary software projects do.
-Certainly, free software has no monopoly on unrealistic requirements,
-vague specifications, poor resource management, insufficient design
-phases, or any of the other hobgoblins already well known to the
-software industry. There is a huge body of writing on these topics,
-and I will try not to duplicate it in this book. Instead, I will
-attempt to describe the problems peculiar to free software. When a
-free software project runs aground, it is often because the developers
-(or the managers) did not appreciate the unique problems of open
-source software development, even though they might have been quite
-prepared for the better-known difficulties of closed-source
-development.</para>
-
-<para>One of the most common mistakes is unrealistic expectations
-about the benefits of open source itself. An open license does not
-guarantee that hordes of active developers will suddenly volunteer
-their time to your project, nor does open-sourcing a troubled project
-automatically cure its ills. In fact, quite the opposite: opening up
-a project can add whole new sets of complexities, and cost
-<emphasis>more</emphasis> in the short term than simply keeping it
-in-house. Opening up means arranging the code to be comprehensible to
-complete strangers, setting up a development web site and email lists,
-and often writing documentation for the first time. All this is a lot
-of work. And of course, if any interested developers
-<emphasis>do</emphasis> show up, there is the added burden of
-answering their questions for a while before seeing any benefit from
-their presence. As developer Jamie Zawinski said about the troubled
-early days of the Mozilla project:</para>
+<para>Было бы заманчивым(tempting) сказать, что причины неудач свободного ПО
такие же
+как и у коммерческих проектов.
+Действитеьно(Certainly), для свободного ПО так же характерны (unrealistic
requirements),
+(vague specifications), неэффективное управление ресурсами, (insufficient
design
+phases), или другие проблемы(hobgoblins) хорошо известые в истории
+индустрии ПО. Об этом уже написано достаточно много и я не
+хочу повторяться в своей книге. Вместо этого, я хочу
+описать проблемы характерые только для свободного ПО. Часто сложности
+при разработке свободного ПО возникают из-за того, что разработчики или
руководители
+недооценили проблемы характерные для открытого ПО,
+хотя возможно достаточно хорошо подготовились к
+хорошо известным проблемам закрытого ПО.
+(development ???).</para>
+
+<para>Одной из наиболее общих ошибок является слишком большие надежды
возлагаемые
+на достоинства открытого ПО. Использование открытой лицензии
+не гарантирует того, что над проектом сразу начнут работать много
разработчиков,
+которые будут тратить на него своё свободное время. Также открытие исходных
текстов
+само по себе не поможет решить проблемы пректа.
+ Более того, открытие исходных текстов может принести дополнительные
сложности, которых может стать
+<emphasis>больше</emphasis>, чем до открытия проекта. Для открытия проекта
необходимо
+сделать код понятным для новах разработчиков, создать и поддерживать веб-сайт
и (email lists),
+а также написать документацию. Это достаточно долгая и трудная работа.
+И если разработчики заинтерисуются проектом появится необходимость
+некторое время отвечать на их вопросы до того как они принесут какую либо
пользу. (Jamie Zawinski) сказал о проблемах
+проблемах на раннем этапе развития проекта Mozilla:</para>
<blockquote>
<para><emphasis>Open source does work, but it is most definitely
@@ -89,28 +86,26 @@
url="http://www.jwz.org/gruntle/nomo.html"/></emphasis>)</para>
</blockquote>
-<para>A related mistake is that of skimping on presentation and
-packaging, figuring that these can always be done later, when the
-project is well under way. Presentation and packaging comprise a wide
-range of tasks, all revolving around the theme of reducing the barrier
-to entry. Making the project inviting to the uninitiated means
-writing user and developer documentation, setting up a project web
-site that's informative to newcomers, automating as much of the
-software's compilation and installation as possible, etc. Many
-programmers unfortunately treat this work as being of secondary
-importance to the code itself. There are a couple of reasons for
-this. First, it can feel like busywork, because its benefits are most
-visible to those least familiar with the project, and vice versa.
-After all, the people who develop the code don't really need the
-packaging. They already know how to install, administer, and use the
-software, because they wrote it. Second, the skills required to do
-presentation and packaging well are often completely different from
-those required to write code. People tend to focus on what they're
-good at, even if it might serve the project better to spend a little
-time on something that suits them less. <xref
-linkend="getting-started"/> discusses presentation and packaging
-in detail, and explains why it's crucial that they be a priority from
-the very start of the project.</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
_______________________________________________
Producingoss-translators mailing list
[email protected]
http://www.red-bean.com/mailman/listinfo/producingoss-translators
