Without the public visibility and reputation of SourceForge and the reliablility of your services, DavMail would probably still be an unknown piece of code used by a single user (well, maybe a few users) to access company Exchange server…

And in addition to sharing that with you, we wanted to take a moment to tell you some of the things we can do to help you promote your SourceForge project.

Project of the Month – The Project of the Month is listed at the top of the SourceForge front page for an entire month, and is chosen by popular vote. The candidates for that ballot are selected from projects that were weekly featured projects in the previous month.

Weekly featured projects – Every week we feature 9 projects on the front page of the website (in addition to the Project of the Month). These projects are chosen from projects that have made a release within the last week. So, the more often you make releases, the greater chance you have of making that list. You should know, however, that a LOT of projects make releases every day, so the competition is pretty stiff there.

Enterprise Directory – If your project is backed by a for-profit vendor, or if your project is specifically geared to the Enterprise, the Enterprise Directory might be for you. If you want your project to be listed, tell us what project, and we’ll evaluate it to see if it meets the criteria, and get back in touch regarding next steps.

Guest blog posts – Speaking of blog posts, we’re always looking for guest content for the main SourceForge blog. If you want to write something about your project, we would be glad to post it to our blog. Guest blog posts should be community-centric, not a pitch for your company or non-open-source project.

Monthly Mailing – Every month we send out a community newsletter which gets delivered to about 1.5 million subscribers. In it we cover site news, community news, and various projects. If you’d like to get something about your project into the newsletter – a help wanted item, perhaps, or a brief profile of what you’re doing – contact us at the communityteam email address. The same caveats apply here as for guest blog posts.

Twitter/Facebook/Google+ – Every day we tweet/facebook/G+ a few dozen of your release notices. We get these from your SourceForge blog entries, so making a quick mention of your releases on your SourceForge blog is a great way to get some extra publicity. However, if you made a blog post somewhere else, please feel free to send email to communityteam@sourceforge.net with a URL, and we’d be glad to put it in our regular social media schedule.

Help Wanted – The Help Wanted forum is a great place to get the word out about specific needs that your project has – whether for testers, designers, or developers. Be as specific as possible about what you’re looking for, so that potential contributors know what they’re getting into. And be sure to mention exactly how you want them to get in touch with you.

If there’s anything else that we can do for your project, please get in touch. We’re here to make your SourceForge experience better in any way that we can.

Go to Admin → Tools, and you’ll see the ‘External Link’ tool there.

Click that, and you’ll get a dialog for configuring the link.

This dialog uses the standard terminology we use for all of our tools. The ‘Label’ is what will appear in the navigation menu, and the ‘Mount Point’ is an identifier for your personal reference. After clicking save, click ‘Options’ in the tool badge, and add the URL of the site to which you wish to link.

In this way, you can provide a convenient link to your main website, an off-site Mercurial repository, a discussion forum, or whatever else you like.

If you’re searching your project’s tracker for a ticket, you have a single text field in which to enter your search, and you may be unaware of the rich syntax that’s available for crafting searches.

For the full details, click the “Help” button on any search results page:

But the purpose of this blog post is to show you a few simple examples so that you’re aware of what’s possible.

First, if you just enter a keyword, you’re searching for that word in the title or description of a ticket. While that may be sufficient if you only have a few tickets, it quickly becomes unmanageable.

The next thing you need to know is what fields you can investigate. Here’s the complete list:

User who owns the ticket – assigned_to
Labels assigned to the ticket – labels
Milestone the ticket is assigned to – _milestone
Last modified date – mod_date_dt
Body of the ticket – text
Number of ticket – ticket_num
User who created the ticket – reported_by
Status of the ticket – status
Title of the ticket – summary
Votes up/down of the ticket – votes_up/votes_down (if enabled in tool options)
Votes total of the ticket – votes_total
Imported legacy id – import_id
Custom field – the field name with an underscore in front, like _custom

Any field can be included in a search query. So if you wanted to search for tickets about ‘fishing’ that aren’t closed, you can do:

summary:fishing AND !status:closed

You can combine more complex searches by using parentheses:

summary:export AND !(status:closed OR status:wont-fix)

If you use labels (aka tags) on all of your tickets, this can also be a great way to find the tickets that you want:

labels:community AND (status:open OR status:in-progress)

If you want to know what your project worked on in a particular week, you can use a mod_date_dt search to look for tickets that were modified in that time range:

mod_date_dt:[2013-02-04T00:00:00Z TO 2013-02-08T23:59:59Z]

Finally, if you use a particular search a lot, you can save it for later use. Click on “Edit Searches” in the left sidebar, and then “Add Bin” at the bottom of that page. Give it a name, and put your search terms into the ‘Terms’ field.

There’s more you can do with searches. As I mentioned above, click the ‘Help’ button for the docs. For the exhaustive docs, see the Lucene query syntax tutorial on SolrTutorial.com.

Happy New Year! Here’s hoping that your 2013 is prosperous and productive, and that time for Open Source finds its way into your new year’s resolutions.

DOSBox is Project of the Month

We’re proud to announce that DOSBox is the January 2013 Project of the Month. It also has the distinction of being the first project ever to receive this honor twice, winning it in May 2009 as well.

DOSBox emulates a full x86 pc with sound and DOS. Its main use is to run old DOS games on platforms which don’t have DOS (Windows, Linux, FreeBSD and Mac OS X).

We spoke with two of the development team on IRC, and that entire interview can be seen on our blog, at http://sourceforge.net/blog/potm-201301/ and you can see all past POTM recipents at http://sf.net/potm

Please also take a moment to vote for the February project of the month, at http://sourceforge.net/blog/vote-potm-201302/ (Note: vote is now closed.)

Site Updates

We’ve had a great month for updates to the developer platform. Since the last mailing, we’ve added a number of important features, or improved existing ones. Of course, you’ll only have access to these improvements if your project is using the new Sourceforge. If you haven’t upgraded already, now’s the time. Go to https://sourceforge.net/p/upgrade and press the upgrade button to get on board.

Linking your project to your Twitter stream – http://sourceforge.net/blog/your-projects-twitter-stream/ This is the first in a series of updates the platform that will let you more easily publicize your work via Twitter and other social media channels.

Side-by-side diffs – http://sourceforge.net/blog/platform-updates-side-by-side-diffs/ We’ve added a side-by-side view to the diff tool when reviewing changes in your SCM. This makes it really easy to tell at a glance what changed and where.

SVN was upgraded to 1.7.7 – http://sourceforge.net/blog/svn-upgraded-to-1-7-7/

Menu cleanup for projects with lots of tools – http://sourceforge.net/blog/platform-update-menu-cleanup/ Projects with large numbers of code repositories, ticket trackers, or other tools can now consolidate tools of the same type into a single menu item, and thus avoid navigation menu clutter.

Ticket tracker reporting customization – http://sourceforge.net/blog/platform-update-tracker-columns Project admins can now customize what columns are shown in their ticket tracker list view, adding (or removing) several columns that were not available in this view before.

As always, we encourage you to vote on tickets in the tracker – https://sourceforge.net/p/allura/tickets/ – to influence what will be worked on next.

New Year’s Resolutions

