\nMountain West Ruby Conference by Gregory Brown
\n16 March 2007
\nPragmatic Community Driven Development in Ruby. Or “Rolling the dice with Ruport”. “Reporting Sucks”.\n<\/p>\n
\nGregory spent several minutes at the beginning of the presentation trying to get his Nvidia X display settings worked out for both the projector and his screen. None of the other people using Linux desktops had the same problems, and neither did the people using Windows or Mac OS X.\n<\/p>\n
\nRuport couldn’t have happened without a community to support it. Community = people + problems. Why is community important? Community helps root out bad ideas, and we all have bad ideas. With a good community, you can discover bad ideas sooner, and replace them with better ideas (hopefully).\n<\/p>\n
\nHow do we leverage community? One aspect is to pick a license that encourages people to get involved.\n<\/p>\n
\nWhat license do we choose? Licenses aren’t as easy to “refactor” as code. Choose a license that is “right” for your project. Don’t write your own. In order to be taken seriously at a community and at a corporate level, pick one of the already approved OSS licenses. Picking a license is a compromise.\n<\/p>\n
\nBSD\/MIT favors individuals.
\nGPL favors communities.\n<\/p>\n
\nReporting is a big domain. Sometimes, it’s necessary to integrate with software with less than ideal licensing terms. The Ruport community chose the Ruby License.\n<\/p>\n
\nCommunities are idea warehouses.\n<\/p>\n
\nYou can only really work passionately on your problems. Find people who have the same problems. Learn to say “no”. Sometimes, less is more – you’ve got so many ideas floating around and such large groups – sometimes you need smaller groups and a focused, trimmed down set of ideas so that you can define software and implement it. It’s easier to read tens of emails per week than thousands.\n<\/p>\n
\nDiscussion led to code, which led to bug reports.\n<\/p>\n
\nMailing lists are not a bug tracker. Gforge is, but it does too much. They decided to use SVN + Trac for Ruport. Allows a casual user to subscribe to what’s happening and to contribute. It’s amazing how much good tools can affect a community and allow contributions. But what about RubyForge? Virtualy all interesting Ruby software is on RubyForge, which gives your software exposure. They used svk and cron to mirror their repository over to RubyForge.\n<\/p>\n
\nFriction affects contribution. Explain how people can contribute bug reports, patches, etc.\n<\/p>\n
\nEvery patch is valuable. Not every patch is suitable, but the relationships you can establish are important. Patches (suitable or not) give you an idea of what people are trying to get out of your software. Still want relevant patches. What is relevant? It took them 15 months to figure it out – way to long. They came up with a roadmap and a scope definition. They didn’t just scope features, but the design as well.\n<\/p>\n
\nWe have to be careful not to accept code\/features that are only for ourselves – that will never be used by anyone else. They moved some things out of the core into plugins.\n<\/p>\n
\nUnique project identity is good. Half-way implemented features are bad for users.\n<\/p>\n
\nRecommends the book “Producing OSS Software” by Karl Fogel, which is available for free online.\n<\/p>\n
\nRuport 1.0 will be released on May 15, 2007.\n<\/p>\n
\nSometimes, developers have to “hide” from the large community surrounding their project, simply because they don’t have time to respond to all questions and ideas. They have to make time for families, work, and for development. It’s good to get smart users involved to help answer questions.<\/p>\n","protected":false},"excerpt":{"rendered":"
Mountain West Ruby Conference by Gregory Brown 16 March 2007 Pragmatic Community Driven Development in Ruby. Or “Rolling the dice with Ruport”. “Reporting Sucks”. Gregory spent several minutes at the beginning of the presentation trying to get his Nvidia X display settings worked out for both the projector and his screen. None of the other … <\/p>\n