San Francisco
Adam is a Shuttleworth Fellow and coFounder of the Collaborative Knowledge Foundation. Previously founder of FLOSS Manuals, Booktype, and Book Sprints.
Adam is a Shuttleworth Fellow and coFounder of the Collaborative Knowledge Foundation. Previously founder of FLOSS Manuals, Booktype, and Book Sprints.
Authored Comments
hey Aaron, Good points (and thanks for reading the article so closely). So...my point is that there is a large cultural difference between how open source is produced and how proprietary software is produced. Most modern software production processes that I have seen or read about in the proprietary world spend an awful lot of time (one way or the other) with target users and stay with them right through the process from design to going live (and after). Open source culture *can* use some of the methods proprietary projects use but I would argue that it has to be done in a different way - a way that is more appropriate to open source culture.
So, the question for me is - how can open source evolve to develop fantastic user facing software in a way that feels like it is 'the open source way'. Here I think we are leaving a lot of value on the table because open source projects that have users don't know what to do with them. Sometimes they get asked to file bugs, or do documentation, or marketing etc...but aren't we missing something here? If users are wanting to be involved why not involve them in a far deeper level? They are, for example, the best use case specialists you will ever have. So how about bringing them in as core team to co-design the software? Then you couple the people with the itch (the users) with a team that can help evolve the solution.
As for the economics of it. I think people like working in teams to solve problems together. I also think people love to volunteer to do these things. That is pretty much what community is, and open source (IMHO) needs to start working out how to include a broader skill base (use case specialists, UX specialists etc) at the core of the project (not tapped on the outside as an afterthought). Its not that difficult an issue to think through and start tackling, and I think open source at large, and any given project, would benefit greatly from this.
Also, I'll be writing some more on this topic in future articles here (if opensource.com approves!).
hi Jim, Thanks for the comments! My point is that the itch-to-scratch model should be for everyone, not just for developers. So you need to look for people of all types (devs included) that are sympathetic to your goals and try and convince them to get involved. Since self-interest is really the driver here I'd ask yourself if what you have to offer is really appealing to the diverse roles that you wish to see involved. In essence, consciously designing your community processes to bring in the kinds of people you are looking for. Its hard work but not impossible.