Plant your code and let it grow
"I believe that you have a responsibility as the creator of a project to spend as much time on [an open source project] as if it was still part of your internal organization," Perisic tells me. It's also critical to release the right kind of code. "One big reason why some projects don't develop strong communities comes from standalone projects that exist in a silo." The code might make sense in isolation within your company, but if it isn't obviously useful outside your company, it's likely to fail.
Sometimes, however, it's better to leverage the energies and organization of an existing project, even if it doesn't come with the same level of public credit. "Standalone open source projects are great, but if it makes sense to put a project under the Apache umbrella, don't hesitate. If there's existing community of developers eager to use it, don't hesitate to make it open source."
What about those times when code outlives its usefulness at LinkedIn? Given what Perisic says about the need to be a good open source citizen, how does he handle code that "the community" wants but LinkedIn no longer needs?
"You can't just abandon a project," he stresses, "But you should instead present users with alternatives and a migration path." For example, LinkedIn discontinued an open source project called Camus that was used as its pipeline to pull data from Kafka into HDFS. Rather than simply abandoning the project, Perisic and team went the extra step to ensure that they provided a migration path so that Camus users could easily adopt Gobblin, LinkedIn's new data induction framework.
All of this requires "significant time to develop, monitor, and nurture," but Perisic doesn't mind. As he concludes, the open source community "often pays you back this investment many times over."
Sign up for CIO Asia eNewsletters.