Chapter�燨pen Source

Programming in the New Unix燙ommunity

Table of Contents

广告：个人专属 VPN，独立 IP，无限流量，多机房切换，还可以屏蔽广告和恶意软件，每月最低仅 5 美元

Unix and Open Source

Best Practices for Working with Open-Source Developers

Good Patching Practice
Good Project- and Archive-Naming Practice
Good Development Practice
Good Distribution-Making Practice
Good Communication Practice

The Logic of Licenses: How to Pick One

Why You Should Use a Standard License

Varieties of Open-Source Licensing

MIT or X Consortium License
BSD Classic License
Artistic License
General Public License
Mozilla Public License

We concluded Chapter�a> by observing the largest-scale pattern in Unix's history; it flourished when its practices most closely approximated open source, and stagnated when they did not. We then asserted in Chapter�/a> that open-source development tools tend to be of high quality. We'll begin this chapter by sketching an explanation of how and why open-source development works. Most of its behaviors are simply intensifications of long-established Unix-tradition practices.

We'll then descend from realm of abstraction and describe some of the most important folk customs that Unix has picked up from the open-source community — in particular, the community-evolved guidelines for what a good source-code release looks like. Many of these customs could be profitably adopted by developers on other modern operating systems as well.

We'll describe these customs on the assumption that you are developing open source; most are still good ideas even if you are writing proprietary software. The open-source assumption is also historically appropriate, because many of these customs found their way back into proprietary Unix shops via ubiquitous open-source tools like patch(1), Emacs, and GCC.

 

 

 

Prev  Up Next

Best Practices for Writing Unix Documentation  Home 燯nix and Open Source