Social software development

For a couple months I've been toying with an idea to merge the community organizing and marketing power of electronic social networking to the FLOSS software development process. I've found that the easiest way to get the answer you are looking for is to ask the right question. There are currently too many real and imagined barriers preventing non-technical end users from asking the right questions. Increasing end-user knowledge of software tools across the board in general and allowing immediate involvement in the development of their tools in specific should increase the ability of the end user to ask the right questions to get the right answers.

Like I said, I've been kicking this idea of mixing non-tech and uber-tech around for a couple months now. Through the brain storm, I have asked for the thoughts and opinions of multiple people of both tech and non-tech persuasion. Both the non-tech and the tech has consistent responses.

Responses
First, from the non tech respondents: How do I sign up?

Non-technical end users have been lead around the nose with the promise of salvation by cool tech toys only to be disillusioned by the perversions of procurement, the fickleness of contractors, and eye-in-the-sky disinterested leadership. The people I talked with want to be involved in creating their toolbox but they have been put off by perceived lacks – time, tech knowledge, information about how to contribute, and no easy first step into contributing.

Underlying critique/problem/emotions(can be conflicting): desperation, despondency, frustration, technical ignorance, and passivity.

Now for the tech side: Why would we want to do that?

We've got a good thing going on and bringing in the ignorant masses, however well intentioned, will only slow us down. End users don't know anything about our work and they're just going to screw things up and make life difficult for everyone. Just let us figure out what you need, we'll make the code, install it, and teach you how to use it. Your opinions need not apply.

Paternalism and noblesse oblige– meet the digital age.

Underlying critique/problem/emotions (can be conflicting): insularity, complacency, mild case of the lazies, and worshipers at the alter of efficiency.

Middle ground
Where is the middle ground? On the one hand we need to convince the non-technical end user to reenter the fray. End users must be convinced that their contributions, thoughts, and advice are valuable. Successful (software) projects require the experience and participation of the people who will end up using the product. It may sound naive, but we need to grow some hope that tools may improve and meet the evolving needs of the user.

On the other side, we need to encourage technical minded people to wade into the messy gray areas of the end-user experience. Involvement consisting of a brief "requirements gathering" session will not yield the necessary results. Technical people have to understand the true need for a tool and understand the day to day ebb and flow that will color the use of the tool. Technical people need to get dirty and yes, gradually educate the non-technical.

Development models (thanks Wikipedia)

1. Waterfall development

Waterfall development is the codified process for creating a product, any product, that strictly adheres to a preformed work plan. In Waterfall development, you cannot move on to the next step in the process without 100% completion of the previous step. Most often, if the requirements are not considered adjustable, many of the functions developed are not utilized by the end user. No matter how rigidly the Waterfall development model if followed, allowing any flexibility with the requirements introduces better functionality into the end product and puts you on the road towards iterative, extreme, and agile development.

2. Iterative, extreme, and agile development

These three models of development focus on growing complexity and functionality rather than master-plan designing it. Many of the features of these individual development processes focus on incentivizing short bursts of productive work. Some of the most distinctive attributes include writing the tests before writing the code, releasing functionality early and often (buggy or not), allowing for goal posts to shift in between releases, and a willingness to make something work and then worry about making something pretty.

This may sound messy. It might be messy. This method has also been proven to produce more creative results and products. 37 Signals provides a great commercial example of extreme programming

So where can non-techies fit into the development cycle?

Waterfall development asks the end user to create the project requirements and then hand over all responsibility to the project technical lead. Iterative, extreme, and agile development moves too quickly to allow for such a neat division of labor.

The non-techie user can and should participate in any step in the design cycle. They can plug themselves in wherever they like because the development cycle is completely transparent, has low barriers to entry, and constantly requires the informed opinions of the end user. Without this input, the development cycle reveals itself as an unsustainable dissipative structure. End-user participation can come in the form of bug reporting, revising or creating documentation, user help and support, critiquing the graphical interface, requesting new features, testing recently released features, and yes eventually working on the coding should they feel up to the task.

How does one find a FLOSS project to work on?

The easiest way is to rely on the community. Ask people who use FOSS what they could suggest for your problem. If nothing else, they'll point you to someone who might be able to answer your question.

The other way to do it is to check some of the massive online project repositories. Sites like Sourceforge or Google Code are massive repositories of open source projects that are geared towards the developer who knows what project s/he wants to work on. But what if you have no idea what you're looking for?

Social Source Commons

Enter Social Source Commons. Social Source Commons is a web based social networking tool that lets you see what your friends, colleagues, and professional networking contacts are using for software. The site is not limited to FLOSS, so you get a complete picture of the range of options you might have to choose from. An additional unique feature of Social Source Commons is the ability to create and share a toolkit. A good example of a toolkit is the CiviCRM toolkit that packages together a suite of applications to help non-profits manage their constituent relations.

Once you find the software you're looking for, if it turns out to be a FLOSS project, the software description includes a link directly to the development community.

The code that makes up the Social Source Commons website is, itself, licensed as a FLOSS application. To make the application truly useful, the website needs a few more features including the ability message a friend, rank software on a standard scale (5 stars?), and let people suggest FLOSS alternatives to any proprietary software that is suggested/listed on the site.

Altogether, Social Source Commons provides software usage transparency, an open method for comparison and software research based on trust, links directly into the development community for non-technical end users, and the ability to modify the site itself to anyone passionate about the project and idea. End-users and techies both should use the site. End-users to discover new software and find the communities to support it; techies to find users and better understand the way the tools are used.

Social Source Commons just might be the necessary middle ground.