I bet your eclipse project is not open-source

You are not authorized to post comments.
Session Type: 
Standard [35 minutes]

The two main questions you should ask yourself when trying to determine whether an eclipse project is a good open-source citizen are:
- Is it transparent?
- How easy it is for external people to contribute?

The Eclipse Fondation has recently launched an ongoing effort to improve its processes and technologies, in order to lower the barrier for external contributions.
- project's meta-data now have a dedicated tooling easing their maintenance, increasing the project transparency
- the contribution process has been simplified
- the migration to git and the integration of gerrit remove part of the hindrance of new contributions for committers and newcomers altogether

But there are still a lot of issues to tackle:
- take your open-source project. If it is older than 6 months, you probably have parts of your documentation that does not reflect the recent changes you made. Hence any contributor in need of information about your architecture or technical choices could be misled, and will have a lot of trouble understanding your code and making a good contribution.
- take your dev guidelines. Even if you made the effort to write complete guidelines (target environment, code formatter, processes, good practices...), there is no tooling to check these constraints formally. In result, when reviewing code and even if tests succeeded on Gerrit, you'll have to make a long and painful manual review, that can lead you to endorse the bad role when having to explain to your contributors that they do not code like you want them to. Moreover, as these constraints are not expressed formally, you are never sure that you checked all of them. In result, contributors may be discouraged for future contributions.

Attend this talk to discover how can Mylyn Intent and Ariadne can be used to:
- detect when your documentation is not up-to-date so that contributors can find the information they are looking for
- formalize constraints and guidelines (target environments, constraints like "Any bugzilla issue should be associated to at least one Junit test", "Any feature displayed to the end-user should be presented inside the User Guide with a screenshot"...) so that contributors can be sure that they made everything that was required before sending their contribution.

Schedule info



Experience level: 

Re: misleading title

Actually that's a recent Eike Stepper post that gave us the idea for the title http://thegordian.blogspot.fr/2012/10/release-notes-and-api-evolution-re... .

The Open source initiative http://opensource.org/ cites transparency in their prime mission statement:
"Open source is a development method for software that harnesses the power of distributed peer review and transparency of process."

In that context, I though it was ok (and yes, controversial, that's the point :) ) to say that a project is not open-source if it's not transparent and does not allow easy contributions.

However, if you were expecting something else from the title, I will try to change it, the idea was not to mislead readers :)
Any suggestions are welcome!

The title seems a little misleading

I concept of automatically updated docs, formalized constraints and traceability from code to bugs to docs is an excellent idea. I also think that it's an important part of a well managed open source project. However, I don't think we can classify a project as "not open source" if they are failing in these areas (not open -- maybe, not transparent -- possibly, hard to contribute to -- absolutely).

I understand that the titled is meant to be controversial, but I was excepting something completely different.

Just my $0.02.

Copyright © 2013 The Eclipse Foundation. All Rights Reserved.