Software Publishers' Guide (Draft)

1. Introduction

Count From Zero (CFZ) provides a community for publishers of programming software and their users. The primary feature is the directory of programming libraries and APIs. See the About page for more details. Go the the Users' Guide for descriptions of the data CFZ provides. For communications email cfz@countfromzero.biz.

2. General Information

1. CFZ does not discriminate on the basis of licensing or financial backing. Your software can range from an individual open source project to specialized industrial software costing hundreds of thousands of dollars. The support you provide to your users can range from none to an army of consultants. You can choose to support CFZ or not (see final paragraph in this section). It all makes no difference in CFZ's services to you.
2. CFZ accepts no paid placement, period, no exceptions. To act otherwise would be a disservice to the CFZ community. However, you can buy advertising on your software's dedicated page or the categories it belongs to with an AdWords account. CFZ plans to launch an advertising program soon.
3. If you ever want your software delisted, it will happen, no questions asked.
4. CFZ responds well to constructive criticism! Keep it coming!
5. Some of the most important data CFZ collects about your software is the identifier and release date of the latest version. Updating your data happens quicker if you are proactive and notify CFZ of new versions.
6. CFZ looks for actively maintained, quality software. Please see the listing criteria.
7. If you wish to reciprocate the most appreciated method is to create hyperlinks from your blog or site to CFZ to increase search engine ranking (make sure the "nofollow" attribute is not specified in your markup). Alternatively, you can buy advertising, promote the site by word-of-mouth, or send a tip (email to get the payee and address). Regardless of your actions on this matter, CFZ will neither hold anything against you nor favor you. CFZ avoids playing favorites to build a better community of publishers and users.

3. Data CFZ Collects About Packages

1. Package Name
2. URL Home
3. URL Download
4. Language Written: the predominate language the package is written in
5. Version: the identifier, such as 3.1.23, of the latest release
6. Release Date: the date of the latest release
7. License: CFZ tries to classify licenses into one of ten categories. The Users' Guide details them. Support for multi-licensing is a planned future feature.
8. Short Description and Publisher's Description: see section 4.
9. Relationships: programmatic relationships to other packages, such as dependencies and extensions.

4. Guidelines For Writing Descriptions

CFZ uses descriptions three ways:

1. The short description is used when your package is in a list, particularly on the category pages.
2. The first 10-20 lines of the publisher's description (hereafter called the intro) is used on CFZ's page dedicated to your software.
3. The full publisher's description receives it's own dedicated page because of potential length.

So,

the short description makes the reader want to go to your product's dedicated page, where they read the intro which makes them want to read the full description.

1. Short Description: A one or two line description of the package. The short description answers the question

   "What features distinguish this product?"

   Some guidelines to make your short description the best answer to this question:
   1. Distinguish the package from others in the same category. The short description helps users quickly compare the features of your product to the features of other products in the same category.
   2. The package name, language, category, and category description are redundant. The name and category can always be inferred from the context, as can category descriptions when support for them is added soon. You don't need to say "MyCoolUploader is FTP software that makes sending a file from one computer to another possbile." The reader will already know everything in the sentence from the other data available.
   3. An excellent use of descriptions is to place the package into categories not supported by CFZ, especially if the category would be unique to your package. Source control software rarely uses a relational database engine, so no "source control: relational database engine" category exists. The description for such a package provides the chance for this non-existant category to be identified.
   4. Don't use sentences. Descriptions are similar to code comments. A semicolon-delimited list of features is better: "feature a; feature b; feature c."
   5. Avoid vague terms; be specific. Descriptions are too short to use terms such as "easy to use," "high performance," "best in class," and so on. Such descriptions do not help the reader much and your package is more likely to be skipped over in favor of other packages with more specific descriptions. If your security package is unique because it makes practical one-time pads possible, say "practical one-time pads" instead of "EasyPad makes communications totally secure with a new breakthrough in security technology."
   6. Assume your audience already understands the category. You don't need to explain what a pointcut is for your aspect-oriented programming package. A reader looking at the aspect-oriented programming category will likely already know this, but if not the definition will be in the category's wiki or listed external articles for the category (although neither feature is supported yet).
2. Publisher's Description: opportunity to sell your product. Any length within reason. Only the first 10-20 lines will be shown (the exact maximum number of characters is yet to be decided) on your package's main page. The entire description will be on a dedicated description page linked to from the main page. Use the 10-20 lines to interest the reader enough to click through to the description page where you can really sell your product.