July 7, 2016
I got my first taste of Open Source Software (OSS) earlier this year while I was working on our BlueOak team. Tasked with putting together a Cordova POC for Google Authentication, I gravitated towards a plugin by Eddy Verbruggen entitled “cordova-plugin-googleplus.” Using this plugin allowed us to execute native Google authentication from our hybrid application. It was exactly what we needed. However, it wasn’t perfect. There had been updates to Google’s Identity platform that had yet to make it into this plugin. I found myself at a crossroads.
The road to the left was a full, eight-lane super highway. On that road, I would be comfortable, but I would have to wait for Mr. Verbruggen to update the plugin.
The road to the right was a rocky, off-road adventure. It wouldn’t be smooth, but I could get the results we needed quicker. On this road, I would make the changes myself and push them back to the community.
I chose the road to the right. I updated the plugin to the latest Identity platform, made some other changes to refine usage and scope of the tool, then pushed it back to the community. For the most part, my changes were well received, but every project is different.
Open Source Software speeds up development time and gives developers an advantage but to continue to make it successful, it requires these three elements:
#1: Contribution from Developers
In discussions about my contributions to Eddy’s plugin, I’ve found that I don’t know the answer to every question people have. As a result, I’ve learned to point developers towards the documentation and encourage them to try to find the issue and share it back with the community. That technique has helped others figure out solutions and has helped me learn even more about the nuances of the technologies I’m working with.
For this reason, I believe that no developer or company will find success with Open Source software if they don’t learn to have a DIY mindset. Think about this:
One of the most common licenses attached to OS projects is the MIT license. It states that the software in question is provided “as is.” That means no support and no formal expectations of quality. If you read between the lines, this also means that this software might not do exactly what you need it to.
Let’s set the scene. Your team has incorporated a new Open Source resource into the project. In testing, you discover a bug in that resource that could block you from a successful release. What do you do? You fix it! You figure it out so you can get your product out the door. Now, consider this: Couldn’t the bug that you fixed be beneficial to the OSS community?
The answer is, absolutely. Contribution to Open Source software is the most effective technique for improving it. In fact, it’s the only technique.
#2: Collaboration in Open Source
One of the most important things any programmer will ever learn is the concept of DRY Coding. Don’t Repeat Yourself. In practice, this means it’s better to write a method or function once and use it multiple times then to rewrite the same logic every time you need it.
For the Open Source community, I believe that we can translate DRY into Don’t Reinvent the Wheel (DReW?).
Consider PointSource’s BlueOak Server: Why did we make that Open Source?
First, we recognized a need: Developers could benefit from a server scaffolding system. With a framework for a node, express and swagger server we could enable developers by streamlining project start up, allowing them to get to the work that really matters.
Second, we used it ourselves. I think this is a very important part of the process. We didn’t just create something and push it out. We created something that is useful for our own teams first.
Then, when we saw the immediate benefit of our own work, we pushed it out to the community and said, “Hey, we’ve made this version of the wheel. Feel free to use it on your car if you need to!”
Through BlueOak Server, we have been able to collaborate with developers and help push them towards meeting their goals.
The process of recognizing a need, finding a solution and contributing it to the community is the backbone of modern Open Source. Here at PointSource, we believe that the first step, finding the need, can only be achieved through communication. It is imperative that companies, teams and individual developers communicate their needs and desires to one another in some way shape or form. It could be by word of mouth, attending conferences, Q&As or even through a blog.
It’s also important to remember that effective communication requires a response. A response can take many forms – acknowledgment, investigation, action – but at the very heart of the response needs to be this question: If one developer has brought this forward, how many others are in the same position? When you start to think like that you begin to see just how big of an impact your contributions to open source could be.
According to the 2016 Survey of Open Source Software, 65% of companies are contributing to the Open Source community and 65% say that OSS speeds up development. 59% of those interviewed said that they are active in Open Source to “gain a competitive edge.”
I believe that we can continue to drive these numbers up if we remember the three Cs of Open Source:
- Contribute your solutions, but don’t reinvent the wheel.
- Collaborate with and enable developers from around the world.
- Communicate your needs and be open to communications you receive back.
Let’s go invent the future.