Let's Open Source Dog Agility!
05 Jun 2013
For today’s Dog Agility Blogger Action Day on Improving Dog Agility Organizations I’m proposing that adopting Open Source Software development practices can help agility organizations be more responsive, transparent and better serve their members. As some of you know I have two great passions: dog agility and writing software. My experience with Open Source Software (OSS) projects helped me realize they have a philosophy and techniques that can greatly benefit dog agility organizations.
OSS projects and agility organizations are typically started by a few volunteers with ideas for improving an existing product or create a whole new product. The products for an OSS project are the software and the resulting documentation. For agility organizations the products are the regulations and the infrastructure to enforce those regulations along with mechanisms for recording results and awarding titles. Both types of organizations may also organize and run annual meetings/competitions.
When most people download “Free” software from the internet they don’t think much about the people and processes used to design, create, test and maintain that software (or the countless unpaid hours that go in to the work). They are often all volunteer groups with some core developers who act to manage the project (and write software) and dozens to hundreds of other developers who might contribute a little of their time to answer emails, report/fix a bug, add a new feature, update/translate documents or write/run tests. The volunteers come and go, contributing when they can. The core developers use a number of (OSS) tools/websites to manage their projects, create the software and distribute it based on the efforts of all the volunteers.
Transparency
Transparency is the biggest benefit of OSS projects. Contact information for every contributor/volunteer is often available. All the software, the “source” files on which other projects could be based, are available on line. Furthermore, the entire history of every file (every change, who made the change and when) are tracked and can be inspected. Every discussion ever held (via email or chat) is available online and is searchable. Every bug report and the discussions by developers about if/when/how it will/won’t be fixed are also visible to anyone online. When a bug is filed anyone can choose to be automatically notified via email when there is activity or comments on that bug. Lastly, maintaining the reasons for not doing something can be very valuable when that idea is resurrected again years later - what if the reasons for not doing it no longer exist? Or if they are still valid they are easily found attached to the rejected idea.
In contrast, most agility organizations are run like “closed” source software products (think typical Apple or Microsoft products) where users can’t access the source files and the status of bugs is unknown. As “users” of an agility organization’s product/regulations there is no visibility in to what problems they are experiencing in the field (bugs) that might someday cause a rule to be add/changed/removed (a bug fix).
Like closed source projects, competitors often can’t directly contact the people who would actually change the rules. There may be email addresses to which problems can be sent and there may or may not be a response. But there is no way to view outstanding issues, discussions on how the organization might address them, track the status of a problem nor are there notifications if a problem is being resolved or ignored. When rules are updated the changes in language aren’t always easy to determine.
Lastly, the change process itself is often closed. Competitors don’t know the process by which regulations change and that is a great source of frustration. Some agility organizations are run like large corporations and others like (benevolent) dictatorships - but all would benefit by taking a more open approach to maintaining their open issues.
Users of OSS are their biggest advocates often because of the openness of the process. Their favorite features may never be added but, because they got feedback and they can see how the core maintainers respond and are responsive to user’s requests they still use and love the software. It really builds a sense of community.
Competitors want to feel like part of their agility organizations. The closed source approach imposes an “us and them”/“king and subjects” relationship between the organization and the competitors. Increasing transparency breaks down that wall.
Handling Future Change
As I mentioned before, future versions of OSS projects are visible (long) before they are released. Some projects may have a current release and several future versions of the software/docs available for inspection/download/use even if they don’t work yet. Since they are visible and actively being worked on everyone can:
- Easily identify changes between versions (there are online tools to show the differences).
- Comment on and discuss the changes and their implementation.
- Create their own modifications and propose them to the developers.
There are two key benefits to exposing future versions:
- Everyone who uses the product knows what is being worked on for the future. It may not be the final version, but they can see the direction and the viewpoints of members of the organization as the changes progress. Some changes may be abandoned or shelved. But at any time anyone can see where a change/feature stands. You never loose ideas, years later you can bring back a suggestion and base future changes on it.
- External contributors can bring in viewpoints/suggestions to improve the proposals. There is a tremendous breadth of skills among organization members waiting to be tapped. Furthermore it makes people feel like they are really part of the organization because they can directly impact it.
In OSS circles, a developer who submits their own modifications creates a “pull request”. That is, a request for the maintainers of the project to “pull the developer’s changes in to the product”. Most OSS projects have a core set of maintainers who review the pull requests.
Not every pull request will be adopted. But they all are visible to everyone and anyone can comment on those changes or further modify them. Typically the maintainers will comment on why they choose to accept or reject a pull request. More often they will offer additional suggestions to further improve the pull request and then accept the refined version. Many new features or improvements are added by a volunteer who was interested in investigating a problem and proposing it.
As you can see, there can be many people looking at every part of the OSS product - there is tremendous value in having dozens of experts pouring over every change before it is accepted. A well run OSS product draws the very best developers and the best ideas proceed based on their merit.
I think it would be wonderful if the thousands of smart competitors could make that kind of impact on their favorite organization. The work of the agility organization is then monitoring/refining/rejecting/accepting those suggestions and scheduling them in to “releases” (future versions of the regulations). The history of each change, all the supporting arguments pro and con, would be forever available and open for inspection by competitors.
Improved Communication
The last positive aspect of OSS projects I’m going to cover is communication. These projects are built on the nearly instant communication of the developers over chat, email and the OSS product’s source code/bug tracking websites. I’ve worked on projects where there are people around the world using and improving the product 24 hours a day 7 days a week. Modern technology makes that possible and young, computer savvy people expect that when they interact with a company/product support. Those same types of people are increasingly involved in dog agility.
Most agility organizations have web sites with regulations, registrations and FAQs to help inform current and future members. A number of them also have email lists. But some organization’s don’t have any officially empowered members participating in their organization’s email lists. In OSS email lists the developers are always members of the list/chat and directly respond to questions, bug reports and enhancement requests (often referring users to existing documentation in the bug tracking, source code, or online documents).
Dog agility organizations will better serve all members and especially younger, tech savvy members through an official and pervasive online presence.
Conclusion
Yes it would be a significant shift for agility organizations to change to be this transparent. But the benefits are worth it. They don’t loose control of their organization by doing it, they gain the knowledge and experience of dozens of experienced competitors to improve the organization. I think there are many competitors who would happily volunteer to help. OSS practices provide new and better ways to create products/regulations that could be: easier to comprehend - written for laymen, multilingual, better organized, etc.
Just knowing that they can make a difference will inspire members to contribute their time and expertise. That is what turns groups of people competing together into a community and a community that can make our sport better.
By working together with competitors agility organizations could make the sport easier to start in, more welcoming and responsive to their members.
If you enjoyed this article won't you please: 
Thanks!