Subversion

Subversion turns out to be a very powerful, yet simple tool.  The Windows tool TortoiseSVN adds commands to windows explorer menus when you right-click on files or folders.  These commands do everything from checking out a repository to committing changes made.  It also provides an icon to indicate the status of files while in windows explorer. 

The Ubuntu tool  RapidSVN is a GUI that has all the same features Tortoise provides, but it's done through a GUI instead of explorer menus.  Ubuntu also provides command line tools for maintaining an SVN repository.

Setting up a Subversion server was also quite simple.  I used VisualSVN server to set up a simple SVN server on my Windows machine.  After installing, it was simple to add a new repository, add a user, and connect to the repository using those new user credentials.

The History of GNOME Empathy

This weekend I researched the history of the GNOME Empathy project.  It started as a reinterpretation of a project that was a compilation of two other projects.  Needless to say, the history wasn't exactly clear.  It is a messaging program integrated into the GNOME desktop.  It's written in C, which will be interesting because most of our group aren't familiar with C programming.  The project is sponsored by Collabora Ltd., a software consultancy based in Cambridge, England.  The project leaders are Guillaume Desmottes and Xavier Claessens.

The Cathedral and the Bazaar and IRC

I'm going to start this by extracting all the rules of open-source development from the essay and making a list.

1. Every good work of software starts by scratching a developer's personal itch.
2. Good programmers know what to write. Great ones know what to rewrite (and reuse).
3. "Plan to throw one away; you will, anyhow." (Fred Brooks, The Mythical Man-Month, Chapter 11)
4. If you have the right attitude, interesting problems will find you.
5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor.
6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
7. Release early. Release often. And listen to your customers.
8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
9.  Smart data structures and dumb code works a lot better than the other way around.
10.  If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource.
11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
13. "Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away."
14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.
15. When writing gateway software of any kind, take pains to disturb the data stream as little as possible—and never throw away information unless the recipient forces you to!
16. When your language is nowhere near Turing-complete, syntactic sugar can be your friend.
17. A security system is only as secure as its secret. Beware of pseudo-secrets.
18. To solve an interesting problem, start by finding a problem that is interesting to you.
19. Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.

This list of rules outlines the sound strategies Raymond implemented during a successful attempt at starting an open-source project.  He then documented his thoughts and motivations during the execution of that project.  He modeled his attempt after what he perceived as Linus Torvalds' successes with the Linux OS.

Another list worthy of note ... the closed-source program manager's five functions:

1. To define goals and keep everybody pointed in the same direction
2. To monitor and make sure crucial details don't get skipped
3. To motivate people to do boring but necessary drudgework
4. To organize the deployment of people for best productivity
5. To marshal resources needed to sustain the project

Raymond tries to explain why these functions are necessary, but instead explains why open-source makes them unnecessary.  They don't need to marshal (defend) resources because everybody brings his own toys.  They don't need to organize for best productivity because only the best of the best get any attention in the elitist open-source culture.  There's no need to motivate or monitor people who are volunteering to do the work in the first place.  The goals of open-source projects are elicited by the leaders of the project and elaborated upon by the beta-users and co-developers, rather than a committee that gets the goals wrong 60 - 75% of the time anyway.

This essay has pretty much sold me on the effectiveness of open-source software development.  Toward the end of the essay he says, "Human beings generally take pleasure in a task when it falls in a sort of optimal-challenge zone; not so easy as to be boring, not too hard to achieve. A happy programmer is one who is neither underutilized nor weighed down with ill-formulated goals and stressful process friction. Enjoyment predicts efficiency."


IRC was remarkably easy to set up.  I'm currently using the windows version of Gnome Empathy, which supports IRC as a chat method.  A quick search of the Pidgin website detailed how to set up an IRC room.  Joining the mailing list was also quite easy.

Group Project Picks

Last Thursday, as a group, we chose 3 FOSS projects that sounded interesting.  After doing some research on them, I've decided the Gnome Empathy project has the best support for new contributors.  They give suggestions for developers, provide links to the source and details on how to build it, and have both IRC and a mailing list for contacting the team.

The other 2 projects the team chose are both interesting. 
The OpenRemote project looks to be nearly complete, and it doesn't have much in the way of documentation on their website.  Of course, it could have all the necessary documentation bundled with the source code.  They also don't have any obvious IRC channel, but they do provide a web-based chat-room with logs of previous chats.

The OpenKinect project also sounds interesting, but it's not software in and of itself.  It's software to allow for integration of the new Kinect controller for the XBox 360 with various operating systems.  Their wiki has a lot of information available and IRC and mailing lists as well.  It also links to the source code and provides detailed build instructions based on operating system.

I hope I'll be able to convince the team to go with Gnome Empathy, but they sounded very excited about the OpenKinect project.

Blogs, Wikis, and POSSCON; Oh my!

Setting up a blog was easy.  Google already knows who I am, so it was just a matter of asking them to set up a blog for me to use.  Setting up a Wiki for our group, called When It's Done, was easy as well.  The wikispaces website is easy to use, and simple to operate.  Signing up for POSSCON was also easy (confirmation info: Transaction ID: RKDRJGQZCF, Order Number: 10000239), and free to boot.  I have Physics on MWF, so I don't plan to attend Friday's events for POSSCON, but I will be there for Thursday.

I read chapters 1 and 2 of TOS.  The information inside was mostly stuff we've either gone over in class, or I've seen it somewhere before.  I imagine it'll become much more useful quite soon.