Issues surrounding enterprise adoption of open source must be carefully considered.

Part 1 of this two-part series reviewed challenges such as mindset, IBM's stake in open source, business reasons for adoption, and communications issues that could stand in the way. Part 2 explores myths about open source, tips for getting started, common pitfalls, and the impact of open source on application development.

In Part 1, we introduced three experts on open-source technology on the IBM i and asked them a number of questions about challenges to adopting open source on the platform. Interviewees consist of Pete Helgren, a Java software developer for Bible Study Fellowship International (BSF); Jesse Gorzinski, an IBM business architect specializing in open source; and Alan Seiden, principal at Seiden Group, a consulting company that helps IBM i users modernize apps, adopt open source, and resolve issues with its use.

There are several popular myths about open source that need to be debunked. The top one is poor security.

"At one point, there was this pushback from proprietary software developers that open source was inherently insecure. The answer to that is no," Helgren says. "It's no more nor less secure than any other solution, whether it's proprietary or not. The good news on open-source development is that you've got access to the source code, so if you've got concerns about a certain component, how it's communicating to the outside world, and what security it has around it, then you just have to dig into the code and take a look at it."

"People are already scared about open-source security because any security vulnerabilities are published and discussed, and the fixes are also discussed," Seiden notes. "People are aware of security with open source, but that also means there are more people taking a look at correcting any issues."

"If you look at some of the keystone open-source projects that are security-focused, projects like Open SSL or Name Service Switch, not only do you see huge investments through things like the Core Infrastructure Initiative, founded by the Linux Foundation, you see huge investment from other Fortune 500 companies," Gorzinski elaborates. "We've been kind of trained to think otherwise through pop culture and movies. If the other team knows your plans, then you're somehow exposed, and people transpose that to code."

The actual reality, Gorzinski says, is that "you see money behind things like Bug Bounties, where they actually pay people to find weaknesses and vulnerabilities in the code, and all these things together mean that the software is very secure. Another interesting thing to look at is who is first to adopt the latest security protocols and the latest cipher suites. You'll find that those are the open-source projects."

Another myth is that open source is too hard to learn.

"Some might fear that a new language has too large a learning curve; it's going to be expensive to get everybody trained up. The licensing is too complex," Gorzinski opines. "It's not stable enough, or it moves too quickly. Unfortunately, misperceptions can make it seem like the costs outweigh the benefits, but those are all myths. Open source is well worth the effort or we wouldn't be seeing the lion's share of Fortune 500 companies creating, adopting, or distributing open-source software."

A myth Gorzinski particularly wants to quash is that open-source code is somehow free of charge.

"You will want some oversight to make sure you're complying with open-source licenses, [and] you will need to build new skills, possibly in a variety of technologies," he highlights. "You're probably going to want a support contract in place. That being said, open source is certainly going to be very cost-competitive, but it's not free. Companies need to acknowledge this and plan accordingly. Adopt open source for the many benefits that it brings—cost-competitiveness, help with hiring, access to all kinds of new technologies and new capabilities."

Tips for Getting Started with Open Source

There are two tracks to getting started. The first is getting your feet wet as a developer unfamiliar with the technology. The second is the track if you're a business thinking about implementing open source as part of its solution set.

The path for developers is simpler, according to Seiden.

"I would start by asking what they wanted to do, what they'd like to do. Pick a use case, because speaking generically, it's like asking 'How do I start programming?' I think it's always good to start by challenging yourself with a 'proof of concept' or some kind of little project you'd like to accomplish.

"A developer could write some open source and post it," he says. "If an RPG programmer with more than a few years to go in their career doesn't learn open source, then some of the newer projects may go to another team. By at least being familiar with open source, the RPG developer who may run across it may be able to work on some interesting new projects."

Seiden suggests developers work with open source on their personal PCs, offline from company systems at first. That way, developers don't have to get permission to run something on their use case, environment; they can run it on a PC and gain experience first. "You'll find easy instructions online if you get started on your PC at home."

"The trend that I see is that more and more people are self-taught through the Internet," Gorzinski shares. "When I started programming Python as a new language, it's my own personal learning style but perhaps this is a common way to do it. I started running Python, so I googled 'show me a Python Hello World.' I found that, and I got it to run. Then I googled 'How can I interact with Twitter from Python?' and boom, I found a package that did it, and I found some code samples, and then I typed them up, tweaked them for what I wanted to do, and it was working. I just started googling all these things that I wanted to do, and in the process of doing that, I started learning the actual language of Python."

He concludes with the admonishment to not be shy. "If you run into questions, ask people. Join our open-source chat, follow some of our hashtags on Twitter. There's a group on LinkedIn, there are of course midrange mailing lists, there's all kinds of ways for you to connect with the community around you. So don't be shy. Don't think that it needs to be this solitary effort, because the help is around; just start asking people."

For businesses, the to-do list is a bit longer. Whether or not a business adopts open-source technology depends on a number of factors.

"It basically has to do with the business that they're in, the amount of technology they want to leverage, and how quickly they want to move," Helgren observes. Companies have to decide first "Are we going to be a consumer of open-source solutions or are we going to be a developer of open-source solutions? So that's also an issue of the company and what their reason for embracing open source is." He also warns that companies need a system to manage the complexities, particularly if multiple applications are talking to each other across multiple platforms.

