Open source. Inner source. How do the two compare? Do we recognize both the risks and the rewards? Open-source software, if not vetted properly, may pose certain security threats. Some smaller open-source projects, for instance, potentially do not do thorough security vetting, leaving code open to vulnerabilities.
Sometimes, when there are a lot of cooks in the kitchen, so to speak, as there are in open-source communities, there’s kind of an expectation that someone else is taking care of security. And in some cases, that’s not happening at all.
The concept of shared ownership can be really great, but just to play devil’s advocate, what if this shared responsibility is keeping us from really being diligent about security?
Since developers are often pulling code from a host of different libraries, they may not be aware that various components they’re building into their open-source products are risky.
This is just something we as an industry need to be aware of, and there’s actually a movement to pay open-source maintainers, which could encourage these people to keep open code both functional and secure. So, the need to focus on open source and security—and the security of the code itself is essential.
One way to lower the barrier of entry for web developers looking to build complex visualizations or software—and one key benefit of open sourcing—is inclusion.
In most situations, I like to advocate for data sharing, best practice sharing, code sharing, etc., because there’s huge potential for positive change in our society thanks to technology if we put our heads together.
The benefits of open sourcing are even influencing organizations that traditionally develop proprietary solutions. Simply, it’s a development methodology where your engineers and development team build your own proprietary software based on best practices from large-scale open-source developed projects.
On the other hand, inner sourcing reflects this, and maybe you’re already doing this at your company. Inner sourcing is the use of open-source software development best practices within an organization. Inner source is actually not a new term which Microsoft has introduced.
These best practices include open collaboration and open communication, essentially creating an open source-like culture within a company.
Big companies like Adobe, Walmart, PayPal, and many others have adopted the inner-source ethos, and it seems like Microsoft is ramping up its inner-sourcing strategies as well. In talking with developers many report the most successful are driven by members that have vision, speed, security, and form all of which are created through an inner source.
It should be noted that inner source has been around for many years and companies like Google, HP, IBM, SAP, and others have been involved. In fact, there is already an InnerSource Commons Community of about 70 members.
As for Microsoft, it is stepping up and putting job postings online that are making it pretty clear that it wants to focus more on inner source. And in November, a job listing for a program manager 2, invited applicants to help engineering teams within Microsoft use Github and adopt inner-source practices.
Similarly, a posting for a senior program manager made earlier this month is looking for someone to contribute to the company’s “inner-source initiative” to make inner source pervasive across the company.
Why is this interesting? Just like open source, inner sourcing has benefits, such as involving more people, adding transparency, and making code better … not to mention building it faster.
There’s also something to be said for creating an open culture in which employees are invited to take part in processes and decisions. Just imagine what’s possible.
Want to tweet about this article? Use hashtags #M2M #IoT #5G #AI #artificialintelligence #machinelearning #bigdata #digitaltransformation #cybersecurity #blockchain