SourceTree

From RCC 2007

Topics relating to SourceTree:

•Collaborative Decision Making for software development and code evolution.

•Distributed / Adaptive Data Systems like Congo-DB

View the notes from the strategic mapping conversation at Recent Changes Camp.

Read further for an introduction to SourceTree...

OSS Project Processes for the Information Age

The Current Landscape

We find ourselves having slipped into a new era, an information age where the rules and patterns have changed. This is no longer business as usual as it has been performed throughout the industrial era. Yet we remain saddled by many of our old models of thinking, decision-making and collaborating.

Open Source Software (OSS) development is a shining example of the new era. The cutthroat and monopolistic business practices with which companies like Microsoft have eliminated their competition and controlled certain spaces have proven ineffective to stop it as open source operating systems, databases, web browsers and development tools erode their market share. Ten years ago, most people would not have believed that groups of loosely affiliated programmers who are sharing their code openly and have no recognizable business model could produce more stable, more innovative and more efficient products than the corporate giants. Many still cannot see it, but there are irresistible forces afoot.

Some people recognized that we needed new systems of distribution and participation for OSS and web sites like SourceForge.net stepped up to provide valuable infrastructure for sharing OSS products and managing source code. However, even from such a leader in OSS (and throughout the OSS community) we find their approach is organized around old models of thinking, decision-making and collaborating. Even their software is centrally controlled, proprietary and sold for commercial use.

In some ways, we’re still saddled with some of the worst parts of the old system. Some projects are controlled by people whose egos impede progress and innovation. And those which aren’t, are often worse off: projects managed by committee.

We are still trying to sort out how to work in these new ways. I look at projects like Drupal and see a thriving and vibrant community of developers, and yet it is also a huge frustrating mess with each successive version creating significant compatibility with the prior modules and versions and still not correcting simple, fundamental things (like adding possessive forms to people’s names with “ ‘s “ even when their name already ends in “s”).

•How many OSS projects get pulled in multiple directions by people with different goals such that they fail to serve any of them well?

•How many projects have good ideas, and people who want to build them, but get stalled because of an inability to incorporate ideas and participation effectively?

•How often does a project get forked into a new one (the old one left to die) so that people can bypass political hurdles?

•How much redundant work is done on similar projects while there is no way of recognizing compatibilities of code?

Projects as Living Entities

What if we recognized that OSS projects exist to fill a niche in our technological ecosystem? Sometimes software “mates” with other software to produce offspring which solves different problems than the projects they grew out of. Some species of software can viably mix with others because they share certain core (genetic) patterns such as running on the same operating system, or speaking to the same databases, or complying with certain APIs.

What if we tracked and managed software in service to the niches it fills instead of serving our egos? What if projects could fork to meet new needs, but still remain a part of a family of software with the ability to share modules in common which comply with their backbone API? Projects departing from the core standards start new families with new standards. We can track genealogies of code. We can even reference prior projects which served only as an inspiration for new ones, but whose code was not appropriate to include.

We can implement collaborative decision-making tools, ratings, feedback and reputation let the projects be self-governing. We can use standards for sharing and hosting these systems to build a distributed network which is itself an evolving project serving the needs of developer communities.

We can include human dynamics and build more integral software development processes with the tools to support leadership, acknowledgement, conflict resolution, collaboration, task management and so on.

Some of us have started building a plan for exactly this kind of support infrastructure. We’d like to invite you to bring your wisdom and insight to help make this something which raises OSS development to whole new levels of productivity, fun and impact.

For now, it is code-named SourceTree.