Skippy Records

A habit of skepticism teaches us to ask a lot of questions. Practice improves our ability to ask fertile questions. There is a knack to finding questions that lead to interesting answers.

Finding and weighing evidence is a novel, real-time affair. What is evidence? Who is the authority on certain kinds of evidence? How can one test evidence? How can we be sure about cause-and-effect chains holding up over time? 

There are many kinds of evidence:

• Authority
• Experience
• Logic/Reason
• Modeling
• Aesthetic
• Empirical
• …

Science gives as tools for apprehending many types evidence. 

Science teaches us that authorities are a fast and important way to get information (“don’t reinvent the wheel”), but they are not the only way.  Each of us can dream up how we think things are, devise a test of the implications of our assumptions and go out and get our hands dirty with an experiment.

Science shows us how authorities have reasons for asking questions the way they do; the form of these questions shapes the answers. 

Science gives us a body of useful knowledge, technology.

Science teaches us to frame questions at the practical limits of our body of knowledge and our ability to test the evidence.  Scientists don’t spend much professional time on questions where there is not background knowledge to build on (or overthrow) or any tools of empirical study.  “What does God think of me now?” isn’t going to get peer-reviewed grant funding any time soon. 

Science education for non-scientists teaches us to hear what scientists are saying.

And... 

You might argue that even given these benefits, science is still the domain of scientists and others need not be bothered.

“Democracy” renders this argument immature and naïve.  In a society where each of us is responsible for decision making, then each of us is responsible for intelligent decision making.  That requires that we reliably weigh evidence, balance claims of authority, make hypothesies and follow through on the supporting or contrary evidence.

Posted by DrSkippy27 at 11:52 AM | Permalink | Comments (0)

Posted by DrSkippy27 at 10:40 AM | Permalink | Comments (0)

I posted earlier about the Silicon Flatirons session on “Re-examining Open Source & Community Development.”  During that session, I took some notes on organizational practices that may help as a commercial software development teams contribute to Open Source software projects and build commercial products from Open Source software.

Below are five guidelines discussed at the session: 

Guideline 0. Record every use of Open Source as it occurs.  Print paper copies of license agreements.  Be sure to keep the copy of the license under which you started using the Open Source applications or components as licenses may change over time.

Guideline 1. Decide how and when your company will provide indemnity and warranty for Open Source software.  Evaluate the risks your are assuming as you may have little or no upstream indemnification or liability protection from the Open Sources licenses you have agreed to. Articulate this policy to your customers and users of your software.

Guideline 2. During a sale or major funding event for the company, the question about Open Source software use will come up.  Because there is no purchase record for Open Source software, you should assemble your documentation form engineering notebooks, filed Open Source license agreements (see Guideline 0) etc. as you prepare for due diligence.

Guideline 3. Your strategy for complying with Open Source licenses is to cooperate with the community as much as it is to figure out the exact meaning of each agreement and come into technical compliance.  As much as staying out of court, you are trying to stay off Slashdot (www.slashdot.org) or get the negative attention of the Free Software Foundation.

Guideline 4. If your company chooses to build a core product using community development and Open Source licensing, articulate your code ownership policy clearly to every contributing developer.  If you plan to retain ownership of the code, create the appropriate Ownership Assignment Agreement, have each developer sign it and keep them on file.

Posted by DrSkippy27 at 09:54 AM | Permalink | Comments (0)

This question was raised to the panel at the Silicon Flatirons seminar "Re-Examining Open Source and Community Development" on March 5, 2007. I think this is an interesting question and I thought it would be fun to try to answer this question for myself.

I think Open Source as a way to organize resources for development will be more broadly understood and more explicitly leveraged to solve problems like building software.

I am enthusiastic about building software because I see it as one of the most direct tools for extending and amplifying human intention.  It is an enabler of an increasing scope of desires for learning, analyzing, organizing, filtering, entertaining, communicating, and connecting.  As an intention-enabling tool software must continually adapt and evolve with the sophistication and sphere of focus of those doing the intending.

The most effective solutions to these problems evolve from cooperating groups of user-developers. This is one of the key differences between well-run, large-scale commercial software projects and Open Source projects--the users are the developers in the latter case, while the developers are hired professionals in the former.

This "user-" difference has many implications for the time it takes software functionality changes to drive innovative changes in the behavior of people using the software, which in turn results in ideas for new software functionality. And around it goes.

The "-developer" difference will become more significant than it is now.  Tools will improve in both power and ease of use, enabling non-nerds to develop intention-enablers (software) that only nerds could develop in the past.

I anticipate that intention enablers, including software, but also including modes of cooperation, spiritual practices, models of rapid value creation in conversations, etc. become much more powerful in the next 10 years. So do the tools and, therefore, so does Open Source development.  Of necessity, licensing of the intellectual property that supports the evolving modes of creation and patterns of use plays a larger role as well.

Posted by DrSkippy27 at 11:39 AM | Permalink | Comments (0)