Open-Source Adoption Hurdles Are More Organizational Than Technical, Part 1

Linux / Open Source
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

Although adopting open-source technology usually involves developers learning a new language, several IBM i experts in open source point out that adding it to an enterprise’s solutions toolkit is more of a business-cultural change.

While the concept of open-source technology on the IBM i has been around for years now, as with many “new waves” in technology over the platform’s history, a large number of enterprises have been relatively slow to adopt it. According to HelpSystems’ 2019 IBM i Marketplace Survey Results report, a top concern at 50 percent of the participating survey sites was “application modernization,” and 71 percent of respondents report running more than half their core business apps on the i. Open source is a path to the modernization goal, but from the outside, the issues surrounding its adoption can appear daunting, even though many companies already use it in some form.

“Whether they’ve acknowledged it or not, the reality is that there are very few companies today that are running such isolated proprietary software that they wouldn’t be running something that’s open source,” says Pete Helgren, a Java software developer for Bible Study Fellowship International (BSF), an interdenominational Christian fellowship. Helgren cites IBM i interaction with Windows apps and Linux or UNIX use on the i (or on platforms that communicate with i systems) as existing examples of in-place open-source use—the use of which executives, at least, may not be fully aware. “Usually the reason that kind of gets set aside in a ‘maybe we should look at open source’ discussion is because folks don’t really understand what open source is all about.”

“None of those concerns, at least not in the top six or seven, are really specific to IBM i,” underscores Jesse Gorzinski, an IBM business architect specializing in open source, referring to some of the HelpSystems survey results. “They’re really just the top concerns in the IT industry: the need to keep applications up to date, the need to reduce IT spending, the need to ensure the security of their business data and their customers’ data. None of that is unique to IBM i, but still open source is a great way to address a lot of those problems.”

“It’s a state of mind,” notes 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. “I think it’s a cultural change to adopt open source,” Seiden explains. “Open source is basically about collaboration and sharing and having source code that we can all improve.”

That doesn’t seem to fit with the admittedly stereotypical—but still common—image of the smaller IBM i shop as a handful of programmers who have written nothing but RPG for years.

“Although RPG is very strong for developing business logic, it’s not optimal for creating web applications,” Seiden cites as an example. “So, many companies will create a web application using an open source tool like PHP, Python, or Node.js, and then call RPG programs for the existing valuable business logic. That’s very common.”

IBM’s Stake in Open Source on the i

When asked what IBM’s main strategic goals for embracing open source are on the i, Gorzinski jokes that there are “about 60” but singles out three top ones.

“For one, open source drastically expands the capabilities of the platform. That in turn changes the perception of the platform and gives clients the confidence to continue investing in IBM. Secondly, it attracts new skills to the platform. Third, open source provides a pretty simple bridge to even more interesting and useful technologies. So for instance, IBM i can now interface seamlessly with cloud-based machine learning, AI, and even quantum computing.”

Seiden cites the growth of SQL as another significant IBM motivator, which the HelpSystems survey identifies as the second-most common “application development language” on the i, after RPG.

“SQL is accessible from any language on the i, whether RPG, COBOL, or Node.js, Python, PHP, and others. I think SQL is a strategic tool on the i that serves all these other tools and technologies. IBM has even gone so far as to create a set of IBM i services that are SQL wrappers around traditional commands and program calls. As a result, open-source developers can take advantage of core IBM operational functionality with just SQL, which is easier than having to learn the specifics of system APIs. That’s been an important enabling technology, that IBM has made improvements to SQL to make life easier for open-source developers.

“I recommend using Rational Developer for i (RDi) when editing RPG,” Seiden adds, “because it makes RPG more comprehensible to the open-source person, helping teams collaborate. I was doing some coding recently and realized how essential RDi was in making RPG a very workable language. In fact, the open-source developer could become an excellent RPG developer with RDi.”

Helgren points out that another strategic value of open source is helping with the long-term problem of RPG programmers “aging out” of the platform as they retire.

“I think there’s a myth out there that RPG resources are a bit limited. The problem is just finding people that are willing to change. The opportunity is great on two fronts. One of them is if you have a company that has a vision about leveraging stability and the flexibility of an IBM i, it has the opportunity to start bringing in Angular programmers and Node.js programmers and folks who can replace the existing technology with a newer stack. It may be due to not being able to find RPG resources, but I think it’s more driven by the fact that there are great solutions that are living on other stacks than RPG.”

Gorzinski disagrees in part with that emphasis.

