Published October 5, 2008
Tags: open source, research, science
Thanks to Matt Rhodes I became aware of the recent hype around social media’s impact on science. The numerous discussions cover topics like scientific blogging, copyright issues, and open source science, often referred to altogether as Science 2.0.
As this subject is very close to my heart – I’m pursuing research via this blog, even though I don’t have a formal affiliation with any of the scientific institutions – I’d like to delve deeper into what I consider as open source science. Continue reading ‘Open Source Science’
Published August 8, 2008
Tags: community, linux, open source
A report from LinuxWorld provides evidence of the growing value we already get from community driven projects:
At the LinuxWorld expo in San Francisco, analyst Jay Lyman of the 451 Group spoke about the potential for enterprise adoption of Ubuntu and the impact that community-driven Linux distributions will have on the market.
Companies are increasingly choosing free community-driven Linux distributions instead of commercial offerings with conventional support options.
By the way, the term ubuntu comes from the same South African tribe headed by Chief Jongintaba, which also shaped the character of Nelson Mandela. It stands for a quality of mutual responsibility and compassion.
Ben Collins-Sussman from Google’s Open Source Project Hosting project shares his view on why you should allow early collaboration on your project, even when it means releasing a low-quality product to the public:
Be transparent. Share your work constantly. Solicit feedback. Appreciate critiques. Let other people point out your mistakes. You are not your code. Do not be afraid of day-to-day failures — learn from them. (As they say at Google, “don’t run from failure — fail often, fail quickly, and learn.”) Cherish your history, both the successes and mistakes. All of these behaviors are the way to get better at programming. If you don’t follow them, you’re cheating your own personal development.
One of the key reasons for publishing your work in the early stages is to allow community to get acquainted with it and provide feedback. This is like LISTEN behavior, as opposed to TELL behavior, where you come to the community with a polished product and ask them to accept it. Bob mentions here the open source programming “anti-pattern” of code bombs:
That is, what do you do when somebody shows up to an open source project with a gigantic new feature that took months to write? Who has the time to review thousands of lines of code? What if there was a bad design decision made early in the process — does it even make sense to point it out? Dropping code-bombs on communities is rarely good for the project: the team is either forced to reject it outright, or accept it and deal with a giant opaque blob that is hard to understand, change, or maintain. It moves the project decidedly in one direction without much discussion or consensus.
I think this is a great piece of advice not only for programmers, but for any project in the social networking space. If you’re a blogger, write your posts without striving for completeness and allow readers to provide their feedback via comments.
A few days ago I got really excited when I found out a few old (2006) posts from Mitchell Baker, the Chairman of Mozilla Corporation, on leadership challenges in open source projects. Leading the distributed effort to create Firefox, Baker definitely has a word to say about leadership in online communities. Here are some tips I extracted from her posts and one interview featured in The McKinsey Quarterly.
- Make sure you create, publicize, and live by mission, values and goals. Mozilla project was all about open Internet and safe browsing, and people that identified themselves with this mission became the most valuable contributors to the project. Continue reading ‘4 Leadership Lessons from Mitchell Baker’
What are the key elements of successful open source projects that engage hundreds of people?
Imagine an almost ideal information model of human – every element (gene, particle, organ …) is described and its characteristics are stored in form of parameters. There are relationships defined between those elements, which can take parameters on their own. Furthermore, imagine a group of people who volunteer to be described by means of this model. They provide their genetic code, and allow for storing information of actual parameters recording the state of their body. Continue reading ‘Open Projects: Some Draft Ideas’