It’s interesting what one can find when cleaning up an old laptop before dumping it 🙂 Old photos that I’ve long forgotten of (some embarrassing ones too, omg the haircuts I supported throughout the time! :D), snippets of code back from the day when technology X was just coming out of its stables and I was trying my hand at it (again, some of them rather embarrassing as they never really took off, so in hindsight that was just a waste of time) … and in the case of yours truly, also snippets of blog articles and ideas that I was working on ages ago which again never saw the daylight. In this particular case, I came across a blog article that I nearly finished back in the day but never quite finished — and then other projects captured my attention so I buried this in the hard disk and left it to rot 🙂

This particular article I think surfaced in the early days of my aws-version-mgmt project on SourceForge (what happened to them? It’s all github and bitbucket nowadays..) — and as the work was progressing on that and I was looking for volunteers to lend me a hand at this open-source project, it occurred to me that some other open source folks might benefit from my experiences and learnings from this so I put together this (rather long) article. Since it’s quite long, I’m going to attach it here as a PDF — feel free to download it and spread it — however, just to save you some time and help you decide if this is something worth your attention, I’m including below some snippets from the article.

For the impatients among you, here’s the link to download the PDF — for the others who like perusing first, here’s some snippets from it:

This book is the synthesis of the work that I have carried out myself in starting up an open source project and driving this through sourceforge.net – from concept to implementation to making it available on sourceforge.net and then recruiting a team of enthusiasts and managing the development and the release process from there on.

It is meant to help others who are interested in developing a project and making it available to the community using sourceforge.net, however, they might be scared at the prospect of what a complex task this can be become.

The original project this book is about is still alive on SourceForge; the project is called “aws-s3-version-mgmt” and you can check it out for yourself on SourceForge by visiting this link: https://sourceforge.net/projects/awsversionmgmt/ . (And if you are that way inclined, by all means join our community of developers and contribute to it too!) The book will make often references to various tools and features offered by SourceForge and will provide links to these sections on the above-mentioned project site. So be warned ahead that I an un-ashamingly promoting this open-source project by doing so, but ultimately it’s for a good cause as well as I feel it provides a better context for the readers of this book.

Why SourceForge? There are many other open-source incubator sites out there – github.com being one of the most prominent ones at the moment – however, having been a SourceForge user for a long time (I did find myself many times downloading and using components hosted there!), and bearing in mind my rather poor knowledge of git, I opted for SourceForge when it came to starting this project. As many entrepreneurs around the world will tell you, when it comes to starting a project, you need to iterate quick and often, and as such, you need to start by using what you know – as the project evolves you can start looking at leveraging other tools and frameworks, but to start with choose the one that’s going to get you quicker to the goalpost. Hence SourceForge, in my case.

Start simple again – build just a simple “developers” mailing list, and once it’s ready add yourself to it. You will be the administrator for it and I suggest a few settings for your list:

• Set it up such that all user registration requires you (the admin) to approve it – this helps with preventing spam as well as you will be notified initially every time a new developer joins, so you can have a clear idea at any point who is joining your list. Maybe you want to reach out to each subscriber individually, welcome them to the project – if you do this, it might be worth while to have a default email template for this! Or maybe you just want to email them to find out if they are a developer or a user of your project – if you notice at some point a mix of developers and users on your list it might be then the time to create a separate list for just the users and separate them from the developers! (Users will typically be interested in how to use your project, they might ask for features or for help in setting up – developers on the other hand will quite likely raise design questions, discuss about a particular unit test failing – things that are not relevant to your users.)
• Also make sure you do NOT allow emails from non-subscribers – if you do that, all you need is for a spammer to get access to your list email address and then your list will be filling up shortly with spam. (Remember that all of the emails on this list are indexed and archived by sourceforge and the archives can be browsed on the web! As such a list full of spam will decrease the confidence in your project, since people will think that there is no “administrator” guarding the project!)
• Depending on the kind of emails you expect to be sent around on this email list, set a decent max email size in the “General Options” settings, under “Maximum length in kilobytes of a message body” – sourceforge offers you the choice to select “0” for “no limit” but I advise against that, since it simply gives your subscribers the chance to send huge attachments around, which can be a waste of storage and bandwidth (bear in mind these emails get in turn broadcasted to all subscribers – some of which might have filters set on their inboxes not to accept emails bigger than XYZ!). I find the default 40Kb can be a bit restrictive (especially when dealing with rich text format or HTML), so I suggest you look somewhere around 64Kb – 100Kb. Though, depending on your project, other values might be suitable for you.

The rest of the default settings for the mailing lists I found to be ok, but feel free to tweak it here and there if you need to.

One last thing, as I said, it can take sourceforge a few hours to create your mailing list – so first just proceed to setting up the list and then I’d advise you to allow it 24 hours before you go to setting up the rest of the options described above. This way, by the time you get to making changes to the configuration you will be 100% sure that the list and all the components around it has been set up and finalized.

The purpose of most open-source software projects (on SourceForge and otherwise) is to provide some tool or libraries or framework the user can download and use. In the case of Java projects this typically refers to a bunch of classes – in most cases grouped together in a jar file. (Typically these are referred to as deliverables or binaries.) This file is normally generated by your build process – be it ant, maven or some other tool.

In fact let me rephrase that: this has to be generated by your build process! What I mean by that is the fact that you need a build process which automates most of the tasks – including generating these binaries; rather than having them packaged by some manual process. A manual process requires the person building the packages to remember a set of steps, each one with their particularities. Since you are going to set up the build process, these steps would probably stick in your mind very well and you might argue that you can’t possibly forget them. Also you would argue that you could put it on the project wiki – and that’s true, you can! However, imagine that your project develops enough traction to get the attention of a few developers – and they might or might not pay attention to the wiki page or they might even forget some of the steps involved. And in an open-source environment you can’t really take the approach of “I’ll be the only one performing builds” – or if you do you will find that you end up consuming a lot of your time performing admin tasks (i.e. creating a release and uploading it) rather than concentrating on implementing and coding your project! There are lots of articles out there who explain why this is so I’m not going to stress on this, but just enough to state that you have to tailor your build process such that it produces all the binaries somewhere in some directory.

… And I’ll leave it at that 🙂

Read the rest — again, remember, this was written about 4-5 years ago I think! — by downloading the PDF (if the above snippets suggest that this is worth your time).