“IBM has delivered a great solution to this ‘aging out’ concern. It comes in two pieces. Those two pieces are our open-source stack and free-form RPG—and of course the modern tools around it. Customers who adopt those two things have an easy win here. Just imagine being an IBM i shop that has both open source and modern RPG as part of your solution set. Hiring developers is easy. Post a job for a JavaScript or PHP programmer on a public job site. The hardest part is actually going to be wading through the hundreds of applicants.”

The Business Case for Adopting Open Source

Opinions of the three observers interviewed here show that the reasons for adopting open source are myriad.

“What usually drives a company that direction is the need to bring up a needed component or feature that already exists out there and they don’t want to spend a lot of money and time inventing it,” Helgren notes. “The second one is actually pragmatic. It may be that they’re a company that develops software and sells that into the marketplace. These days, if you don’t have an open-source offering to start with, you may be left out of the selection process because you only have closed-source, proprietary solutions.”

“There is a wide array of benefits that we see with open source,” Gorzinski says. “There’s cost reduction. People can actually use open source to help secure some of their software. If you look at the top concerns for IBM i customers in the Help System marketplace research data, open source helps address most of those top concerns easily.”

Seiden points to technical advantages. “ ‘Open-source language’ has often covered packages and modules that have specific mathematical, statistical, or financial functions.” Seiden cites the R language as a means of helping enterprises cope with analyzing large data sets and displaying them graphically. “Until now companies have often extracted data from the i and analyzed it with R on other platforms such as Windows or SQL Server, and generated graphs there. R generates beautiful graphs with one or two commands. That makes it easy to analyze data. With R running on the IBM i as well, some of our clients are simplifying operations by bringing data back to the IBM i, creating a data warehouse in a spare IBM i partition, and analyzing it there using R. But now R runs on the IBM i as well, so it’s much quicker to create a data warehouse on the i as such.”

There are advantages for companies that use APIs.

“APIs are the rage for interoperability…APIs can include delivery trackers or sales tax calculators. RPG can achieve aims such as APIs, but some companies attract new talent by using open source. Often, APIs may provide sample code written in open-source languages such as Python,” Seiden says.

“In larger companies, particularly where developers work on the same code base in parallel,” Seiden says, “tools like the Git source-control system can help developers work separately and then merge their changes in. Most of the commercial change management tools support some level of integration with Git.”

Communication Issues with Adopting Open Source

While the expansion of available technology is a strength of IBM i, specialization of skills can create a sticking point in smooth adoption and use of open-source technologies.

“I’ve seen situations where let’s say there’s an RPG team and a PHP team, for example,” Seiden recalls. “The PHP team doesn’t have a background of working on the IBM i. The whole IBM i is a black box to them. When they’re ‘in the zone’ of developing, they don’t know how to do much more than query the database because they don’t know how to look at RPG code. If they’re calling RPG code and something goes wrong, then they point the finger at the RPG team because they have no way to look at RPG and understand it. The RPG team says, ‘No, no, it’s all on the open-source side, the PHP team.’ ”

Lacking a common vocabulary, the two teams can have trouble communicating. “The traditional programmer might say ‘fields’ while the more open programmer might say ‘columns,’ for example. Or ‘file’ versus ‘table.’ ” Seiden thinks cross-training and adopting a common vocabulary can be helpful.

“The RPG developer should at least be able to read and understand code that was written by the open-source developers,” Seiden suggests, “and the PHP developer should be able to at least read RPG.”

Helgren thinks this problem may be at least partly generational.

“What you do find is pockets of resistance to embracing newer technologies, which may or may not be open source,” he says. “There are plenty of what I would call very mature open-source projects that have been around forever that folks have not jumped into, not because the projects aren’t accessible or valuable, [but] because of their own reluctance to embrace a newer way of doing things. It can also be that the technologies in some cases can be radically different. In the case of RPG, which is not object-oriented at all, if you deal with somebody either in PHP or Java or many of the other open-source languages that are object-oriented, the concepts [can be] difficult to grasp. What it takes is, hopefully, a team orientation to solution-providing so that the guys that write RPG code can understand why and how the PHP components play in that environment and vice versa.”

Gorzinski is less worried about this particular issue.

“When you have companies doing large and important things, there are different teams, and you can have communication barriers there. Those types of scenarios are prevalent, in my opinion, throughout the industry, not just for IBM i folks. As long as the teams have a mutual respect for one another and the patience to understand each other’s needs, they’ll overcome those communication barriers. Above all, it’s not a technology problem. Good HR and management practices can help build a team synergy.”

Editor’s note: Read the second half of this article in an upcoming issue of MC Systems Insight.

 

 

BLOG COMMENTS POWERED BY DISQUS