Real World Guide to Open Sourcing a Saturday Project

DZone 's Guide to

Real World Guide to Open Sourcing a Saturday Project

· ·
Free Resource

Inherent to a "Saturday project", whether written in Java or any other programming language, is that you've got it boiling on the backburner somewhere. Maybe it's a cool mobile game, possibly a revolutionary language, or perhaps a complete application. Typically you spend a lot of your private time on this pet project and the enjoyment of seeing it grow under your own steam is at least part of the point of the exercise. However, at some stage you might consider it worthwhile to open source your work. Why would you do so and what do you stand to gain? Conversely, what are the things you stand to lose?

Below, my personal experiences, my assumptions at the start, the stages the project went through, and some lessons I learned during the process. I also hope to hear from others, whether you've gone through a similar process and if your discoveries are similar.

Stage 1: Prototype.

The specific "Saturday project" in question is an application written on top of the JFugue API. I started out wanting to provide a simple drag and drop user interface to generate JFugue strings. The other two features I wanted to implement were "Play" and "Save" functionality. The latter two were going to be simple, since the JFugue API provides simple yet powerful methods that handle these aspects. Therefore, a drag and drop interface, with notes and instruments, was all I was after. I wanted to set my own expectations really low, so included the word "Notepad" in the application's title, since that's about as basic as an application can get.

At this stage, I had no real demands on how the application should look, all I wanted was something that worked. A prototype was my simple aim, with this pretty ugly result:


When showing this application to anyone, the Napkin look and feel became an obvious choice, as can be seen below, because of the draft state of the application. However, at this stage, some basic syntax coloring was already available for the JFugue notation:


Stage 2: Open source.

A tendency one might have at this stage is to think: "Let's continue developing this application until it is really solid. Then, and only then, I'll open source it, so that others can contribute to it." Of course, open sourcing something that is nothing more than a prototype is not helpful, because the first potential contributors would quickly lose interest when they see the state of your application (i.e., a mess at this stage). However, equally questionable is waiting so long that you never actually get to open sourcing, because you want your application to be so perfect that you never reach that point.

But why would you want to open source your Saturday project anyway? Part of its value is that it is yours. True. However, the statement "innovation happens elsewhere", is unquestionably true. Until you make your application available to others out there, you have no idea how much experience there is out there that can be beneficial to your application. Maybe not true in all cases, but it is in the interest of your application that you open source it. Maybe not in your own interest, personally, because obviously you lose a measure of control over it.

On the other hand, in my case, when I open sourced my application on java.net, within a week or two, through announcements on java.net (about which I knew nothing), the application was picked up by a developer called Pierre Matthijs, who lives in Belgium. As it happened, he was not only an advanced Java developer, but also a musician! What luck, since I'm not much of a musician myself (apart from a range of instruments picked up and abandoned 20 years ago or so). He needed an application such as the one that I had open sourced. He needed an application that would help him compose his music. Rather than starting from scratch, he took the slightly-beyond-prototype that I had put out there and extended it to a significant degree.

His domain knowledge (i.e., his being a musician), plus his need for exactly this type of application, led to a number of priorities being set. In the initial stage of his contributions, he provided sharps and flats, which were an obvious missing part of the application, as well as rests, as can be seen here:


Next, it made more sense to him to provide a toolbar rather than a palette for the dragging and dropping of notes and other elements on the music sheet. In addition, the long list of instruments made available by the Midi API, via the JFugue API, also needed to be integrated in a better way than giant buttons with pictures. So, he developed a tree listing all the instruments, for selection by the user when appropriate:


Already the application had obtained a "clean" look and although the functionality was still basic, it did everything that one would expect it to be able to do. However, though notes and instruments could be selected such that the JFugue strings were correctly generated, it was not possible to change anything at all. For example, one could drop a note, but one could not move it or delete it. Obviously, that was an important missing piece in the puzzle. Pierre worked on the project for about two months at one stretch, during which time he reorganized and restructured it and generally polished the rough edges, on top of adding all the code that he added to it. Again, this would not have happened, at least not as quickly or efficiently, had the application not been open sourced.

Stage 3: Self sufficient development.

For about a year after that, nothing happened with the project. My initial assumption, that a successful open source project is one where there are many contributions from many developers on a regular basis, caused me to begin believing that open sourcing the Music NotePad had not been a particularly great success. Or, in fact, a failure. All along, quite a number of developers had written to join the project, around 50 or more in total. However, most didn't want 'developer' status; they were only interested in the 'observer' role. And those that did want 'developer' status didn't contribute anything either.

Until... one day a student called Michal Fapso, from a university in the Czech Republic, signed up. He was interested in the project because he was putting together a term project at his technical university. The term project revolved around creating graphical user interfaces. He proposed, to his unversity, and then to the open sourced project, that rather than beginning an application from scratch, he would begin with the Music NotePad and add... editing functionality! He wanted his term project to focus on providing functionality that would allow the user to (1) select notes and (2) move them up and down the music sheet. He completed this project work, received first class marks in his class, and then... contributed the code back to the project! He extended it a bit so that now one can select notes and move them left and right, which extends their duration. One can either move individual notes or groups of notes. Below, one can see red notes, which are those that have been selected, thanks to the code contributions provided by Michal:


Compare this screenshot with the initial one, and note the difference! Sure, this is purely on a visual level, one can't see the code, but I think the change is quite apparent. On top of that, not only did open sourcing the project result in it being found by someone who had a valuable contribution to make, but the someone who found it gained a lot from it himself. In other words, he was able to integrate it into his studies and thereby advance his progress there.


What general lessons can be learned from all this? Here are those that I've found most valuable:

  1. Don't be overly concerned about the state of the application at the time that you open source it. You can still continue working on it yourself at that stage anyway. Just because you've open sourced your code doesn't mean that your personal work on it stops! It just means that others are able to contribute their insights and knowledge too. Of course, there must be some level of coherence in the code, otherwise those potentially joining will quickly lose interest. After all, they don't want to do your basic application development work for you; their interest lies in bringing it up to another level, but that can't be the most basic level. Plus, if you take pride in your work, you won't want to expose your work until it has reached a certain level of quality.
  2. Don't assume that open sourcing has failed if you don't get many and/or dont't get regular contributions. It's often easier to work with fewer people anyway. Having one contributor at a time is almost ideal, especially since you're dealing with a Saturday project, rather than something that has to meet a certain deadline. (In that case, you probably want/need a lot more contributions of very high quality.) Long breaks of nothing happening between contributions should be expected and, in the lulls, you can do a bit of maintenance work.
  3. Expect to be surprised at the insights you get from those you had never heard of! Expect to gain a lot in terms of domain knowledge of the contributors involved. Open sourcing is fun, especially with Saturday projects, since they're generally not time driven and can lead to a number of interesting encounters with developers around the world.

In this particular case, the application was open sourced at java.net, more specifically, at http://nbjfuguesupport.dev.java.net/. However, several alternatives exist, of course, such as JavaForge.

I would be interested to hear from others, about your experiences, if they're similar (or if this particular open source scenario is unique, which I doubt). Are there other lessons to be learned? One area is project management, and setting targets, and how is direction determined? These and similar issues I would be interested in hearing about here.


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}