It’s not too late to make some New Year’s resolutions, and maybe SourceForge can help you with some of them. You can update your resumé with some great templates (http://templates.openoffice.org/en/taxonomy/term/158) and Apache Open Office (https://sourceforge.net/projects/openofficeorg.mirror/), automate your home lights with MisterHouse (http://sourceforge.net/projects/misterhouse/) or rearrange your living room with SweetHome3D (https://sourceforge.net/projects/sweethome3d/).

And getting involved in an Open Source project is a great New Year’s resolution. Use TortoiseSVN (https://sourceforge.net/projects/tortoisesvn/) to ease the learning curve into participation, and check out our Help Wanted forum (https://sourceforge.net/p/forge/helpwanted/) for ideas of where you might be able to plug in.

For more ideas of using Open Source in 2013, see some of our resolutions on our blog at http://sourceforge.net/blog/new-years-resolutions/

Help Wanted

With over 300,000 projects and almost 3.5 million users, it can be a little difficult to match up a developer with a project. The Help Wanted forum (https://sourceforge.net/p/forge/helpwanted/) is one attempt to get projects in touch with developers and vice versa.

If you want to work on something, have a look to see what projects are looking for help. Or, if your project needs something, posting there should be part of your search process.

The EasyObject project is looking for people to help them with testing. EasyObjects is a PHP5 and jQuery web application framework. You can engage with the community at https://sourceforge.net/p/easyobject/discussion/testing/

The superbios project (https://sourceforge.net/projects/superbios) is looking for developers. You can respond to their posting at https://sourceforge.net/p/forge/helpwanted/programmers/thread/e664c976/

And numerous developers are looking for projects that need their particular skills. (https://sourceforge.net/p/forge/helpwanted/developers/) If your project needs help, start there, and be sure to check back often to follow up.

Top Growth Projects

Here’s the projects that have seen the fastest growth in the last month. There’s some familiar ones, and a few we haven’t seen before. Thanks to all of them for being part of the SourceForge community.

Media Player Classic – Home Cinema: Home of Media Player Classic – Home Cinema. This project is based on the original Guliverkli project, and contains additional features and bug fixes (see complete list on the project’s Website). http://sourceforge.net/projects/mpc-hc

Classic Shell: Classic Shell adds some missing features to Windows 7 and Vista like a classic start menu, toolbar for Explorer and others. http://sourceforge.net/projects/classicshell

Whited00r: A custom iOS firmware for older devices. http://sourceforge.net/projects/whited00r

Megacubo: Megacubo is a IPTV tuner application written in PHP + Winbinder. It has a catalogue of links of TV streams which are available for free in the web. At the moment it only runs on Windows (2000, XP, Vista and Seven). http://sourceforge.net/projects/megacubo-br

avidemux-mswin: Avidemux builds for Microsoft Windows http://sourceforge.net/projects/avidemux-mswin

InstagramDownloader: Instagram Downloader ( Public Accounts) http://sourceforge.net/projects/instagramdownlo

Open Broadcaster Software: Free and open source software for media streaming. http://sourceforge.net/projects/obsproject

Linux-on-android: Working to getting a range of Linux distros running on android http://sourceforge.net/projects/linuxonandroid

DVDStyler: DVDStyler is a cross-platform free DVD authoring application for the creation of professional-looking DVDs. It allows not only burning of video files on DVD that can be played on standalone DVD player, but also creation of individually designed DVD menus http://sourceforge.net/projects/dvdstyler

calibre: calibre – Ebook management http://sourceforge.net/projects/calibre

MediaPortal: Turn your PC into a very advanced MediaCenter/HTPC http://sourceforge.net/projects/mediaportal

WinDS PRO: Pack de Emuladores de Game Boy (Color) (Advance) y Nintendo DS. http://sourceforge.net/projects/windspro

UltraStar Deluxe: singing game http://sourceforge.net/projects/ultrastardx

aMSN: MSN compatible messenger application http://sourceforge.net/projects/amsn

Bodhi Linux: Bodhi is a minimalistic, enlightened, Linux desktop. http://sourceforge.net/projects/bodhilinux

StrongDC++: This project allows connecting, file sharing and chatting in Direct Connect and ADC networks. http://sourceforge.net/projects/strongdc

FreePOPs: FreePOPs is a webmail to pop3 conversion daemon. It is extensible to support other webmail using the scripting language LUA. See the homepage for supported webmails. http://sourceforge.net/projects/freepops

Lightweight Java Game Library: The Lightweight Java Game Library (LWJGL) is a solution aimed directly at professional and amateur Java programmers alike to enable commercial quality games to be written in Java. LWJGL provides developers access to high performance crossplatform libraries such as OpenGL (Open Graphics Library), OpenCL (Open Computing Language) and OpenAL (Open Audio Library) allowing for state of the art 3D games and 3D sound. Additionally LWJGL provides access to controllers such as Gamepads, Steering wheel and Joysticks. All in a simple and straight forward API. http://sourceforge.net/projects/java-game-lib

Open Nautical Charts: Open Nautical Charts produce seacharts for everybody. This charts are usable (offline) with several ship-plotters and Navigation-equipement on board. kap. KMZ WCI. Png Jpr png-cal For example with Open CPN. http://sourceforge.net/projects/opennautical

gpw: Guv’nor Portable Workspace aims to bring many of your favourite applications in a ‘portable’ format, so you can use them anytime, anywhere… directly running from a USB removable device. http://sourceforge.net/projects/gpw

In Closing …

Thanks for being part of the SourceForge community!

If you want more frequent updates than this newsletter, there’s several places where we make those updates. We’re on Twitter – http://twitter.com/sourceforge. We’re on Facebook – https://www.facebook.com/sourceforgenet. We’re on Google+ – https://plus.google.com/u/1/102470258162390195749/posts. And if you follow the opensource and software Reddits, http://www.reddit.com/r/opensource and http://www.reddit.com/r/software respectively, you’ll see the occasional post from us there, too.

And our blog – http://sf.net/blog – is where we post longer articles about our projects and our platform.

Keep hacking!

The SourceForge Community Team
communityteam@sourceforge.net

Since Github is deprecating the Downloads tab, Github recommends few options to projects that need to host binary files. We are happy to see our name among those suggestions, and we thank Github for the mention.

SourceForge as a trusted partner for open source welcomes you to distribute your releases via SourceForge even if your code is developed elsewhere. By distributing your releases at SourceForge, you’ll get the following advantages.

Free Unlimited Bandwidth

Reduce overhead and provide a better experience by using the largest free managed global mirror network. We serve 4.8 million downloads per day, and we move over 2 PB data monthly.

Analytics

Follow the trends that enable you to create better software. Learn more about where your project is popular, and what operating system your users use.

Premier Visibility

Reach more users and gain market share in the open source landscape. 41.8 Million unique visitors come to us every month, your chance to improve your project outreach.

A Trusted Name in Open Source

Since 1999, thousands of projects have chosen SourceForge to host not just their source code, but also their project communities. You’ll be in great company.

Get Started

If you want to provide downloads for your Github project, you’ll need to follow these steps:

1) If you don’t already have one, create a SourceForge account.

2) Create a project. You’ll want to uncheck the Git tool, since you’ve already got that, but you can add whatever tools you don’t already have elsewhere.

3) On your new project page, click the Files link and upload your release.

4) Link to your files page from your Github wiki, so that folks know where to go to get releases.

Feel free to contact us if you have any new release in the pipe, we are here to help you through our blog and our newsletter. Drop us an email at communityteam@sourceforge.net

Any forge resource (“artifact”) can be linked with surrounding square brackets, e.g. [MyPage] or [#123]. These artifact links can take several forms.

Simple Links

Most commonly, the artifact identifier can simply be surrounded with square brackets. Here are some examples:


[MyWikiPage] # Wiki - name of wiki page
[#123] # Tracker - ticket number
[r10721] # SVN - revision number
[3b9d48] # Git & Mercurial - first 6 characters of revision hash
[2012/02/my-post] # Blog - post slug, including YYYY/MM/ prefix
[a6d38f98] # Discussion Thread - thread id
[a6d38f98#42f8] # Discussion Post - thread_id#post_id


Two-part Links

To link to an artifact in a specific tool, use the form: [tool:artifact], where tool is the name of the tool as it appears in the URL. Two-part links are useful when you have two tools of the same type installed. For example, let’s say you have a ‘bugs’ tracker and a ‘features’ tracker installed, and you want to link to the first ticket in each:


[bugs:#1]
[features:#1]


Put a tracker artifact link in a commit message to link that message to the ticket in the code browser.

Three-part Links

To link to an artifact in another project, use the form: [project:tool:artifact], where ‘project’ is the name of the project as it appears in the URL. For example:

[allura:wiki:Home]

To link to an artifact in a subproject, use the form: [project/subproject:tool:artifact], where ‘subproject’ is the name of the subproject as it appears in the URL. For example:

[allura/sub:code:3b9d48]

Back-links

Any time that you link to an artifact, that artifact will automatically link back. For example, if you link from ticket #2 to ticket #3, ticket #3 will automatically have a ‘Related’ section added to it, with a link back to ticket #2. Similarly, if you link to a ticket from a wiki page, that page will have a link back to the ticket.

Inline documentation

In any editing environment (ie, if you’re editing a blog post or a wiki page) you’ll see a “Formatting Help” button that will give you a pop-up help window with formatting instructions. That includes artifact linking, as well as all other aspects of formatting in Markdown.

The most common way to do this is with a file hash that gets generated with the file is created.

Verifying downloaded files

Each time a file is uploaded, we generate an MD5 hash, and a SHA1 hash of that file, so that you can quickly check whether a file has been tampered with.

In the files interface, click on the “I” information icon next to the file, and you’ll see, as in the image above, two strings labelled SHA1 and MD5. These are cryptographic strings generated from the file itself, which you can verify on your end to ensure that the file you are downloading hasn’t been tampered with somewhere between us and the mirror, or between the mirror and you.

We will also, very soon, be adding those checksum strings to the file download page itself, so that you don’t have to go out of your way to look for it.

Once you have downloaded the file, check to see that the MD5 checksum, or SHA1 checksum, of that file, matches what we list on the site. If they don’t match, notify us, then try downloading from a different mirror.

On Windows, we recommend a tool like md5deep to generate the hashes from the downloaded file. There are also browser plugins that will calculate the checksums on a file as you download it, so that you’re less likely to forget to do it yourself.

On Linux, at the command line:

$ md5sum download.tar.gz
84a3d6aa561b112058ad9aa08a352044  download.tar.gz

$ sha1sum download.tar.gz
b6133cbc973faf908f83fa950574db0fa268480c  download.tar.gz

On Mac OS X, at the terminal:

$ md5 download.tar.gz
MD5 (download.tar.gz) = 84a3d6aa561b112058ad9aa08a352044

$ shasum download.tar.gz
b6133cbc973faf908f83fa950574db0fa268480c  download.tar.gz

Again, if you discover that a checksum doesn’t match, please tell us so that we can do something about it as quickly as possible.

We also strongly encourage project admins to verify your files yourselves on various mirror servers, after you’ve uploaded them, ensuring that what’s on the server matches what you uploaded.

Ticket voting is here.

If your project is on the New SourceForge (if it’s not, you should upgrade now), go to Admin → Tools, and click on Options under Tickets.

Check the box next to ‘Enable voting on tickets’, and click Save.

Tickets will now contain a voting mechanism, and any authenticated user on SourceForge will be able to indicate whether a particular ticket is something that they care about.

In the list view, tickets will indicate what the current vote tally is, and you can order tickets by vote, so that you can work on what people care the most about.

You can give the feature a spin right now by going to the Allura ticket queue and telling us what you’d like for us to work on next.

I’ve recently been watching the OpenHatch site, with its wonderful approach to getting people involved in projects. They seem to really care about the projects, but also about the developers who are casting about looking for a place where they can be useful.

One brilliant resource on the site is the training missions. These are short exercises designed to teach you some of the basic skills required to survive in the Open Source wasteland. You do the task, and you’re evaluated by a little bit of software which is non-judgmental and won’t laugh when you make a mistake. You can do it as many times as necessary in order to get it right, and then move on to the next thing.

Over time, the list of training missions will grow, and this site will be an even more valuable resource that all of us in the Open Source community can point to, so that we don’t all have to develop this training material for ourselves.

OpenHatch also offers resources for connecting projects with developers, and I’m looking forward to seeing how this matures over time. I’m already a big fan.

While you’re there, also take a look at their project growth cookbook, which offers a lot of great ideas for getting people involved in your community.

Later that day, the Software Sustainability Institute blog posted an updated version of my migration doc, clarifying some of the things I’d explained poorly.

We really appreciate this kind of community participation in our documentation. Did you know that all of our documentation wiki pages are available for you, the community, to enhance? If you feel that there’s something we’ve explained poorly, or not at all, please feel free to update those docs. If you find that you don’t have access to update a particular doc, just ask, and we’ll set you up with the necessary permissions.

In particular, if you have experience migrating your data from a Hosted App to your web space, the whole SourceForge community could benefit from that experience.

The SourceForge platform itself is Open Source, but so is our support community, and we encourage you to participate in that process.

So, a hearty THANK YOU to Mike Jackson and the folks from the OGSA-DAI project for sharing their time and expertise with us. Now, if you’ll excuse me, I’m going to update my document.

But, if you aren’t multilingual, how do you go about it? Well, it also appears that providing a mechanism for translation attracts new developers and contributors to your community, because it’s something that’s easy for people to do if they speak another language than the one in which the project was written.

As a citizen of the United States, I’m aware that I’m a part of a tiny percentage of the world who is not multi lingual. I used to live in Kenya, and the old joke went something like:

What do you call someone who speaks two languages? Bilingual.
What do you call someone who speaks three languages? Trilingual.
What do you call someone who speaks one language? American.

But most of the rest of the world speaks at least two, and usually more, languages. So translating a few user interface components, or a page of the documentation, isn’t a huge investment in time or effort, so it’s an easy way for someone to get involved in a project.

There are several resources for projects wishing to have translations done. By using one of these services, you can reduce the effort required for someone to contribute translations, without having to learn about your particular documentation format, your revision control system, or even know much about your product.

The Pootle project is a SourceForge project is a web-based translation tool. The tool itself is available in numerous languages, and the project website offers extensive resources about making your project translation-ready. The earlier in your project’s life you read this stuff, the more work you’ll save for yourself later.

Launchpad has a free service that coordinates translation for projects, and is used by a large number of projects, so has an interface that potential translators may already be familiar with. It’s easy to register your project there, but you’ll need to do some initial work to make your project translation-ready. Having text in the code, rather than in resource files, makes translation more complicated. Likewise, your documentation should be in formats that are portable between operating systems, and not tied to a particular application that someone might not have.

DuoLingo looks like an interesting approach, but hasn’t yet launched, so I can’t really comment on how it works.

Get Localization was another service that was recommended to me, but which I haven’t used myself.

This latter category is usually for projects that aren’t available for a platform that I use regularly.

Not pointing any fingers, but there have been times when I simply couldn’t figure out what the project was for.

In your project admin interface, you have three opportunities to describe what your project is, in three different ways.

You have a summary statement, which is 70 characters or less, and is intended to be one memorable phrase or sentence that best describes what your project is. Good examples of this are “TORCS – The Open Racing Car Simulator”, and “TuxPaint – Art software to let kids draw and paint. For children 3 to 12 years”, and “Arianne is an engine to develop multiplayer online games like Stendhal”. They are completely lacking details, but give you an immediate understanding of the central idea of the product.

Web usability folks tell us all the time that you have just a few seconds to get someone’s attention before they move on to the next link and forget about you. This summary statement is your opportunity to get their attention. Omitting it, or making it inscrutable, ensures that they’ll move on.

Next, you have the description. This is longer, and gives you the opportunity to describe what the project does. However, here too, you need to focus on what makes you distinctive. Saying that the project is Open Source is redundant. Saying that it is “full featured” is meaningless.

Imagine that you’re in an elevator with someone that is looking for a project to invest their money in. You’ve just met them, and you don’t know their level of technical expertise. They ask “what does your product do?” You have two minutes before they get to their floor and forget about you.

Ok, now go rewrite your project description. Tell me why I should choose yours over that other one, or what yours does that is unique or exciting. If I encounter another “free, open source, secure, easy-to-use and light-weight” product, I think I might scream.

(In the marketing business, they call this your elevator pitch, but’s also called the value proposition, or unique selling point, or the Big Idea. If you don’t know what yours is, then nobody else will either.)

Finally, you have the list of features. This is where you should throw around the technical terms that those in the know will be looking for. The acronyms, RFCs, and standards names. But here, too, you need to focus on what’s impressive, and what matters. Don’t tell me that your product is fast, responsive, secure, or error-free, because I assume those things.

Now, think of your friend or coworker who is least knowledgeable about your Open Source project, and show them your project page. Give them 60 seconds, and then ask them what your project is for. If they don’t know, go back and do it again.

Now, I know that you’re in this for the fun of developing the project, and sometimes, it doesn’t seem like marketing is something you want to spend that time on. But it’s more fun when more people are using it, and more people are playing along with you, and this is a worthwhile investment.

Also, please remember that this is my job, as well as my passion. If you want me to evaluate your project summary page, please JUST ASK. I’ll be brutal, and specific, and will even help you rewrite, if you want. I am a writer. And I want your project to succeed, because I love Open Source. Please just ask. It’s what I’m here for.

Special thanks to the members of the Arianne project, and especially Katie Russell, for discussion and suggestions on the #arianne and #sourceforge IRC channels (on freenode.net) which led to this article.

Most of this activity comes directly from the projects that are hosted here.

So, this article is for two things. First, I want to tell you how to post a news item on your project. Then I want to give you a few pointers in writing a press release in this age of Twitter.

If your project is running on SourceForge Classic, items posted to the News page (Select News in the Develop menu, then click Submit) are aggregated in a place that I can get to them, and I then post as many of those to Twitter as seem to be release announcements, and that I have time for in a given day.

If your project is running the latest version of SourceForge (code-named Allura), anything you post in the project blog is also aggregated for me. The blog tool isn’t enabled by default on Allura projects. However, even if you already have a blog somewhere else, what I recommend is that you enable the blog tool (Click Admin, then Tools) and create a blog called “Release Notes”, or something similar, where you can post release announcements.

Which brings me to part two – what should you write?

The most important thing to keep in mind when you write release notes, or any kind of press release, is that it will be seen out of context. That is, your announcement is going to be taken and published elsewhere, and the person reading it may not be familiar with your project. Because of this, you should tell them everything they need to know, in every release note.

This may seem overkill when looking at a list of news items all of which describe your project. But when someone sees the message on Twitter, or on Facebook, or in a tech magazine, they don’t have your website in front of them, and you need to tell them everything.

Bad press release:

v1.34 released! Shiny stuff. Fixed bug #844.

Good press release:

Click Track version 1.3.0 released. Click Track is a Metronome and click track generator for Android. http://bit.ly/wxtBa7

* Change position of click track marker.
* Delete click track marker.
* Add click track marker.
* Added help.
* Added XML editor tool.
* Added WAV to MP3 tool.

As an added bonus, you’ll notice that the first paragraph is less than 140 characters, so I can immediately copy and paste it into Twitter. This has the benefit that it’s more likely to get picked up and retweeted by other people, and possibly eventually make it into some tech news aggregator or newsletter. The extra few minutes it takes to condense your good news into 140 characters can really pay off in getting new eyes on your project, and new participants in your community.

Of course, it also saves me a little time, which increases the chance that you’ll end up in the @sourceforge Twitter stream.

So, to summarize:

* Write good press releases
* Follow @sourceforge on Twitter
* Keep releasing awesome software

Now, I know what some of you are saying. This is Open Source. We don’t have customers. We write this stuff for our own amusement, and we don’t have to pay attention to the users. Of course, if that were actually the case, you wouldn’t be publishing this software on a public site like SourceForge, but would be keeping it to yourself. In the Open Source world, we tend to call the consumers of our products “users”, rather than customers. I prefer to use the term customers, because I think it creates a different attitude towards them, encouraging us to treat them with more respect and professionalism.

The easiest way to engage your user community is to listen to what they’re saying, and then respond to them. While that might strike you as an absurdly obvious thing to say, I encourage you to take a look at the open tickets against your project and see if you’re doing this. Identify the tickets that are duplicates, and merge them, informing the reporters that you’re doing this. This tells them that you care about the project, but also that you care about your customers. Also, identify the tickets that are invalid, and explain respectfully to the customer why they’re invalid, and close them. Perhaps the problem they’re experiencing has to do with some other piece of software, or some other condition outside of the control of your software. Or perhaps they just don’t know how to do something, which is explained in the documentation.

The harder task, of course, is addressing the legitimate tickets. One useful strategy for doing this is to use them as an opportunity to engage the developers in your community and give them a way to become more active participants on the project. For the simple ones, explicitly label them as simple, and perhaps even provide a short discussion of how you think it should be addressed. Encourage your community to have a try at fixing it. For the more complicated ones, I still encourage you to do the same thing. Add an explanation of how you would address the request, and possibly break it into smaller pieces. This exercise not only encourages participation from the community, but sets a roadmap for yourself, so that you can address things in stages, as you find time.

Using your ticket tracking system to map out your plans for your project also makes customers feel more connected, as well as less frustrated with your progress, since they know where their requests fit into the larger scheme of things.

Also be sure to set your preferred support mechanism in your project admin. That’s set on Project Admin → Settings → Set Preferred Support Mechanism (on the right) for classic projects, and at Admin → Metadata for Allura projects.

Finally, an observation. I’ve noticed that a pretty significant number of projects don’t even have ticket tracking enabled. Not having any ticket tracking at all may be interpreted by your customers as a statement that you don’t care what they think. If you fall into this category, I strongly encourage you to enable ticket tracking, and start actively using it as a community-building tool.

But how often is often enough? Is it possible to release too often?

When evaluating a project to see if it’s one I want to adopt, I consider several factors. One of the top factors is the date when the project was last updated. This gives me a sense of whether the project is active, which, in turn, gives me some idea of what I can expect with regards to product support and longevity.

If a project has regular releases, and has had for a while, I think maybe I can expect them to continue into the future. On the other hand, if the last release was five years ago, I don’t even bother to evaluate the product, because I know that my support requests are going to go unanswered.

Frequent releases, particularly with detailed release notes, tell the users that the product is making steady progress, and that user feedback is being heeded. It tells the user that if they make a request, or file a bug, it’s not going into a void, but that there will eventually be a release that addresses their concern.

And, in turn, the impression that is created of a vibrant and active project brings not only new users, but new developers.

So, when should you release? The easy answer is “when it’s ready,” but this depends largely on the nature of your project.

If your product is a low-level developer-focused thing like a Perl module or a C library, any time it passes all of the tests (you do have tests, right) ship it. Developers want the latest and best thing you have available. On the other hand, if it’s a desktop product with a polished user interface, a new release should probably include some change or feature that the end-user is actually going to notice, otherwise they’ll decide there’s no value in getting updates.

We recommend you cut a new release any time there’s something new that might benefit the end-user. This might be a bug fix, a completed new feature, or an enhancement to an existing feature. When the coding is complete and the change has been tested, there’s no reason to withhold it from the customer. Ship it, and let them experience the new shine.

There are, of course, complications to this. You may be working on several things at once, and one is complete while another is still in progress. Or perhaps several features enhance one another in such a way that it makes sense to push them out together. Just make sure you have a good reason for not releasing.

Finally, there’s the question of whether you can release too often. I think you can. Releasing too often has two side-effects.

One, it gives the impression that you don’t think very hard before releasing. This, in turn, makes people concerned about the quality of your releases. Be sure that a release works and is thoroughly tested, before pushing it out.

Second, if there’s a release every day, you eventually train people that there’s no real value in getting every update. This causes problems when a release is critical, such as an important bug fix or security patch.

It’s a good idea to ask your users how often they expect releases. Listening to your customers is always a good idea.