Based on the relatively small mindshare ChiliProject currently has in the Rails and general Ruby "population", I want to find axes for a ChiliProject-centered presentation to spread the word about the fork, explain it, gain mindshare and visibility and maybe win one or two devs over to help. The purpose of the to-be presentation is not to explain (longer than 3 minutes) what ChiliProject does as the assumption is most of the audience knows about Redmine, nor is it intended to be a training for people who already use it ("did you know about our awesome right-click menu on the issue list?") but to gain mindshare, visibility and new devs.

Now here are the general ideas I worked into my previous presentations:

• Why fork?
  • Community reasons
    • No clear roadmap/vision: versions get dates and suddenly don't have anymore, there is no "clear" rule what goes in what verson, there's no communication about what to expect from future revisions. This is frustrating for users as well as for fellow developers who are not always (ever?) taught about those changes.
    • No community management: Communication with the community happens through news and occasional forum posts, the latter coming nearly exclusively from committers/developers rather than the "lead", the committers/developers can most of the time only temporize though as they often don't have more information than the rest of the community.
    • Next to no communication: Communication with the project lead is difficult at best, non-existent most times. Example: I have been promoted committer without even being notified about it, I have been made administrator of redmine.org only on "want to?" "yeah, why not?" without anymore guidance, dos and don'ts or a clear communication channel to hit in case of problems/uncertainties.
    • No visible interest in fixing it: When confronted with them the problems seem to have just been ignored, any proposal to help remedy the situation hasn't received the necessary attention or "authority" for it to bear fruit.
  • Technical reasons
    • No technical "guidelines": I don't really see any commit, code or "style" standards or even (constructive) criticism other than "just commit it" or "does some rework and commits it without giving feedback to the committer".
    • Split response to refactorings: Ok, so I'm not that sure about that one anymore because this argument was tainted with backstory/bad blood, but the fact is that we still have rails 1 (and probably even pre-1) code.
    • Erratic versioning: The versioning is hard to follow or predict making it harder for admins/packagers to know "what they get".
    • No real security management: security issues are often fixed on trunk potentially divulging them early, and the fix might sit on trunk months before being released as part of the next best version coming along.
• How does ChiliProject address those problems?
  • Clear and open governing structures,
  • Adherence to the "Free and Open Source Ideal",
  • Planned development and releases,
  • Community involvement,
  • Responsible disclosure and timely security releases as necessary.
  • (or at least we try hard)
• Chalenges ChiliProject faces
  • Big codebase: on Holger's count we're at ~41000 SLOCs (down 5000 from Redmine) with a more or less 50:50 code/test split. We've shaved 10% off, we can go further, less code for us to maintain.
  • Old codebase: and edit action through post and Controller actions that test if they are post or get. That was fine years ago, there's newer best practices though.
  • Javascript: it's prototype and really sprinkled every which way across the app. We're trying to get to JQuery and more uniformity.
  • Not Invented Here parts: there's a not insignificant portion of the code that tries to solve already solved problems that should probably be phased out to work with externally maintained gems/libs.
  • Vendored gems: some gems have been vendored and patched "to death", coupling them to the app and making updates harder.
• What we've achieved
  • s/svn/git/ (yeah, the switch to git as the main repo was a middle-ish interest to some)
  • Bundler
  • Ruby 1.9 (except for some last-minute edge-cases)
  • Rails 2.3-latest
  • Security releases
• What's next? (3.0)
  • New design
  • Liquid for formatted text
  • "Itches"
    • Separate mails instead of (B)CC-ed mails for notifications
    • reposman as a gem (OK, maybe not quite for 3.0)
    • API work
• And then?
  • Rails 3.1
  • s/Prototype/JQuery/
  • Tentative JRuby support
  • More API work

Ok, this turned out a little longer than I had thought.

The topic I wanted to work into this for future talks/presentations is that the Ruby and Open Source community in general need and deserve a better general-purpose project management system (as opposed to e.g. GitHub which does great on Code, OK-ish on issues/milestones, but can't really be used for anything else than code or onsite except for big money), with examples of how it is used by non-technical teams at some of our clients' or even adapted by us to accommodate another use-case than "pure" project management (not official yet) (yeah, those are examples from finn, but that's the ones I know about, I'm happy to hear of more). This topic would need some research into "competing" products like trac, jira and maybe basecamp and so on to be complete and credible though.

Any more ideas you'd want to see in stuff like that?