I was recently involved in a discussion where the topic of open source came up. The comment was made that open source has become quite ubiquitous in the world and the concept of open source was no longer novel or unique. In fact open source has become pretty much the “norm” or the standard by which technology projects are created. So with that base in mind, what does the open source of tomorrow look like?
Open source is the combined contributions of millions of independent volunteers. This single concept brings with it a few inherent realities. In this article let’s look at a few potentially concerning points about the nature of open source contributions.
Everyone is known for something. As much as you may wish that’s not the case at times. Similarly every business is known for something, be it a product, service, or character quality. What is your business brand and how does it affect what you’re known for?
It’s happened to me many times before. I’ve been stuck needing to unscrew the back off a toy to replace the batteries. I have no screwdriver handy so I begin to look for alternatives nearby. The result is mostly an extreme sense of frustration.
The buzzword of culture within a company is a frequently debated and often examined topic. A corporate culture establishes and shapes a company future. Does the same exist for open source communities? Does a culture exist and does it shape their future?
Open Source is valuable. Very few people would argue that point. There is most definitely a sense of intrinsic worth. But where does this value exist? Is it in the code produced or in something else?
I’m leading another talk on developing code using an open source framework. Only it’s going quite slow this time. In fact, I’m pausing after every sentence. And yet the room is far from silent and the excitement is quite high. What causes this excitement instead of frustration?
I guess I should clarify. This particular teaching opportunity is taking place in the great city of Sao Paulo, Brazil. And the reason I’m pausing after every sentence is to allow my translator the chance to repeat everything in their native Portuguese. It’s an intense experience. If you’ve never had the opportunity of sharing a highly technical topic with someone who understands only one out of every dozen words you speak then you are missing out on an experience. Now imagine there are a dozen other people sitting in the room also listening to you and trying to follow along. As I said, it’s an intense experience. But it is an unmatched feeling. Incredible might be a better word. And it makes me think about another power which open source possesses. Here’s a few lessons I draw from the unique opportunity of learning open source.
Learning is community centered
Sure, there are books and tutorials and videos, and a multitude of other resources available. In fact, there are schools and courses and an infinite number of ways to learn. However in open source you’ll often find the best learning is done within the community. People learning from people in a group setting.
The concept of group learning is unique in some sense to open source. We’re here because we want to be here. We’re not being paid to spend our weekend sitting in some classroom learning. We do this because we want to learn. And almost as much as we want to learn, we want to help others. That’s the other side of the coin. No matter how much I learn I always always find someone knows more. And someone else knows less. This means just as important as learning more is the idea of sharing knowledge with others based on what I know. Helping others. We’re a community of like-minded people focused on a particular set of values and shared interests. Our learning is centered on this.
Learning is personal
Even though we’ve discussed how learning is community centered learning is also very personal. People grow internally based on their experiences and they learn based on the instruction they are given. This learning causes them to change, and hopefully to improve.
When we are in an open source community we are often stretched outside our comfort zone. We don’t start that way, but over time we grow and the desire to learn more, or to be better forces us to timidly reach beyond our comfort zone and reach out to others. We’re driven by the deep down longing to learn more. As a result of this longing and learning we change who we are (to an extent). We improve ourselves. The very act of learning in an open source sharing community makes us a more well-rounded, and better person.
Learning is empowering
There’s something intrinsically powerful about knowledge. It’s a pretty commonly understood idea. “Knowledge is power.” But extrapolating on that notion leads back to the root that the very act of learning is empowering. By learning we are gaining knowledge and we are gaining power.
Open source is teeming with knowledge. When every line of code which makes up an application is made publicly available to be analyzed and poured over by anyone interested the result is empowering. Open source encourages learning and as such encourages the increase of knowledge and power. When you look at code and see what can be done and learn how to do things better you are empowered to do more. Now you can share that knowledge with others. Now you can become the teacher. Open source alone gives you the perfect environment – the opportunity to learn woven inseparably with the opportunity to teach.
Learning is exciting
I left one of my favorite lessons for last. Learning is most definitely exciting. I’m not referring to the type of learning you were doing in university with first year studies of ancient history (unless you enjoy that kind of thing). Instead I refer to the type of learning you find in an open source community. There’s a rush of excitement you can feel when you walk into a room on a weekend to meet with others in a community for the sake of learning. It’s very exciting.
As I wrap up my session in Brazil, the excitement is clearly evident. People talking over people, hands being raised, fingers flying on keyboards. Yes, this is what open source learning is all about. Watching someone understand the concept you’re teaching. The smile that spreads across their face when they successfully complete a task. The eyes glint with the newfound knowledge and the empowering, exciting, personal growth they’ve experienced. If you’ve never had the opportunity to experience this before. You should. Find a community and become a part. Get involved and see what learning in an open source environment is all about. I guarantee you – you’ll be changed forever.
I’m sitting at the airport. This quite a common place to find me. As an open source advocate I travel a lot. Most of the time my flights are on time and my connections are easy. This is not one of those times.
I found out my initial flight leg from RDU to IAD (Washington Dulles) was delayed and then 20 minutes later delayed again; and again. Eventually it was delayed 3 more times. And as expected with that many delays, I missed the connection from IAD to GRU (Sao Paulo, Brazil). Majorly frustrating. As I make the arrangements to rebook the flight for the following day it strikes me how applicable this situation is to life, and also to open source.
We all have plans for our lives. We have an agenda, things we want to see accomplished and goals we want to achieve. In an open source community we set our sights on accomplishing lofty things. Many of them having some form of “change the world” buried in them. We put down a mission and a vision statement we want to accomplish and then we start to organize ourselves to accomplish those goals.
Open Source Opportunities
Open source projects have several obstacles to overcome in this scenario though. Chiefly, we rely on the time, interests and energies of volunteers to accomplish these lofty goals and ultimately accomplish our mission and fulfill our vision. If our volunteers fail to have the time or interest then the project also fails. This is where the power of flexibility becomes so critically important.
It is foolish to believe a mission statement or a vision cannot change. It’s also foolish to believe every deadline will be met perfectly. When an open source community relies on volunteers and contributors one of the greatest battles is the battle to remain flexible, to be willing to make changes to deadlines, to goals, and even to a project’s mission.
Why must a community be flexible?
As I’ve already mentioned when a community relies on the goodwill and generous donations of time and talent from contributors there must be an inherent amount of understanding and ability to change as a result. Secondly, and possibly even more importantly, The world changes. Software changes, companies and organizations change. An open source community grows over time and as it grows it evolves. It establishes a culture and becomes more refined (dare I say focused) as it grows. At least this should be the case because the community listens to its members. Not only does it listen to its members to help it establish culture but it also listens to the world. A strong community pays attention to the changes happening around it and is flexible in adopting change (when it’s for the good of the community).
Are communities quick to be flexible?
No, and that’s why I say it’s a fight to be flexible. Sometimes individuals in the community are change-averse. They prefer the status quo over the ‘unknowns’ involved in changing. A well-rounded community is made up of a variety of individuals. These differences should be celebrated and embraced. These differences should also be kept in mind. Just as there are those ‘strong and steady’ types there are also the ‘non-comformist’ type, this is the person who loves change, any change, and even wants change just because it’s change. There’s dangers in both these types as well as the many other types (trust me, there are many many personalities which make up a good open source community). The point is to be flexible. Be talking and communicating with each other within your community. When communication happens (and listening happens) then the true power of open source communities can be found. Because I believe this is where open source stands head and shoulders over others.
Open Source Wins
Open source projects should stop looking at flexibility as something that must be fought but rather one of it’s greatest strengths. The ability to change direction based on the community is a powerful one. Most large corporations are unable to implement the types of flexibility and take advantage of a changing culture in the same way an open source community can. The passion found in volunteers cannot be bought, cannot be forced in a closed source corporation. It’s inherent in the genetic makeup of open source. Take advantage of the benefit of being open source. Take advantage of the flexibility and use it to be an incredible community.
Remember, we’re all in this together.
That awkward silence which fills a room when there is a lull in the conversation, or that moment when you realize you’re the only one talking, or the time when you respond to a chat message and there’s no reply. These are all common occurrences in life. But when is a quiet community a bad thing?
Too Much Talk
There is of course a time when talking is not enough. I’ve see firsthand those moments when everyone is talking and no one is listening. Sometimes a community is so busy debating with themselves over minor details that they forget to actually do something. Too much talk can be a bad thing.
Too much talk means a community is not focusing their time on doing things and making progress. This will kill a project, any project. In open source communities and especially open source communities, where the community is in charge of decision making, the discussions and debates over every minor decision can quickly lead to stagnation.
I think we can all agree too much talk can at times be a bad thing. So what about a quiet community? Is a quiet community equally bad for a project? Yes. A quiet community can be potentially a bad thing. Here’s 3 potential problems in a quiet community.
Silence is deadly
If a community is too quiet it will die. Outsiders judge a project’s viability and life by its communication channels, the chatter which takes place. Raise your hand if you’ve ever gone to a Github repository and viewed the last commit timestamp, followed closely by a glance at the open issues. You’re trying to judge the health of the project by its communications. Or if you check twitter to see the last messages posted with a specific hashtag or @ tweet.
Silence in a community is not golden when it comes to a community which makes group decisions and relies on the involvement of volunteers (open source) to accomplish things.
No man is an island
Secondly, if a community is quiet then volunteers will begin to feel as though they are “alone” in the project. This is incredibly discouraging. Everyone knows the feeling of writing something and waiting for the response. In real life you look for the facial expressions, the reactions of those you’re talking to. You use these verbal and non-verbal cues as encouragement for continuing or as a warning sign that you should sit down and shut up. Now take that same feeling and apply it to an online community. You post a message on a forum, on a social media channel, in an online chat, or on a mailing list. In this environment there is no opportunity to read non-verbal (or even verbal) cues. You rely on the responses.
If a community is silent then you have nothing to motivate you to continue and you will sit down and shut up. You’ll leave the community and find a new community where the participation is higher. As humans we need this interaction.
Apathy is quiet
This last point is a hard one to pin down. I’m not claiming that apathy is always silent, nor am I claiming the reverse, that a quiet community is apathetic. But often when there is apathy the result is a lack of input. If you find yourself not really caring or believing in something you can walk away, you can leave. But that involves effort. Sometimes you don’t feel like making that effort. You’re ok with doing nothing because you’re not interested, you don’t care. You’re apathetic.
If a community doesn’t care then it will not make decisions. It will not do anything. Which means something else will happen. It will stagnate. It will die.
Three potential concerns in an overly quiet community. As with everything in life, a balance is necessary. Open source communities should keep an eye on communications. If they see any of these three concerns becoming too prevalent then it’s time to do some soul-searching. Seek out the reason for the quietness. Has the community lost its drive? Its focus? Its vision? It’s possible a change is in order. Its possible action needs to be taken to help stimulate conversation. Perhaps its merely a lull, a welcome moment of calm in an otherwise noisy and thriving ecosystem. Excellent, make the most of it. Enjoy the stillness. But stay alert and be ready to make changes if needed.
In honor of Earth Day I figured I would write a quick post about how the U.S. Environmental Protection Agency uses open source software and technology.
I admit it’s not perhaps the greatest example of open source at work. But they’re making an effort and that’s worth mentioning. The EPA is taking advantage of open source networking through the use of a Github organization and series of repositories. They’ve boldly made the decision to place their website files in a repository to allow other developers to provide improvements and help. The sad news comes out when reviewing the number of pull requests made. In the nine months the code has lived out in the open there have been exactly 0 (zero) pull-requests.
Ok, so perhaps not the greatest example. There are other repositories in the EPA organization account. Unfortunately, the other repositories post many of the same statistics. Various repositories for projects, applications, and websites exist but none have any better stats.
What does this mean? Should open source be neglected and not used by these government agencies? Not necessarily. The problem is not in the intent but in the execution. I’m sure many of you know how the recent healthcare.gov site also attempted to use Github to share all of their codebase. https://www.healthcare.gov/developers
Healthcare.gov Github Failure
This was a fiasco for them during this process and after only a few weeks they removed the code. Why do these different government agencies fail? As I said before
The problem is not in the intent but in the way they carried out their plan.
Open source is not an easy, “instant” solution, and as I’ve written about before, many will fail at open source. These government agencies falsely assume the community is waiting for opportunity to contribute code and contribute fixes. While the world is full of altruistic, well-intentioned developers it cannot be assumed they are idly sitting waiting to offer perfect little code-presents bundled up with a bug-fix bow.
I’m glad to see the government eager to take advantage of open source. But it must be carefully thought-out and planned and be sure it’s not seen as just a chance to get free help from developers. Care should be taken to grow and nurture a community surrounding the organization. It takes time, it takes thought, and it takes planning. Yes, it can be done. And it can be done successfully. It’s a multiple step process.
The first step is to recognize the benefits of open source. This one is the easy step. Most companies and people recognize the power of open source. The EPA has recognized the power of open source. They’ve taken the first step and I commend them for it.
The second step is to organize a plan for how, where, and why to implement open source. What technologies, what software, and what platform should be used to share this code with the world? This step is a bit harder than the first step but again most can accomplish this step as well with very little effort.
The third step is the first step which takes much greater effort and attention. This is also the step when most companies begin to fail. Simply dumping the code onto an online repository such as Github or BitBucket is not enough. This is not implementation. Implementing involves more than the code release. Implementation means marketing, advertising, and clearly defining the benefits for the community to helping. This means showing the value of the open source code to the greater good. Giving the community a reason for participating and sharing how the project benefits more than just the organization.
The final step is the nurturing process. This is not the end of the process but this is the last of the steps in seeing it successfully begin to grow. Nurturing the community surrounding the code means spending time showing the value of the whole. Offering praise and feedback to those community members volunteering their time. Companies who fail to plan and implement clearly never spend the time to nurture these communities. Contributors must feel valued and see positive outcome from their involvement.
Again, I’m excited to see open source growing in government agencies and other organizations but it needs to be done well. Companies should pay attention to more then recognizing the value. Encourage others to plan, implement and nurture their open source communities and then we’ll truly see the power of open source.