"You need to do due diligence on the quality of the code that you're adopting," he adds. "You need to have some sort of process of vetting the code, examining the code, and making sure that what you're implementing is stable and secure. We've taken that for granted in the IBM i world. Then you have some additional work to do in terms of vetting what you're doing, which opens up an opportunity for basically inheriting somebody else's problems. But it can also speed your development. Trying to find a balance there is always a challenge. There also needs to be communication between the microservices that may be in the same single stack, although that's usually handled by a services bus of some kind."

"A company could be seeing new business requirements that are mostly addressed with open source," Gorzinski observes. "It could be working to grow their development team. Maybe they have modernization goals that involve web stuff, mobile, REST APIs, or microservices, and open source can help with any of those things."

Another issue is what tools to use to work with open source and whether or not to standardize the tools the developers at a given company should use.

"People don't always know which tools to use for their open source, which is understandable," Gorzinski says. "Even with something as basic as a file editor, you have dozens of choices. For example, at one point, SEU was the editor for RPG. That was it, end of story. So people didn't have to think about what tool to use. Then eventually IBM replaced SEU with Rational Developer for i, which is today the best tool. Now, open source for many of these tools brings many choices. 'We want everyone using the exact same tools,' some companies say, while others say, 'We want everybody to choose their own favorite.' Honestly, I don't know which of those approaches is better."

"One challenge people face is they find so many different resources when they're searching that they don't know what to trust," Seiden points out.

Another pitfall he mentions is that unless "you're used to working with code that resides on the IFS rather than in source members, it might be that developers will need to get used to a development workflow that is based on the IFS and uses some sort of source control technology, such as Git."

"Another thing that companies need to be aware of if they adopt open source is that you need to be very proactive about keeping the software up-to-date, to make sure you have the latest security fixes and features and so on," Gorzinski warns. "We have companies who are using open source now that say, 'Once a week we're evaluating whether there's a new release of say Python or Node.js or whatever it is they're using—do we need to install that? Do we need to put that on our development partitions? Do we need to roll that into production?'"

"Keep an eye on the versions because they sometimes are updated more quickly. Very quickly," Seiden echoes.

"Check the licenses if you're planning to resell" the software you create is Seiden's next piece of advice. "Every open-source package comes with a license file. For anyone planning to resell that component, there may be specific terms to take into account, such as sometimes a requirement to give back to the project."

"Recognize that what's at stake is the need to add other technologies to the mix that are open and cross-platform technologies too," Seiden adds.

The Culture of Open Source

Not only can open source have an impact on an enterprise's culture, it's having an effect on the culture of application development as a whole that needs to be recognized.

"The thing that we kind of take for granted and we don't put enough emphasis on, I think, is the community aspect of open source," Helgren says. "In this increasingly social-network-focused world where communication is all electronic, we start missing out on the human element of the way we go about interacting with each other. Rather than learners, we've become folks that just find answers, and so I think in general it's affected the quality of software development but it's just reality now."

On the other hand, Helgren thinks IBM does its share to overcome this problem.

"I don't know of any other place on the planet where a company, as big as IBM is, at which you can get to know as many people in the IBM ecosystem that develop not only the hardware but the software that you work on every day. I mean, I don't know anybody at Microsoft. I don't know anybody at Amazon Web Services, I don't know anybody in a lot of companies as well as I know the folks at IBM, because they make themselves available to the community."

"I think there are some key differences in how people find information," Gorzinski says. "Generally speaking, open-source users want example configuration files, code snippets, tangible things that can solve their problem quickly. They don't want to go read a three-inch reference manual, they don't want to consult a comprehensive resource, if you will, like Info Center. They expect a web search to give them relevant hits on social programming sites so you can think of stack overflow and the like. But it even gets more practical than that, because if you're an open-source programmer, you need to learn how to use an API that you've never used before. GitHub and other hosting platforms let you search the source code for millions of other projects. With that approach, you can quickly see other working examples in real applications."

"I think community is important," Seiden remarks. "Community is woven into the philosophy of open source. People would do well to even attend some local meet-ups if they have some, or online meet-ups, or conferences like the RPG and DB2 Summit Conference. IBM has a post on Bitbucket about how to get started. There's a midrange open-source list. There's a Ryver site."

Look First, Then Leap

Clearly, the decision to adopt open source, both for developers as individuals and for enterprises seeking a new path for software solutions, isn't trivial. For companies in particular, there are many aspects to consider: not just the if, but the why and the how of adoption. While we've touched on a number of issues here, the question clearly deserves more thought as week as some planning if you think your enterprise should take the plunge.

What seems clear is that open source on the IBM i platform is influencing a process of convergence with other platforms toward a future that looks more community-oriented than ever and less of a venue for the rugged individualist. Code reuse, once a shortcut for the developer to mirror functions from one personally written application to another, takes on a whole new meaning in the open-source environment. Why reinvent the wheel when you can simply borrow someone else's design and modify it? The nature of programming itself seems to be sliding toward a reorientation. The real question everyone has to answer is whether to participate and reap the benefits or to maintain the long tradition at some shops of the IBM i holding itself in a relative state of splendid isolation.

John Ghrist has been a journalist, programmer, and systems manager in the computer industry since 1982. He has covered the market for IBM i servers and their predecessor platforms for more than a quarter century and has attended more than 25 COMMON conferences. A former editor-in-chief with Defense Computing and a senior editor with SystemiNEWS, John has written and edited hundreds of articles and blogs for more than a dozen print and electronic publications. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..

Also Read

Node.js on IBM i: System Access and DB2 Database Access

Node.js on IBM i: Vexing Versions

Kisco U - Journaling Data Areas