So I recently asked for help with our website on Twitter. It’s been my most popular tweet. Several people have expressed an interest – thanks for that, and thanks for your support.

The goal of this post is to list the requirements. It’s definitely incomplete and will evolve over time. Post your questions and comments and help refine the list!

• We’re Unix people. That means we want to edit text files, not run a GUI with custom editor. We keep the pages in a git repo, and push them to do updates. A cron job running on the server can pull things down and run make.

• Most of the content is written by hand, but some of the really important things such as CVE vulnerability lists, lists of tarballs, etc., are generated. How those will be generated doesn’t matter much (XML -> new-markup -> HTML, YAML -> HTML, etc.) but it should be doable from a cron job shell-script running make. You can see the makefile and shell scripts in the repo.

• Standards are good, religious wars are bad. CSS and HTML are certainly safe choices, and probably HTML5 over XHTML. ECMAscript/Javascript seems unnecessary considering we’re a site with static content, but is acceptable as long as it doesn’t become the main part. Markdown (this blog is written in a markdown format via Octopress) is also probably fine.

• “View source” is important. Ever look at the output of “Save as HTML” for an MS Office document? We don’t want that, we want human-readable markup.

• The content needs re-organization, and not just new design.

• Our primary users are developers coming to the site for an information update, to join mailing lists, or to see if the latest vulnerability is applicable and fixed.

• Our “governance” section is going to grow. Right now it has the security policy and release strategy. Possible additions include coding style, contributor agreements, and others.

• The “hire us” messaging can be toned down; the overlap among “hire us” “fund us” and “sponsor us” need to be clarified.

• We need to thank our sponsors for their financial support, groups that have provided in-kind contributions, and mention some of the organizations that have purchased support contracts. Those should probably all be in one place (not one page, one place).

• Oh yeah, about funding. We can’t afford to pay you. You’ll get credit; see https://www.openssl.org/community/thanks.html . We need the rights to make changes, either by assigning copyright or using an appropriate Creative Commons license. In fact, as I write this, I really like the CC idea.

Our website repository is now available at https://github.com/openssl/web

We look forward to your feedback.