Pragmatic Community Driven Development in Ruby

by Gregory Brown

This video, presented by Gregory Brown at MountainWest RubyConf 2007, focuses on pragmatic Community Driven Development in Ruby, particularly emphasizing the importance of community collaboration in software projects. The talk includes 86 slides and covers the evolution and challenges faced while developing Ruport, a reporting software package for Ruby, which serves as a case study for collective development.

Key points discussed include:

- Community Collaboration: Ruport's success is attributed to community effort, highlighting the need for collaboration when tackling large projects. Gregory encourages audience participation and reflection on shared interests and challenges in the Ruby community.

- Licensing Decisions: The importance of selecting the right open-source license for projects is emphasized, with Gregory advocating for simpler licenses like BSD or MIT to encourage broader participation.

- Communication Tools: The establishment of a focused mailing list helped streamline contributions and discussions, leading to an efficient development process. The introduction of Trac as a bug tracking system improved organization and community engagement.

- User-Centric Development: Projects should prioritize user needs and experiences, ensuring that contributions align with these priorities to avoid disappointment among users.

- Project Identity and Goals: Maintaining a clear project identity while being open to diverse ideas is essential for fostering a productive community. Setting precise goals will guide project evolution and responsiveness to community feedback.

Significant examples include the challenges faced in the early stages of Ruport's development and the lessons learned regarding licensing and community engagement. Gregory shares insights into problem-solving and practical approaches to community-driven software projects, urging members to maintain open channels of communication and support one another's contributions.

In conclusion, the video underscores the importance of collaboration, accountability, and shared experiences in community-driven software development, inspiring attendees to enhance their contributions to the Ruby community and the broader open-source ecosystem.

Overall, Gregory Brown encourages fostering a culture of collaboration and knowledge sharing in order to fully realize the potential of collective contributions in the Ruby ecosystem.

00:00:06.720 Hello everyone, I'm here today to talk to you about pragmatic Community Driven Development in Ruby. I have 86 slides to go through in about 35 minutes.

00:00:33.840 The real title of this talk is "Rolling the Dice with Ruport," which is a reporting software package for Ruby. However, I decided not to use that as the title because I know that reporting can be a dull topic. The most significant aspect is that Ruport is a product of community collaboration; it wouldn’t have existed without a community effort. When we started developing it, it was evident that the task was too large to tackle alone, making it an excellent case study for others facing similar challenges.

00:01:15.420 I want you to consider some important issues and start a discussion. Ruby is in a stage of rapid growth, and our identity is changing. It’s essential for us to define what that identity is. Issues such as building a community and working cohesively within it are crucial. If you take anything away from this talk, I encourage you to get your voice heard, contemplate these issues, and help shape the community.

00:01:54.180 Feel free to engage in discussions on IRC while I’m speaking; I would love to see what comments you share. One good question to start with is: why are we here? Perhaps it’s a passion for Ruby, maybe we have a need for Ruby, or perhaps we’re just curious.

00:02:31.620 The reality is we share a community; we are here together because we have common problems we want to address. This implies that we can collaboratively focus on and resolve those problems. But what kind of problems are we facing? These can be ideological problems, issues with our software methodologies, or struggles with community building.

00:03:01.260 For instance, a joke goes around about some philosophical disagreements mostly within the Debian group regarding the classification of the Firefox logo. While that may concern ideology, it surely isn’t a pragmatic approach to dealing with our tasks. Our focus should be on solving practical issues in software development. The best way to achieve this, particularly in a growing community, is by leveraging our collective strengths, common interests, and needs.

00:03:37.620 It’s important to share bad ideas and implementations; if you don't, they’ll likely never improve. An adage expresses that with enough eyes, all bugs are shallow. The same applies to ideas, and while this talk might include some bad ideas, we also have many eyes examining them.

00:04:11.099 Let’s analyze a project with a strong community around it, even if it’s sometimes edgy to critique one’s own work. My experiences over the last 20 months with Ruport, and the bad ideas I’ve encountered, contribute greatly to the learning process. Although Ruport wasn’t initially meant for community use—shared with only one other person, James Edward Gray II—we were in informal competition to develop mini reporting frameworks. The original code was under GPL due to my roots in the Perl community, but I didn't initially grasp the implications of that choice.

00:05:51.660 When starting a project, especially one intended for community input, you need to consider licensing from the outset. License choices are difficult to change later and can significantly affect your project’s development. I propose that when building a software community, pragmatism should take precedence over ideology. The right license depends on your project’s goals. If your aim is to promote free software, sticking with certain licenses might be fitting. However, a community that embraces diverse interests might benefit more from simpler, permissive licenses like BSD or MIT.

