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.
