• Save
Open Source
Upcoming SlideShare
Loading in...5

Open Source



A talk about my experience in open source and a reflection on the open source development model.

A talk about my experience in open source and a reflection on the open source development model.



Total Views
Views on SlideShare
Embed Views



1 Embed 1

http://www.lmodules.com 1



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Open Source Open Source Presentation Transcript

  • Open Source Development
      • Charles Connell
  • Summary
    • Personal experience
    • What I learned
    • Suggestions for your open source contribution
    • Comments on "Open Source Projects Manage Themselves? Dream On."
  • My Experience
    • I have been a Linux user and programming geek since at least 2005.
    • In the spring of 2007, I wanted to develop software that would reach many users.
  • My Experience
    • I joined the Kopete team, part of the KDE project (kopete.kde.org)‏
    • I developed several small features, including a plugin to send encrypted instant messages.
    • After a year, I got frustrated with the
      • bloatedness of the code
      • inability for the small development team to maintain the large codebase
  • My Experience
    • Luckily, about the time that I was tiring of Kopete, a friend suggested an idea for a project we could work on together.
    • We developed Recuerde, a list manager (recuerde.googlecode.com)‏
    • Recuerde development was almost entirely on my own, so it was a welcome relief from the chaos of Kopete.
    • Recuerde was finished (at least in its initial conception) near the end of this summer.
    • Since then, I have been fooling around with Mozilla Ubiquity
  • What I Learned
    • I was initially shocked by the complexity of the code in Kopete.
    • It took a long time to learn how to read code from a real application.
    • Code in Kopete used every part of the C++ language all at once.
  • What I Learned
    • I was wading through huge amounts of code just to change a few lines.
    • I had no idea how to find the few lines I needed to change, or what they were at all.
    • I didn't know if what I did would negatively affect some other part of the code.
    • I wrote my first patch from scratch four times.
    • Only the fourth time was I confident enough with it to commit it.
  • Getting Comfortable
    • When making a change, be sure you know exactly what you are doing.
    • If you call a function, know what it does entirely .
    • If you modify a method, know what calls that method, and for what reason.
    • Be sure that you understand undocumented but expected behaviors. These almost always exist.
  • Your Best Work
    • Your work on one component can affect many developers.
    • Everything you write should be the best work you can do, since you are representing yourself to others.
    • Make others' work easier by doing your best.
    • Remember that everyone is a volunteer.
  • Bugs
    • Fixing a bug can be much more complex than it seems.
    • Understand the code around the bug
    • Fix it comprehensively by eleminating the root of the problem, not just supressing the symptom.
    • There are more conditions than you can imagine that affect behavior
    • Ensure that your fix works in
      • All testable conditions
      • Untestable but theoretically possible ones
  • Maintainers
    • Often, certain people are considered the maintainer of a certain component of a project.
    • They have the final word on it, and have the job of keeping a unified design.
    • Understand how much control a maintainer exerts, and work within that.
  • Patches
    • All changes to the source can be regarded as a patch.
    • A patch is a difference file generated by the version control system when it compares your local changes to a recent revision.
    • For example (in svn): svn diff > mypatch.patch
    • When making a change, you can post a patch
      • In a comment on the bug tracker
      • Attached to an email on the mailing list
    • This patch will be read and criticized
  • Discussion
    • Teams will discuss what direction to take a part of the project through a variety of means.
    • Discussion about narrow topics – bug tracking system.
    • Discussion about broader topics – mailing list.
    • Your work may need to be discussed on the mailing list.
  • Getting your changes committed
    • Different projects have different workflows. You may be asked to
      • Submit a patch through a bug report
      • Submit a patch through email
      • Commit changes yourself
    • This depends on the style of the project leadership, and how much they trust you
    • If you don't commit the change yourself, make sure that someone else commits it.
    • Don't let your work go to waste because someone let something slip by them.
  • Open Source Projects Manage Themselves? Dream On.
    • I agree with the conclusion of the paper.
    • While I was with Kopete, there was an official leader, but he performed little actual leadership.
    • Kopete is bloated, very buggy, and has no direction. It is quickly moving towards being obsolete.
    • There have been few significant additions since the first release
    • It has simply gotten bigger and more complicated as more people have hacked on it.
    • Commercial software projects have leaders who dicate in what direction the project should move.
    • Open-source projects may not have this, but good ones almost always have someone who says "no" to a commit.
    • Even if all the changes are made by different people and suggested chaotically, the existence of someone who has ultimate veto power proves there is no real chaos.
    Open Source Projects Manage Themselves? Dream On.
    • While I believe it true that good open source projects have managers, it is also true that they are much freer than a commercial project.
      • No one is ever ordered to do anything.
      • Everyone does whatever they want to.
      • People work however much they want.
    • I believe that this model, where everyone does work, and one person selects whose work to use, is the best model.
    • It allows the best work to be used, as well as maintaining a unified design.
    Open Source Projects Manage Themselves? Dream On.