Knowledge Sharing in Sakai
In this, my first post at Three Canoes, I wanted to make an observation from working as a consultant in the Sakai open source community during the last 7 months. I have had the opportunity to work with two universities and two vendors as a subcontractor.
One of the paradoxes of trying to eek out a living as one who supports open source software is that it is tempting to hold your cards close to your chest and suggest that any knowledge transfer must be paid for. It is tempting to repeat the same old trick over and over again. For example, I have a decent handle on how many of the Open Source Portfolio tools can be configured to support different portfolio scenarios. One of the trickiest bits to using the OSP tools involves iteratively writing the XSL file that gives the portfolio tool its marching orders on how to organize and display the student portfolio from a pile of assembled content.
If you follow the Sakai and OSP lists, you know that I regularly participate (for better or worse) in discussions and provide some support to newcomers to our community. A frequent request is for help building forms or templates with the OSP tools. Now that I do this sort of thing as a job, it would be great if I could I get paid for that sort of work, but I don't. I just referred a potential client to the documentation I created during the work I just completed for Weber State. Essentially he wanted the exact same sort of service as I had just performed for the folks at Weber. The documentation I wrote was sufficient enough that it took him where he needed to be to make progress on his project. As a result I may never get to do that work for that client. C’est la vie.
Wouldn't it be tempting NOT to tell anyone how to do this work? Sharing that knowledge instantly makes that service less valuable. (I’ll argue that unless you intend to build a lot of these templates, it may make good sense to outsource this mini design and development project to someone already familiar with the process as a time saver.) However, it doesn’t make sense to be required to outsource simply because you don’t understand how the pieces fit together. That should be made known. I wouldn't feel bad helping someone the first couple times, but then it gets old and I would rather spend time organizing the information so that the process is well understood. Now THAT is a service that benefits the whole community!
Many open source projects suffer from lousy documentation. In Sakai’s case, the documentation lags the current versions of many tools (where it exists at all) because the priority is placed on building the next release and not on documenting it in an easily digestable format. There are probably a lot of similar bits of technical/pedagogical know-how that are tricky to understand and are poorly documented. It doesn’t seem to be in the immediate interests of the Sakai Foundation to fund an extensive Sakai manual. The community hasn’t spontaneously created a usable one in the wiki (at least if newcomers are evaluating it). Even the Sakai "book-in-progress" will quickly become obsolete. There will always be a need to keep current. Wouldn’t it be in the best interest of the contractees to ensure that contractors working on Sakai make any new knowledge public (and be willing to pay for it)? Wouldn’t there be a value to a vendor willing to act as another set of hands willing to help test and document your newest development effort and make it all public?
I have a belief that the speed of innovation in Sakai is such that there is a constant demand for elaboration and clarification within the community. I want to be paid to create NEW intellectual property for the community I work in, not to resell at a high margin what could (should) release as public information. In much the same way that the developers in the community write and contribute code (their embodiment of knowledge) to a public repository, I would like to create, contribute and disseminate technical and pedagogical ideas to the community in an easily digestable format.