Open Source Resource

Open Source thinking is the power behind Open Source Solutions.

But this “Open” kind of thinking involves stretching our perceptions and expanding our concepts of what Open Source is. (For sure, Open Source Thinking is “not what we think.” Open Source Thinking is what “We’all (we all) think.”

(Note: this is the first-person-plural version of the noted, Texan second-person-plural, “Y’ all.”)

Open Source thinking is possibility thinking, collaborative sharing, group wisdom, vision and success consciousness…”breakthrough” thinking at its best.

Mistaking a Product , or Byproduct for the Process

Some Open Source advocates mistake the product (software), or the byproduct (implementation project) as the target outcome. It is a mistake to think that the software that is developed by the community, is the product, or that the implementation of an Open Source Solution is a hardware/ software installation. In fact, the power of Open Source Solutions depends little on the product; but depends upon (and is powerfully driven by) the Open Source thinking process. Even the creation, development, testing and bug-fixing of the software development process relies on collaboration and “best practices” for a process that is never finished.

Open Source software projects are “works in progress” rather than a wrapped and finished, final packages.

Open Source Solutions for education must take this Open Thinking process one step further, and establish a collaborative dialog among equals (our end users, clients and stakeholders are equal participants with developers, technicians and other techies).

Open Source thinking recognizes that the educational stakeholder community has more wisdom, knowledge and insight than a single, talented individual…and Open Source thinking recognizes that communities of school district stakeholders raise this wisdom, knowledge and insight to a level of magnitude higher than the insight held by some isolated groups (for example techies, server operators, or software programmers).

Brainstorming: Thinking on Steroids

Brainstorming in a tool that makes Open Source Solutions powerful and relevant.

So, Open Source advocates need to approach Open Source projects by examining various slants and vantage points of our clients and end users. We need to keep the process in view (and avoid the seduction of advocating a product), no matter if that product is superior to the competition.

Just because a product is superior today does not mean that the product will be superior tomorrow, or even an hour from now. “Leapfrogging” is a label that is used by competitors to mean that one product surpasses the others, not in a step-by-step race, but with a leap forward.

What it takes for a Successful Educational Project

For Open Source projects to be successful in the education arena, our solutions and options must appeal to many constituencies besides the highly trained technical folks. So, our first goal is to increase the relevancy of Open Source Solutions to as wide a range of school district stakeholders as possible, especially teachers and students.

When our thinking is stretched to include the view and vantage points of our clients and end users; we come to understand that Open Source Solutions are teaching and learning projects. Our Open Source projects apply Open Source thinking and Open Source tools to the instruction process. Our teaching and learning projects are not software projects or hardware and infrastructure initiatives. The use of software always takes a back seat to instructional goals in the teaching and learning process.

Successful Open Source advocates come to see that Open Source thinking promotes and targets processes for change and reform, solutions based upon the dynamic interaction among clients and end users, the dynamic interplay among trainers and trainees, the dynamic interchange among curriculum specialists and professional development providers, and the dynamic interrelationship among technical support specialists and the rest of our clients.

Collaboration and a Real-World View: the Real Driving Force for Open Source Projects

The goal of any Open Source Solution in education is the improvement of instruction in areas where Open Source Solutions excel.

By considering, weighing and interacting with thoughts and ideas of our project stakeholders (our clients); we stretch our vision, we encounter a greater depth of feedback. We widen, deepen, broaden and strengthen our insight. Open Source advocates use this dynamic community-based feedback and this dynamic open discussion to problem-solve and to make decisions…crafting solutions and decisions that work in the real world…not just fantasy plans that seem to work on our project management statements of work, seem to work on scope of work documents, and seem to work on critical path project tracking tools.

Relevancy of Interests: Success of the Community

Most school district stakeholders don’t know that an Open Source Developers’ Community exists to serve them. And, most school distinct stakeholders hold vested interests in lots of things, but don’t have a need to become vested in a software development community.

So, it becomes the software development community’s responsibility, or the Open Source Solution after-market community’s responsibility to listen well and adapt.

The shortcomings and unmet promises of the technology integration movement should have proven, beyond debate, that “meeting teachers’ needs first” not “demands of what we can extract from teachers” is the path to educational project success.

This listening, paying attention and believing what stakeholders at all levels tell us is where Open Source advocates “make or break” an Open Source Solution project in our schools.

Open Source advocates either draw these stakeholders into the project, honor and prize their contributions and points of view, understand that these stakeholders have greater wisdom about teaching and learning (than server operators, software developers and hardware technicians). When it comes to the real-world of teaching and learning, when it comes to the real-world of delivering instruction and when it comes to the real-world of driving student outcome improvements… an Open Source project either reaches a substantial portion of its potential; or, fails outright. Open Source thinking and active listening make the difference.

Open Source advocates either target and solve our stakeholders’ greatest issues, concerns and pains; or fail to meet the promises of improved teaching and learning that is expected from the project.

The Open Source projects that get this right, that consider teachers, principals, curriculum specialists, and students as “indispensable project consultants;” are the projects that are successful.

The projects that ram Open Source Solutions through to adoption (by sales pitches, subterfuge and chain of command power plays) always fail to achieve their potential. Guaranteed!

Relevancy or Else: No Relevancy equals “Missing in Action” Project Success

Open Source Solutions must be relevant for our clients and end users.

But, software developers, computer technicians, and server operators cannot, should not, (and should be tickled with a cattle prod if they try) think that they know what teachers and students need unless, until and after they ask, listen, and ask again.

These technical professionals should have more sense than to believe that “operating systems and software equate to test-smart, project-based, engaged-learning, outcomes-focused lesson delivery, or meanful learning assignments.” The Open Source thinking process blares, flags, screams for a focus upon professional development, Service Level Agreement (SLA) support and measureable curriculum-based objectives for every project.

So, the first steps of an Open Source project are “asking teachers and students what the learning objectives are” and “brainstorming with teachers, students and other stakeholders.”

During the brainstorming and sharing process, all ideas are accepted and one idea may invoke a “piggy back’ response, or provoke an opposite idea, an antithetical response. One idea, both, or yet another idea may prove to be beneficial. It is difficult to judge which ideas will bear fruit; so, open discussion is encouraged and promoted.

Another component of brainstorming is allowing participants and learners to make mistakes. This is another Open Source strength…where the community steps up and shares the task of fixing what needs to be fixed. This strategy, when accompanied by a wide, deep and broad inquiry into ideas and possible solutions results in what some folks label as “breakthrough thinking.”

The best implementation of the Open Source philosophy means an open-minded approach to problem-solving and decision-making, a willingness to dialog with stakeholders of all backgrounds and a willingness to communicate with people with all levels of expertise. If only those in the highest echelons of expertise are encouraged to participate, how will Newbies (who by definition, make mistakes) acquire the skills to progress in their own knowledge?

Note: This is another of the myths surrounding the lackluster performance of the technology integration movement. The myth has it that teachers were afraid to venture from their “expert status role” and be seen to be making mistakes by students. While this myth is plausible, the reality is that students know that technology involves mistakes. That is why video game players get a “fist full of lives” when they play video games.

If there is only one “right answer” then the person or group that holds that card is king. That is “closed source” at its finest, but darkest hour. Open Source thinking understands that all together we are smarter than the brightest and best single one of us. This makes Open Source Solutions powerful.

And, weaving the discussion with the threads of many viewpoints (from many stakeholders) is Open Source thinking.

Vision and Success Consciousness

But, brainstorming is not the only component of Open Source thinking. Vision and Success Consciousness are even more important.

Vision is related to the clarity with which an Open Source project’s goals are sculpted and held to. And, success consciousness is the attitude and values of the of key players who develop the project.

The vision that the project’s originators and sponsors hold affects the outcome of a project. Unfortunately, you cannot know what is in the hearts and minds of any other principle member of the project, and this aspect of the project remains hidden.

The vision that key project originators and sponsors hold is difficult to know, and the level of success consciousness of these players is difficult to know. However, these are key crucial and key components for any project, especially Open Source projects.

The Open communication and the honoring of all stakeholders is an important aspect that reveals a sliver of success consciousness, but, it is still possible that manipulators, sales people, and power-focused chain of command people agree to the Open communication model because they know that the model propels success, rather than because they hold all stakeholders in esteem.

Unfortunately, even a clear vision can weaken as the project progresses, and other folks can be brought into the project before they develop a clear knowledge of the vision for the project.

Success consciousness is related to the belief systems held by key project originators and sponsors.

This is also difficult to know because our vision into the hearts and minds or others is obscured by the mist and fog in our own heart and mind. We must perceive what is in our own consciousness before we begin to sense what is in the hearts and minds of others.

Unfortunately, Open Source advocates tend to be technically oriented, rather than people oriented, and long years spent locked away in server rooms, long time-and-a-half days spent debugging computer code, and the hours of stresses from troubleshooting systems, and the perpetual “midnight oil burning” spent scrambling to keep up with the latest changes in technology shunt these folks away from communication and interaction with people. The upshot?

Make sure that a “people person” rather than a “techie” is in charge of the project.

Unfortunately, some school district leaders are politicians, people who say what they think that other people want to hear. Look for these folks because they are found in every stakeholder group.

But, these folks have no vision of their own except one built on the shifting sands of taking advantage of situations by reflecting what they believe are other people’s opinions. The upshot: we seldom find clarity of vision in any of these folks, so never place a politician in charge of a project. In fact, avoid placing a politician in any position of authority, responsibility or importance. These folks wreak havoc in any endeavor that they touch.

Note: Evidence of this dearth of vision in politicians abounds in the circus arena of government where clowns, ringmasters, jugglers, tight-rope artists, animal tamers and slight-of-hand performers entertain us with their antics.

So, what is the Open Source advocate to do to motivate a project towards success when such inportant factors as the vision and success consciousness of stakeholders remain hidden?

Here are some steps to consider:

• Make sure that an honest and ethical person is in charge of the project
• Make sure that the vision for the project is communicated to everyone that is involved

• Note: The Open Source thinking and the Open communication process serves to share the vision and serves to discover how the vision (and associate goals) will play out during its implementation
• The “buy-in” of project stakeholders and participants is really a “buy-in” for the vision for the project.

Maintain a positive attitude and a belief that the project will be successful

Hold to attitudes and beliefs (that the project will be successful) in a gentle, caring and friendly way

Trust that Open communication and a vision of success for the project will attract success-oriented folks and create discomfort for those people that would be detrimental to the project

• It is amazing how negative, project-albatross type folks respond to positive, success-oriented communication by self-rejection
• But do not be surprised if these folks become hostile, disgruntled, backbiting and insidious. Just hold gently to the positive vision for the project
• Avoid any “in kind” response to the negative people that orbit around the project
• Continue to respect these folks, continue to wish them well, and continue trusting the Open communication process and the Open Source thinking process

Picture success results for the project as “already happened”

• Also feel, believe and sense this success in a multi-modal, multi-sensory way
• Listen to self-talk and listen to the success-talk of others in your mind as though they are commenting on the success of the project
• Project your thoughts into the future and perceive how that success continues
• If any thoughts or images seem to be in discord, redo the vision of the project until all images and all steps of the creative imagination process come into harmony
• You will be amazed at how the right people, the right resources and the right information are attracted to the project

Trust that the negative people will add many benefits to the project by pointing out areas where the project vision is weak.

• Silently and honestly thank these people in your heart and mind because they benefit your project in ways that you may discover later, or in ways that you may never know
• Consider your project to be like a chick that hatches from an egg. The chick needs to struggle to exit the eggshell, and the chick even grows an attachment to its beak to assist in the exit process
• But, if we break the shell to assist the chick, we create a weak and sickly bird that never becomes healthy
• Somehow, the chick (like our projects) needs the struggle to become strong

Vision and success consciousness can “fall through the cracks” an take a back seat during the excitement and stress of an Open Source project. Be sure that this does occur during the implementation of your projects.

Note: Some Open Source proponents profess to be “Microsoft™ haters.” Do not trust these folks at any level of an Open Source project because it is not possible to hold a positive vision, to hold love and respect for teachers and children, and to hold a focused success consciousness in the same heart and mind that harbors hatred. The person who cannot embrace the polarity of opposites, who cannot find value and benefit because of preconceived disgust for other’s successes, and who cannot honestly enbrace alternatives that might be best practices for the project because of bias is one who stagnates Open Source thinking and is one who mires (and fogs) any project that they become involved with.

Collaborative Sharing

Collaborative sharing also is a creative process that is bigger, higher, wider, deeper than brainstorming. Brainstorming is a “wild ride” a stretching and a creating, a weaving of associations, and a kick off towards tangents and parallels. Brainstorming is like a skyrocket that launches fragments into colorful star bursts…delighting many but their glow is quickly extinguished.

But, collaborative sharing is the slow and steady, meticulous, often painful, building out of a vision.

Collaborative sharing is hammering out of dents, a smelting of ore and a purifying to rid the project of slag, an oiling of squeaky wheels, of giving all (read every) stakeholder groups their due.

Collaborative sharing is the process that a Dali Lama, a Mahatma Gandhi, a Mother Theresa would take to ensure that all people (stakeholders) receive respectful and caring treatment. No group is ignored, stomped on, ramrodded or forced to acquiesce to the “solution de jour.” Everyone is respected and consensus, rather than “who comes out on top” is the prize.

But, why would anyone want to give up winning, give up taking personal credit; and let group-think prevail?

Answer: They hold the best interests and wellbeing of our students and teachers in mind. Their vision is the “greater good of all students, teachers and stakeholders.”

Group Wisdom

Even if the Open Source advocate is brighter, smarter, more talented…more talented than all the rest of the stakeholders; pushing through a personal agenda is “short-sighted.”

The reason is that these projects depend on other people to carry them out, and that it takes other people to see the project through to completion.

The project depends upon the talents, skills, and knowledge of others; but the project also depends upon the attitudes, feelings, beliefs, values, insights, motivation and good will of others.

And in implementing an Open Source Solution in a school district, the attitudes, feelings, beliefs, values, insights, motivation and good will of stakeholders positioned along all levels of the chain of command are crucial.

But, teachers in particular hold the key to instruction because teachers are the stakeholders that deliver direct instruction. Other stakeholders may just need to be happy that their issues and concerns are addressed, but teachers must have the support, professional development (and anything else that it takes) to ensure the Open Source project’s success.

Paying attention when teachers talk is more than just being polite. Taking to heart what teachers are saying, and acting upon what they tell us is more than good sense. Listening, and listening between the lines. Understanding what teachers (and other stakeholders) said, understanding what teachers and other stakeholders meant to say, and understanding what teachers and other stakeholders would have said if they could, even what they wish that they had said…are part of the conversation that exists when Open Source advocates prize the wisdom of the group.

Giving and Receiving

Open Source advocates pride themselves in sharing, but, giving is the another side of the complex set of interactions that comprise giving.

Giving means more than sharing. If the begging bum panhandles a quarter, and you begrudge the quarter that you drop with disdain into his alcohol-perfumed hand, you have given next to nothing.

In the same way, if Open Source advocates hold attitudes of self-superiority, disdain, distrust, deception or a focus upon a project (without regard for the people involved in making that project a success); the project cannot reach its potential.

Attitude and value make all the difference because people are not boxes and wires, and even boxes and wires respond in a positive manner when we care for them.

Of course boxes can turn from speedy track stars to brain-dead malingerers in the space of three years; but people remain precious throughout the life cycle of the project.

And Open Source advocates must become aware of other negative thinking.

Take for example, that professed “hatred” for Microsoft™.

Of course, this attitude is unwise because holding hatred and a vision of success in awareness at the same time is incongruous. And, holding any attitude of bias, stilts and convolutes thinking.

Holding an attitude of hatred for Microsoft™ costs Open Source advocates the flexibility that they need, binds their thinking to a type of tunnel vision that excludes opportunities and increases the burden that they place on themselves and their end user clients by eliminating elegant solutions in favor of a kludge that takes the long way around to avoid the “Microsoft™ bully.”

Of course, what really happens is that bias leads the project through a struggle that could have been avoided if only a spirit of giving and receiving were present.

Praising our competitors and wishing our competitors only good is the attitude that leads to success. Begrudging success to any other, even a corporate entity, blocks that good from pouring itself upon our project.

Since hatred is “alien” to an accepting-of-all Universe, the obvious conclusion is that those who hate, hate a part of themselves; and they are just projecting that hatred of themselves outward toward (real or imagined) others.

Breakthrough Thinking

Breakthrough thinking is any change in thought, attitude, perception, planning or insight that leads us from “locked in our comfortable rut kind of results” to success.

What do we have to breakthrough, break out of, escape from?

We have to break out or escape from our belief that we know…

• What is best for our self
• What is best for others
• How things really are
• How things should really be
• The best way to do or perform anything
• What experience is like for others and what will help them do or perform better

One characteristic of breakthrough thinking is that the components are simple, not complex. Others often say, “Now why didn’t I think of that. It was right in front of us all along.”

Whether the breakthrough is creative associative, i.e., putting common things together in novel ways; or, creative dissociated, i.e., separating things that have always “gone together; the breakthrough idea just stands out as better.

We break through barriers, mostly barriers of thought and assumptions; but often barriers of habit, feeling, attitudes and conditioning.

But breakthrough thinking at its best in Open Source projects is thinking that accounts for the wants, needs, desires, fears and pains of multiple groups of stakeholders; and satisfies many or most of these issues with an elegant solution.

Everyone in each stakeholder group may not receive everything that they wanted or needed, but at least they are satisfied that their concerns were heard and every effort was made to accommodate their needs.

Participants, clients and end users who feel that their needs and issues were cared for in this way have real, vested buy-in; not the “lip-service, appear to be cooperative” buy-in that reveals its true characteristics at the most crucial, critical, “no turning back now, no escaping catastrophe” embarrassing, “egg-on-your-face” time.

Efficient Solutions

The collaborative solution may seem inefficient to the software coders who pride themselves on elegant, small footprint, efficient code.

But, the Open Source advocate has to be sure that the footprint that they leave is not one of their stomping on clients and end users by forcing (kicking and whining) compliance to the project.

There are all manner of “monkey wrenches” that disgruntled, unappreciated clients can toss into an Open Source project if they are forced, beguiled, or cajoled to participate in a project that they don’t like (or forced to comply with an authority that they don’t like).

Even worse than a project that failed to build buy-in, is a project that increases the pain that teachers and students feel and experience.

For example,…

• a technology integration project that requires teachers to stay after school (without compensation) to learn to operate software
• a technology integration project that increases the amount of work that teachers must perform (without increasing measurable student achievement), or
• a “Catch-22″ project that “everyone just knows will produce spectacular results”, but doesn’t, therefore the problem must be the teacher

all fail because teachers and students were not considered first.

The Technically Superior Solution

Open Source thinking skirts the problem of the “technically superior solution” because the technically superior solution is impractical in the real world. For example, stunning technology rollouts, without professional development, an educational (or business case) and stakeholder buy-in are “real-world impractical.” Prescribing technical solutions without exploring the feelings, fears, stresses, conflicting commitments, bureaucratic system inconsistencies and management incongruities is “real-world impractical.”

But, Open dialog is practical. Brainstorming is practical. Open sharing is practical. Success consciousness is practical. Breakthrough thinking is practical.

For example, teacher members of Open Source collaborative efforts would not want to be bothered with the intricacies about setting up Web servers, and minor distinctions between updates for various Linux distros would hold limited appeal to a campus principal or curriculum specialist. But members of each of these groups would be interested in the professional development issues, educational case justification for Open Source projects, and the logistics of managing student software take home components of an Open Source Solution package

The technically superior solution starts with teachers, students, principals, curriculum specialists; then matches the appropriate professional development, technical support, hardware, software and infrastructure to get the measurable increases in instructional delivery and measurable increases in student performance done.

And, sometimes the technically superior solution requires that the implementation process build on existing infrastructure and materials, use commercial resources with Open Source resources, or just not use Open Source Solutions because none measure up to the teaching and learning requirements that the project needs.

The technically superior solution focuses upon the process of arriving at superior results, and then brings only the highest quality processes and resources to bear on the solution.

Sometimes the “best solution package is Open Source, sometimes the best solution package is commercial, sometimes the best solution package is a combination, and sometimes no package will serve.

But, Open Source advocates need the integrity to explain which of these conditions apply to the project, and Open Source advocates need the professional and ethical integrity to steer clients and end users away from Open Source project if the Open Source components stand little chance of delivering on the project’s goals.

This is what technology integration advocates should have done before recommending so many initiatives that lacked measurable teaching and learning goals, and that lacked a direct relationship to measurable content area and subject matter achievement.