00:06:56.819 These types of licenses seem popular within the Ruby community, but issues arise if the project is ever misappropriated or becomes incompatible with GPL. The simplest path is to use established licenses approved by the OSI or the Free Software Foundation to gain credibility. Once you establish the right license, it’s about compromise—not just about individual ideologies, but about enabling collective participation.

00:08:26.720 Free software is a shared gift. By releasing code under a license, you’re offering it to developers and users. I recall an interesting conversation where someone noted that BSD/MIT licenses favor individual interests while GPL serves community welfare. That’s a fair distinction. The Ruby license is thankfully clear: it guarantees GPL compatibility, allowing for flexibility when integrating with other software that might have stricter licenses.

00:09:58.380 Our licensing discussions for Ruport led us to realize we needed to adapt for our software's domain—reporting, a complex field prone to various challenges. We recognized that to grow effectively, our reporting software must integrate seamlessly with other applications, including those governed by less favorable licenses. We collectively decided to utilize the Ruby license, a safe compromise that encourages wider participation.

00:11:57.420 As our community grew, so did our interactions: we started receiving names for new features primarily through mailing lists and blogs, which indicated that our software was gaining traction. Ideas and feedback from a diverse audience enlivened our discussions, spurring innovation and improvement. However, we faced the challenge of managing many requests while trying to maintain a clear vision for our software.

00:13:10.139 We established a mailing list in December 2006 with around 10 to 20 subscribers, allowing for focused discussions among core contributors. This smaller group was beneficial; filtering through a few emails each week proved far easier than scanning thousands like we had been. The discussions quickly transformed into constructive development, leading to valuable contributions such as bug reports and patches.

00:14:53.760 However, we learned that a mailing list isn’t a bug tracker, a point many contributed to our eventual realization. The need for better organization became apparent, and it was difficult to navigate the torrent of ideas flooding our discussions. We ultimately needed a proper bug tracking system—not just for the sake of organization, but to engage with the community effectively. We turned to Trac, which provided integrated systems to communicate well with both users and potential contributors.

00:16:20.699 Moreover, using Trac allowed for remote engagement; users could follow RSS feeds and readily access all project updates without wading through the expanse of RubyForge. The challenge was ensuring that while leveraging such tools, we maintained our project’s visibility and community engagement without compromising our primary goals.

00:17:52.440 Introducing effective tools dramatically impacted our project's health and community contributions. It became evident that the tools we used could either promote or inhibit our growth. One pivotal change was migrating to Trac, which led to heightened interaction and engagement from contributors, providing the gratifying experience of watching the project develop rapidly. Ideally, contributors should be encouraged and inspired rather than met with unnecessary obstacles.

00:19:13.680 As our community continues to grow, it’s crucial to separate essential project features from developer conveniences. Addressing contributions can lead to misunderstandings and result in partial implementations, which can ultimately disappoint users expecting a complete offering. Always prioritize the users' needs and experiences when developing features.

00:20:36.639 Reflecting on our project identity, we aimed to establish a shared vision while allowing room for individual contributions and brainstorming, even for seemingly offbeat ideas. We strive for a unique project identity focusing on diversifying the development process, ensuring the community’s wealth of opinions is woven into the software’s evolution. We've aimed to maintain a blend of boldness and caution as we expand our scopes and remain open to adapting the project’s direction.

00:22:36.480 Looking ahead, it’s vital to continually define our objectives clearly. Our development processes should inform our identity and understanding of community-driven projects. We require precise goals guiding the project's growth while remaining responsive to the community's feedback.

00:23:25.260 Sharing experiences allows others to learn and refine their approach to community-driven software development. As we venture into the future, I'd like to encourage everyone to reflect on their projects, considering what uniquely distinguishes them while also appealing to broader interests.

00:25:25.260 In conclusion, I hope this provides insight into the evolution of community-driven development, focusing on accountability, collaboration, and pragmatic storytelling through our software projects.

00:25:40.900 Before I wrap up, how many of you are involved in any free software project? Awesome! I find that such interactions spark discussions that lead to meaningful changes in our practices and foster contributions. Often, it’s the little things, like clarifying documentation or guiding users, that stimulate a thriving community.

00:27:59.659 Process documentation can greatly enhance our project dynamics, bringing intelligent users into the dialogue while fostering excitement about future contributions. Sharing knowledge is vital for integrating various user experiences into the software and building a cohesive, productive community.

00:28:57.000 Thank you all for your time, and I hope that together we can continue to enhance our community, making Ruby the best it can be and producing valuable contributions to our open-source ecosystem.