Managing open source integration [closed]

Closed. This question is opinion-based. It is not currently accepting answers. 开发者_JAVA百科

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 7 years ago.

Improve this question

How does everyone manage open source integrations in their workplace? For example, changes are made, some specific to your workplace's needs, to an open source project and then incorporated into the main codeline, likely via a jar. How best to integrate a new version of the open source project applying all local changes seamlessly (with minimal headache)? SVN has the Vendor branches concept/practice, but what if the source control systems are disparate?

---

Open source projects love contributions. When you make enhancements to open source software, do it in a general-purpose, not disruptive way. Get your developers to engage the community that supports the software and contribute these changes to the project.

Let's say you're on version 1.1.2 with custom features a, b, and c. If you follow this advice, when the project releases version 1.2.0 you can adopt it as-is, since features a, b, and c are included in the main distribution.

Open source projects that succeed and thrive use this model. Projects that don't receive contributions this way often don't survive at all. Therefor your incentive to contribute is 2-fold:

• If you do contribute, your version migrations will be much less painful
• If you don't contribute, the project may fold and you'll be forced to sink your resources into adopting something else

---

You have several tiers of quality assurance for this kind of thing.

1. Open Source Qualification.

   You have to test OS components to be sure they actually work. Mostly, this involves running tests supplied with the component.

   However, you may require specific features, or API's or whatever. You must have a test which simply establishes that the component does what you expect it to do.

2. Development Integration Testing.

   Your developers who use open source components will do integration testing when they need specific new features from a new release.

   If the OS library was upgraded, you are not "obligated" to upgrade anything. After all, you're not paying for support. You have the source. There's no reason to "automatically" upgrade your copy of an OS component.

3. Production Integration Testing.

   When you upgrade an Open Source component, you must do integration testing with your application suite. If this works, and it goes into production, then all your developers must do the same upgrade. Across the board.

Configuration Management of this is pretty simple. The entire original distribution must be saved -- unmodified -- in your repository, and must be distributed -- unmodified -- as part of your application.

Each version of the Open Source distribution is separate. You will have to keep each version you're using. And you'll have to keep them separate so you can tell which is which.

/opt/some-package/some-package-1.1/
/opt/some-package/some-package-1.2/
etc.

Each developer should do the appropriate installation. Integration testers, similarly, should do the appropriate installation. Production, additionally, must do the installation of the OS package once things pass the integration test.

Yes, it puts a version of the package in multiple places.

Yes, you have to figure out how to be absolutely sure that a production upgrade leads directly to each developer also doing an upgrade. You need some kind of version number audit to be sure that each developer has the correct set of OS components.