Party Of One: Conclusion

May 17th, 2008 | 7 Comments »

This is the final part of the series on one-man open source projects. In the previous entries i talked about the different facets of the issues that face single-developer projects:

There are a lot of big projects out there with dozens of active developers and hundreds of people actively involved behind the scenes. Sometimes, developers of these projects have the luxury to concentrate on what they love to do the most – coding. However, the terms such as steering committee, constitution, incubation and governance models do not apply to the vast majority of the open-source projects. Such projects frequently languish because their developers fail to recognize that all those menial and tedium tasks are crucial for the long term health of their projects.

Sometimes, the solo developer behind a fledgling open-source project has an unreasonably high level of expectations from the target user sector. This frequently leads to frustration from low number of downloads, lack of interest from the blogosphere and may even result in venting your anger against the competing projects in public forums, mailing lists and blog comments. While being the best in your field is an understandable goal, i would advise focusing on other aspects instead.

Is being the best a goal in itself? How about admitting the following three simple things:

  • You know you’ll make mistakes
  • You’re ready to learn from them
  • You hope to not repeat the same mistakes in the future

This way, you will not be afraid to make a mistake, not be afraid to admit a mistake and be very quick to fix one. And in any case, what are your chances of being the best? Next time you attend a technical conference, look around you. What are your chances of being the smartest guy in the room? What are your chances of being the smartest guy at the conference? What are your chances of being the smartest developer using your favorite language? What are your chances of being the smartest guy in the world?

If you have a blog, if you have your own open-source project, even if you comment on somebody else’s blog – you want to be heard. If you’re open to comments, bug reports, enhancement requests and a genuine two-way conversation with your users, you will be surprised at how much you can learn from them. And if you have the ability to cut through the complexity, distill chaotic flows into a clean API and communicate without condescension, they will come.

P.S. This series was originally conceived as a session for this year’s JavaOne and OSCON conferences. Even though the reviewing committees were not overly impressed, i do feel that it is an important topic. You can download the full slides in PDF format. There are no absolutes. This is what works for me.

Related posts:

  1. Party Of One: Promote If you write it they will come. Open source software has thousands of eyeballs monitoring...
  2. Party Of One: Maintain The previous entry on one-man open source projects has talked about the development facet. Today,...
  3. Party Of One: Surviving A Hobby Open-Source Project Last week’s JavaOne had a separate track on open source, and there’s been a substantial...
  4. Party Of One: Develop As mentioned in the introduction entry, every one-man hobby open source project has three main...

7 Comments on “Party Of One: Conclusion”

  1. 1 Christopher Deckers said at 11:58 pm on May 17th, 2008:

    Great series Kirill!

    I think the sequence you describe matches what we experience when developing open-source projects.

    About having strict release cycles, this works when there can be more releases. If you have less and less things to add (feature complete), the gap between releases would just increase.
    And what about the problem of users thinking a project is dead when it is just “finished”? Is there such a thing anyway?

    I also found that 0.9 releases are good for people to be confident with the maturity of the project while allowing APIs to change. A bit like GMail which stayed in beta for long. Of course, there ought to be a 1.0 release, but this is a good way to get user feedback.

    -Christopher

  2. 2 BlaiseG said at 10:59 pm on May 18th, 2008:

    I’ve waited until this last article to congratulate you for this series. Now it’s done…
    Really good job Kirill.

  3. 3 Mike said at 4:59 am on May 20th, 2008:

    Well done. Thank you.

    ~ Mike

    Our project of two is architecture rules.
    http://72miles.com/architecturerules

  4. 4 Tarique Sani said at 3:42 am on August 11th, 2008:

    As author of several open source projects (one popular enough to have 5million+ downloads from sf) I don’t really get this piece on several accounts…

    Why is 1.0 so significant? With terms like promotion, strict cycle you almost rob the joy of programming – hey I hear those in my day job.

    and why is it so bad to let a project die?

    I most definitely let go of a project when #a it is no longer scratching my itch #b the users are not bugging me to continue.

    How about the best motivator of all – do the project because *you* want to?!?

  5. 5 Cal said at 4:22 am on August 13th, 2008:

    Thank you for writing this.

  6. 6 James Urquhart said at 8:03 am on August 13th, 2008:

    An interesting set of articles. I have to say, i wish i’dve read these before i started my Open Source project – since i can relate to a lot of what you describe.

    But then again, sometimes the best way of learning these lessons is by making the mistakes yourself. :)

  7. 7 Eduardo Grajeda said at 1:21 pm on August 31st, 2008:

    I didn’t though I’ll end up reading the complete series, but I couldn’t stop after the first post.

    Excelent job, thanks.