Mickael Scherer (Mageia) presented “a Fork of a distribution: Mageia derived from Mandriva”
(He made an interesting relationship between Forks and Catholicism vs Protestantism as an historical reference)
Reason of fork => community vs entreprise
History of relationships:
- 2000: cooker: R&D opened from Mandrake/Mandriva and idea of foundation considered
- 2003/2004: resources sharing (compile cluster)
- 2005: email@example.com sharing problems met.
- 2006: Steering committee between employees and contributors.
- 2007: Foundation mentioned at RMLLs – firstname.lastname@example.org
- 2008: AUFML – Assoc of users.
- 2009: Assembly to followup on
- 2010: Mageia created to avoid Mandriva closure. Going further than a distro.
More open governance – Association created + contributors (not creating a company as unfair wrt Mandriva) – Model based on a Council + Board. Renewed by 1/3
Mickael then mentioned some issues:
- Pb1: Infrastructure: Not starting from nothing. Want to reuse and be at a high level from scratch.
Code reuse is easy. Bugs reused is more complex (Customized bugzilla under Mandriva control).
Hosting ? Gandi, Lost Oasis, Dedibox helped a lot.
- Pb2: Brand management: Audit of code to remove mandriva – manual, underestimated.
- Pb3: Comm: with original project. Even if angry vs some people, it’s better to avoid hostility. Split of identity (contributing to Mageia vs Mandriva) – Press contact is required for a distro
- Pb4: Community. Feedback was important – 1100 mails just the first week ! Managing the enthusiasm. => Split tasks – People want to change everything ! DO a planning. Avoid the Vaporware effect (as said by LWN that will need to review that)
- Pb5: Details management.
Logo: guidelines posted. Process to listen and need of transparency. Even if their choice is not chosen, they know why and get explanations. No blund choice.
Presentation made by Gael Blondelle. Works for Obeo (Obeo is Strategic member of Eclipse) – OPEES Project Lead
OPEES goal is Open Source for long life cycle projects.
It’s an Open Platform for thre Engineering of Embedded systems
Ensure the long term availability of FLOSS tools for Critical systems (life impact, very high costs).
Example: A300 Airbus life cycle: 35 Years. Support = 78 years
(1972 project started -2007 production stopped) – Support till 2050
On board software development for very long life cycle products.
Ericsson: Base station for mobile – General life cycle of 30/40 years (electro-mecanical telephony centrals created in 1920 and still used in 1980)
Will FLOSS bring success is not yet known. But what is known is that commercial SW failed (example: Verilog made Geode, then bought by Telelogic, then bought and killed by IBM) Not counting the change of support contracts, costs, …
Decision by Airbus and Aerospace Valley in 2004: Adopting FLOSS with Topcased
(UML modelers and code generation). Used since 2008 to write code in A350 (next generation).
In 2009 the main Topcased contributor was bought, and TopCased devs stopped there. But thanks to the FLOSS approach, other contributors were found to lead the project.
Problem: How to create a community ?
In a classical commercial world: 20% of requests from customers accepted, control in editors hands.
Industrial users have specific constraints. So creating a FLOSS community made of individuals, companies, VARs, vendors should allow to cover 80% of users needs in a generic fashion. The 20% remaining implemented as specific devs.
OPEES is coming from a traditional industrial world, not even a SW world. But they come to the FLOSS approach based on the 4 liberty of the GPL.
It also helps manage IP issues.
Open Code and Open Formats enable migration, interoperability, extensibility, and protect from vendors lock-in.
But FLOSS isn’t sufficient. There are needs for:
- Community management
- Ecosystem dev
- Very Long Time support (10+ years) – Virtualization is a possibility
- Need to have technology vendors oriented towards industrial users
OPEES mission is to ensure cross users company ecosystem (not one for Airbus, one for Thalès, …)
Governance near from Eclipse one. In Eclipse 1,5 years of maintenance. LTS support added (7/8 Years).
What adds OPEES: maturity assessment, industry oriented governance, labels, certification process enablement, Very Long Time SUpport
OPEES: ITEA research center 35 EMEA members – AdaCore, Obeo, Airbus, Inria, E///, CNES, EADS Astrium, Linagora, Atos, Thalès, + Universities
Have a legal entity to sustain the effort after 2012 (end of ITEA project).
Grow the community (transportation – rail, cars, energy – nuclear, …) made of researchers and employees, not individuals
Convergence of the FLOSS forges communities.
Re-dynamising SW forges (Minalogic and Systematic support)
Coordination by Bull + Orange Labs, Xerox, Inria.
Forge: collaborative platform for sw dev (born in 1999 with sf.net). Means both the service and the SW itself
Partners: Codendi (Xerox), FusionForge (ex GForge), Novaforge (Bull)
Problems to solve: Identity management (SSO + roles), interoperability (with other forges – avoids data locking – not the first concern), tracability of specs, continuous integration, use SCRUMM method, work station integration (Eclipse plugin addition)
Specificities of the forges:
- Codendi: Application Life cycle management (sf.net fork in 2001) GPLv2, 25000 users, 4000 projects, on http://www.codendi.org Fully opened 2 years ago => increased download numbers.
- NovaForge: TM of BULL. Based on lots of FLOSS bricks (SVN, Mantis, PHPBB, Hudson, ExoPLatform) AGPL. Focus on data project confidentiality (due to BULL work activities). Migration of OW2 ongoing. Bull business model is around services (internal tool open sourced)
- FusionForge: Fork os sf.net named GForge. Lack of evolutions around GForge after some years. Some french admins created FusionForge in 2009. Integration of extensions. More EMEA contributions (Germany), mediawiki integration, incr”easing # of commits.
Community of Xchanges: PlanetForge.org (Wiki, ML, planet, µ-blogs)
Organisation of forgers meetings ;-)
Mainly convergence between Codendi and FusionFOrge (common plugins, projects models). Problems to sync release cycles between company supported ones vs community based ones (evolution of projects vs customer needs).
OSLC-CM (Open Services for Life Cycle – Change Management): interoperability standard and ontology used for forges interoperability (coclico, trac, redmine)
OSLC + Eclipse/Mylyn for work station dev/forge integration
Exchanges with Qualipso and Helios. Contributions to ForgePlucker (based on E. Raymond rant originally, and now sustained by coclico) and Mailman.
Following these 3 presentations, I animated a round table to cover the topic of this track: 2011, year of the forks. We had various natures of speakers Rodrigue Le Gall from BonitaSoft and Julien Mathis from Merethis who where representing Open Source projects having a strong relationship with their respective company, Charles Schulz representing the Open Document Foundation, and Jean-Marc Fontaine for the AFUP, french association of PHP users, both of them representing direct communities.
We were able to cover various topics, from animation of communities, relationship of companies with the ommunity around the underlying projects, reason of forks, support from tools to maintain communities, brand management impact, the LibreOffice vs OpenOffice latest news, I found it very lively and interesting in content, and I hope visitors enjoyed it as I did.
Rest of the day was passed evoking Mageia evolutions, and discussing with various relationships that I can meet only once per year during this event. In particular I had a long chat with Guillaume Rousseau from Antelink, which is the firm behind Antepedia, database gathering more than 660 000 projects for reference. (too bad mine are not in it :-)) Among other things we discussed of governance, market needs, and I tried of course to convince him to open source his product in order to ease the integration in forges, and allow its easy adoption by large corporation who are the natural consumers of such a product, in the line of FOSSology. Of course, this is always more difficult for a young and starting company, especially on a niche market but some others already showed it was possible.