Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [technology-pmc] Open Source Adapter for Closed Source Software

+1 on the “works with dependency” if that’s what the project team really wants to do, but a word of caution…

 

While it may seem attractive to include as many adapters as possible in the project, it will create logistical issues as external products the adapters are for have their own release cycles and you will not be able to release an updated version of the adapter without releasing the whole project. Per Eclipse Development Process, you can’t do a release on a single component, you have to do a release on the whole project. Once you’ve accumulated a lot of such adapters in the project, you are faced with the choice of either being late in updating adapters and stick with product development schedule that makes sense for the core project or be ready to do very frequent releases to align with various product launches and revisions.

 

For this reasons, many Eclipse projects are moving away from hosting adapters internally, even where these adapters are open source. In addition to GitHub, another alternative to consider is a sub-project under Lyo per adapter. That will allow the adapter to have its own release schedule and its own committer team, but you will have to go through the standard project creation process.

 

- Konstantin

 

 

From: technology-pmc-bounces@xxxxxxxxxxx [mailto:technology-pmc-bounces@xxxxxxxxxxx] On Behalf Of Steve K Speicher
Sent: Tuesday, July 08, 2014 6:50 AM
To: technology-pmc@xxxxxxxxxxx
Subject: [technology-pmc] Open Source Adapter for Closed Source Software

 

Dear Technology PMC,

I've included the thread below for context and reference.  To summarize:

A contributor wants to contribute an OSLC adapter for a close source product with has APIs that need to be called (MagicDraw http://www.nomagic.com/products/magicdraw.html).  This adapter is a Web application (a set of Servlets that are built and packaged into a WAR).
We are requesting a "works with dependency" since all other software components in the Lyo project's repository can work without this.

Note, this particular contributor has a number of these types of adapters and is looking to share them with the Eclipse Lyo community.  The company they represent considered other places to contribute (GitHub) but felt Eclipse Lyo was the right place and we believe it is too.  We just need the right 3rd party dependency understanding in place for these.

Thanks in advance,
Steve Speicher
IBM Rational Software
OSLC - Lifecycle integration inspired by the web ->
http://open-services.net
----- Forwarded by Steve K Speicher/Raleigh/IBM on 07/08/2014 09:39 AM -----

From:        "Sharon Corbett" <sharon.corbett@xxxxxxxxxxx>
To:        Steve K Speicher/Raleigh/IBM@IBMUS
Cc:        Samuel Padgett/Durham/IBM@IBMUS
Date:        07/07/2014 03:59 PM
Subject:        RE: Open Source Adapter for Closed Source Software





Hi Guys;  Apologies its been a crazy time and some much needed vacation was taken last week.
 
It appears you have been able to make a determination concerning the dependency type that applies.  As PMC has to provide their agreement, I'd suggest you go ahead and raise the request on the Technology PMC Mailing List.
 
Hopefully they will engage quickly in light of your timeline.

Sharon

 
 
From:        Samuel Padgett/Durham/IBM
To:        
"Sharon Corbett" <sharon.corbett@xxxxxxxxxxx>
Cc:        
Steve K Speicher/Raleigh/IBM@IBMUS
Date:        
06/30/2014 10:45 AM
Subject:        
RE: Open Source Adapter for Closed Source Software





Sharon,


The Lyo project as a whole and its libraries can be used without this dependency. The specific adapter being contributed cannot be used without the dependency. I'd probably call this a works with dependency since you can use Lyo without it and we're not redistributing it.


The project a whole has three parts:


(1) An SDK to help people develop OSLC implementations
(2) A testsuite to test implementations

(3) Sample and adapters that implement OSLC


Axel's contribution falls into bucket (3). (In fact, none of the Lyo release downloads to this point contain any samples or adapters from 3.)


--
Samuel Padgett | IBM Rational |
spadgett@xxxxxxxxxx
Eclipse Lyo: Enabling tool integration with OSLC


From:

"Sharon Corbett" <sharon.corbett@xxxxxxxxxxx>

To:

Samuel Padgett/Durham/IBM@IBMUS

Cc:

Steve K Speicher/Raleigh/IBM@IBMUS

Date:

06/26/2014 03:18 PM

Subject:

RE: Open Source Adapter for Closed Source Software


 






Greetings;

 
We will actually need you to help us understand which type of dependency actually applies here.  The Eclipse Third Party Dependency Policy [1] should help you make that determination.


With the type of dependency determined, we will be able to provide more input.


Thanks,
Sharon

 
[1]
https://www.eclipse.org/org/documents/Eclipse_Policy_and_Procedure_for_3rd_Party_Dependencies_Final.pdf
 
 
 
From:
Samuel Padgett [mailto:spadgett@xxxxxxxxxx]
Sent:
June-11-14 5:33 PM
To:
Sharon Corbett
Cc:
Steve K Speicher
Subject:
Open Source Adapter for Closed Source Software

 

Sharon,

We've received a contribution to the Eclipse Lyo project that is an open source adapter for a closed source product, MagicDraw:


http://www.nomagic.com/products/magicdraw.html

The adapter takes the MagicDraw data and exposes it using the OSLC standard. The adapter itself is entirely open source, but would need to make calls to the MagicDraw API and thus has a dependency on their libraries. We have no plans to redistribute the MagicDraw libraries, but would require that MagicDraw be installed on the user's system.

Is it possible to accept something like this in Lyo? Is this considered a workswith dependency?

--
Samuel Padgett | IBM Rational |
spadgett@xxxxxxxxxx
Eclipse Lyo: Enabling tool integration with OSLC


Back to the top