At the very moment when venture capital is concluding that open source software is now simply the default option and proprietary software is no longer sustainable as an investment strategy, open source as a development strategy and commons-oriented framework is also fast moving in the field of ‘physical production’, particulary in the field of appropriate technology.
In Agroblogger we find the following item describing what needs to be done to bring AT on a par with developments in the field of software:
Progress has been made:
the somewhat nebulous concept of Open Source AT is now becoming a reality. Just take a look at any one of the aforementioned online communities; they are vibrant and growing, and within the context of each community their exist subcommunities around a specific project or idea, like the Hexayurt. So yes, great progress has been made.
Problems remain:
But as we move forward, there are still a lot of questions to be answered, and more obstacles to be overcome.
First, is the question of accessibility. It is true, the information is out there, but the online communities that contain the information make it somewhat more difficult to access than is ideal. The notion of having to filter through at least four different online sites looking for a specific solution is a daunting task, and becomes almost impractical for all but the most dedicated. Consider that the Honeybee Network has thousands of different innovations; to date, their user interface is not advanced enough to provide information with a couple of mouse clicks.
Anybody with the the initiative to include their information on these websites would be somewhat deterred by the prospect of having to reproduce the information four, five, six…times to give it full coverage on all of the different existing communities. What is becoming evident, is that a wiki is a very blunt instrument indeed for the much more detailed process of collaborative technology development. Open Source software is leaps and bounds ahead of the OSAT community. Linus Torvalds no longer submits much code to the kernel; by his own admission most of his time is spent tracking submissions from the community, and coding a sophisticated tool he has developed to keep track of those contributions.
Similar tools for the OSAT community are conspicuously lacking. To move forward, we cannot continue to believe that simple tools like wikis and community forums will be sufficient to get full leverage out of the technology development, validation, and deployment process. After all, we want these tools to be deployed in the field, as quickly as possible, and we want to create viable business models around the technologies in question. Why should we continue to drive screws with a hammer? To do this right, we need the right tools.
Proposal for a way forward:
The first step is to take a page from the FOSS community, and make a call for the development of a software package that is specifically designed to design, document, and track technology development. What might such a tool look like? Before I attempt a description, I should note I’m not a software engineer. I do, however, have a great deal of experience as a Linux Sys Admin, so I have a general feel for how these types of systems work and how they are configured, though very little experience with actual software design and coding.
Immediately, it occurs to me that such a system may require a backend and a frontend. The backend would be some kind of server-based database that keeps track of changes to the information, then serves up those changes to the community of users who are running the frontend GUI on their client machines. Also, the backend would serve data to a web interface where general users/browsers could access the information without any real need for getting into the meat and potatoes of development. The description is very similar to something like Joomla, Drupal, or WordPress.
In the case of a frontend running on the client machine, WordPress provides a compelling example. The Qumana blog editor provides a nice analog for a front end OSAT development tool. Qumana interfaces with a number of blogging engines, including the GPL WordPress CMS, and allows bloggers to edit and post blog and photo entries to a WordPress blog through a very accessible and powerful GUI interface.
Now, let’s imagine for a moment a similar setup, specifically designed not for blogging, but for appropriate technology development. Through the frontend, users could manage a number of related products during the development process. Documentation could be written and updated on the fly, as the database is updated, changes would ripple through the community instantly. A photo manager would help users to categorize and tag photos. Business opportunities could be created in niche areas, much in the same way developers have taken advantage of the opportunities around SugarCRM. Programmers could write plugins for an ArcGIS bridge, or an AutoCAD bridge, tools that the whole community may not need, but certain types of people would surely benefit from. These plugins could allow a user to import all emails with a certain tag or subject line into the database, or could update changes made to a CAD file and immediately post them to the server backend. The frontend would allow for the management of licenses, contact information, and well…any other information that the community felt needed management and organization.
Online communities like Instructables and Howtopedia may fall to the wayside when anybody with a LAMP server and an Internet connection can setup an entire OSAT development kit on their network. This doesn’t mean that these groups wouldn’t have a stake in the development of such a software package. I would imagine that their role would shift from central organizer to more of a tracking role, keeping tabs of changes in different projects and providing a searchable index of different information, much like the shift we have seen in the past 4 years from Kazaa to the Pirate Bay as the primary tool for file sharing. And, they could also provide an already configured backend for those people who don’t have the bandwidth, the technical know-how, or the time (or any combination thereof) to setup their own LAMP server.
It is not far-fetched to think that this tool does not need to be built from the ground up. Perhaps an already existing CMS like WordPress or Joomla could be forked, or a detailed Joomla component could be developed for this purpose. All of these are possibilites that I put out there to the community to debate and consider.”
Thanks for posting that – I’m longing to see such tools developed. As I reponded at the agroblogger site, a wiki is a blunt tool – yes, and sometimes a blunt but flexible tool is needed. The special design tools needed by the design community need to be integrated with methods of sharing broader information, experience and ideas, fact-checking, brainstorming and networking. A wiki enables this.
And, as a geeky friend responded when I send them this link: “Yeah, that’s why mankind invented plugins. ;-)”
Michel,
This is the project I have been working on for the last year or so. It is really nice to hear other people thinking about it.
I will not go into details of the solution I have been working on here but I will say that when I first approached this problem I was hoping to solve the issue of people in isolated conditions where it is dificult to take advantage of ones potential. I considered one instance of this being people like design students and young designers who are new to the market. I think there is a lot of skill that is not used and a lot of human assets which could be empowered by good implementation of such a system.
I strongly agree with Chris’s geeky friend and I think the backbone of this kind of system really needs to be a plugin based architecture as the advantages of a community application centric approach are incredible. However I also think the suggestion that a Wiki is a good base model is not universally accurate. I found that a simple information standard was a good place to start but that using an unrobust information standard, from a communications point of view, would probably cause serious latency issues. I think wiki is in general the definition of a well connected but unrobustly managed system. My attempts to use similar services for this kind of system did not work well for various reasons, including the lack of a strong information handling framework. At this point I have found an alternative which seems advantageous.
Mark – would be interested to know more of your work. I really believe in working together on these tasks as much as possible.
Unfortunately I couldn’t understand a lot of what you wrote after “not universally accurate.” Sent the link to some more software savvy colleagues for comment.
Chris’s geeky friend here. I’ll try to translate Mark’s comment into non-geek speak first (with some guesswork commentary – Mark, just holler if I guessed wrong).
I think the backbone of this kind of system really needs to be a plugin based architecture
“Any software system that helps people document engineering projects and appropriate technology needs to be really modular, made of a lot of customizable little parts (plugins) that individuals can put together to build their own solutions (as opposed to a gigantic one-size-fits-all application).”
as the advantages of a community application centric approach are incredible.
“If appropriate technologists are able to customize their own software solutions from premade plugin “building blocks,” they’re more likely to get invested in and enthusiastic about the software, contribute to it, use it more, help each other work with it, form a community around the software (and use it to help their own communities form).”
However I also think the suggestion that a Wiki is a good base model is not universally accurate. I found that a simple information standard was a good place to start but that using an unrobust information standard, from a communications point of view, would probably cause serious latency issues.
“Wikis may not be the right place to start, though. When you’re trying to communicate technical information, you need to have some agreed-upon format and structure (a “simple information standard”) to your communications. If you don’t have some preset structure and just let people write anything anywhere in any format (as on a wiki), it takes a really long time for people to get their point across (“serious latency issues”).”
I think wiki is in general the definition of a well connected but unrobustly managed system. My attempts to use similar services for this kind of system did not work well for various reasons, including the lack of a strong information handling framework. At this point I have found an alternative which seems advantageous.
“Wikis make it very easy to connect bits of information to each other (by making links), but they’re hard to manage and restructure and clean-up when the information starts getting messy. I think I’ve found a better way.”
(End translation, start comment)
Also, there’s no reason that additional structure can’t be imposed using wiki software as a base. Wikis start out with a lack of structural definition precisely because the users are supposed to add their own structural restrictions – but you get to choose exactly which freedoms to remove. (This is often done via plugins, actually.)
There’s no reason why you can’t make some or all of your pages pass through a validation of some additional syntax/structure you’ve set, no reason why you can’t specify (in rules or in code to check those rules) that pages should be titled just so, linked in this location, and so forth.
That having been said: Mark, I echo Chris on being curious about the “alternative which seems advantageous” you mentioned. Mind telling us more about it? As an engineer myself, I’m always on the lookout for better tools.
I am really sorry everyone, for writing so cryptically and being unspecific about the solution I am interested in.
Mel – Thanks for your translation which is great. I think I would say my phrasing of why a plug-in architecture is so important is not just improve flexibility but also to improve personal context. This is however a moot point and I think it will not change much in the outcome.
The advantageous thing I was talking about is just a method of tracking changes to many kinds of information through a single interface. It would include changes in things like image files, text files, other data files but also on a ‘meta’ level (information about information), different representations of content or different renders of output and then further more, on an information architecture level (how information corresponds with other information in the system) changes and developments of workflow are also relevant within the system. Another aspect of this system is that it is not just based on versioning but also interconnection and creates an interface for the formal control of linking between files to produce desired outcomes.
This solution is not really interesting to solve the specific problems mentioned in this article however I think it offers some tools that would greatly benefit collaborators and users in most systems. I am working on this system as part of a long term project and right now I call it File Tree. An example of an asset management system with similar ideas in mind is Shake, the compositing software from Apple Inc.
I am currently quite interested in getting some of my recent work developed to form an attention economy funded collaboration network. At this point I am just about to graduate from Uni so I have not put much time into seeking development yet.