The growth and corporate adoption of many community open source projects is hindered by the lack of commercial support. At the same time, well working community open source is a temptation for startups to make a buck by turning the community project into commercial open source. We can currently observe the unraveling of such a story.
TWiki is a community open source project, a successful wiki engine, and the company TWIKI.NET is trying to turn it into a commercial open source project. This post discusses some of the levers and dynamics of this process. But first, to clarify terms: Community open source is open source owned by a community with no single dominant stakeholder, and commercial open source is open source owned or dominated by a single legal entity, typically a software firm that wants earn money with it.
Most authors transfer their copyright to the ACM when having their papers published and archived in the ACM Digital Library. While the ACM allows authors to provide their papers on personal servers for non-commercial purposes, the goal recognizably is to make the DL not only the primary source of such material, but also the only source.
A second less well-known option for authors is to sign the “permission release” form, granting the ACM the right to publish the work, but without loosing the copyright to it. Authors keep the rights to their work while still having the paper published and archived in the DL. Then, the DL becomes one source of the paper, but not the only one. This option is typically made available only under special circumstances, for example, if you are working for the Canadian government.
Abstract: With the growing economic importance of open source, we need to improve our understanding of how open source software development processes work. The analysis of code contributions to open source projects is an important part of such research. In this paper we analyze the size of code contributions to more than 9,000 open source projects. We review the total distribution and distinguish three categories of code contributions using a size-based heuristic: single focused commits, aggregate team contributions, and repository refactorings. We find that both the overall distribution and the individual categories follow a power law. We also suggest that distinguishing these commit categories by size will benefit future analyses.
Reference: In Proceedings of the 42nd Hawaiian International Conference on System Sciences (HICSS-42). IEEE Press, 2009. Page 1-8.
Wikipedia is the free online encyclopedia that has taken the Internet by storm. It is written and administered solely by volunteers. How exactly did this come about and how does it work? Can it keep working? And maybe more importantly, can you transfer its practices to the workplace to achieve similar levels of dedication and quality of work? In this presentation I describe the structure, processes and governance of Wikipedia and discuss how some of its practices can be transferred to the corporate context.
This presentation represents the next step in the evolution of two Wikimania tutorials/workshops, see Presentations/Tutorials. If the slideshow doesn’t play, please use the PDF file download below.
Reference: Dirk Riehle. “Learning from Wikipedia: Open Collaboration within Corporations.” Invited talk at Talk the Future 2008. Krems, Austria: 2008.
Reference: Steven Fraser (editor). “Escaped from the Lab: Innovation Practices in Large Organizations.” In Companion of the 2008 Conference on Object Oriented Programming, Systems, Languages, and Applications (OOPSLA ’08). ACM Press, 2008: Pages 787-790.
Available as a PDF file; my part follows as HTML below.
Position statement for the OOPSLA 2008 Panel on Innovation Practices in Large Corporations
In most companies, the innovation process is organized as follows: A research unit suggests to build a prototype of some innovative product or feature, a line-of-business sponsor signs off on the project, the research unit develops the prototype, a product unit receives it and turns it into a real product.
The critical point is the transfer from research to product unit. Here, many things can go wrong, for example:
How we develop open source software can vary widely from project to project. However, the roles we play are similar across projects: user, developer, tester, documenter, committer, etc. For a while now, I have been interested in what open source means for software developer careers, in particular with respect to fame and fortune. The figure below illustrates some of this thinking:
This is a professional blog, so I usually leave humorous excursions into my life to my personal blog. Well, unless there is good reason for an exception. Today was such a day. That’s because today to much fanfare a new search service, improbably named CUIL was launched. A friend alerted me to the observation that searching CUIL for Dirk Riehle delivers (among other things) the following search result: