Please, add all your notes, links and comments here so we can continue the great discussion.
This was a small but energetic discussion … many thanks to all GH.
Hosted by Steffen Evers, Bosch Software Innovations
Stephen Walli, Corbis Images
Mark Atwood, HP
Emma Irwin, Social Coding 4 Good
Filippa Malmegard, LEGO
Main discussion thread was suggestion that the transition is a valuable opportunity to refactor your software so it’s more modularized and more suited to the environment of the open development model. It is an underestimated challenge for developers who may feel exposed by the process, and unprepared for that.
Mark: In many cases the build process is the first thing that needs to be migrated.
Stephen: If you’re a developer downloading a new project from github or sourceforge, with risk of your time being wasted, you need clarity on expectations, delivery and process. Recommends OpenStack as model of ideal path.
NB - achieving reliable repeatable build to known state with test setup is hugely valuable to the originating company.
Really have to port build environment to open source.
Manrique: Spanish government has set standards for projects moving to open source. (see his comment further down this thread for links)
Steffen: What about documentation?
Mark: Should be Markdown or ReStructuredText deliverable.
Stephen: One of things I’ve seen lead to failure/problems is when “one true codebase” is owned only by internal developers and community is essentially dis-trusted (GH note: i.e. not given crown jewels). Better to reverse this by extracting from the community the “product” that you are willing to support with for-fee services/licensing. So lawyers need to be comfortable configuring the deal to support that flow, then engineers and business-model can follow.
e.g. Genivi (auto-industry collaborative project) has core project with multiple products derived from that … also fedora
Also noted that it turns out that almost every software product has licensing issues when they consider going to open source. There are code audit service companies that specialize in this field. What’s your legal risk? What’s risk to customer using your product?
Final ? (unanswered): Is there an open-source knowledge-base related to the process of becoming OS.
GENIVI should have some documentation on this but I can’t think exactly what or where it is. I’ll ask internally if there’s something we can share or create.
I’ve collected a lot of observations together in the following blog posts:
Patterns and Practices for Open Source Software Development
Collected Ideas on Open Source Software
I commented about some info from some EU funded research projects we (Bitergia) are working on:
- FLOSS Checklist: Open Source your project in 5 steps
- FLOSS Licensing (PDF)
- From MARKOS we will expect some tools for licensing analysis, but they are still alpha I think
Another good reference is OSS Watch:
As I’ve mention there is the “Reference National Centre for applying ICT based on Open Source” (CENATIC) which has published guidelines about going Open Source in the public adminsitrations, but it is only available in Spanish.
Many thanks for this and the other links Stephen … exactly what I needed!
Thanks Manrique … I’ve edited my first post to mention your comments here.
Sorry I missed it. One addition: be sure to include explicit documentation as to brand governance as you turn the code governance over to the community.
That is: who owns the trademarks? What are the expectations of strategic direction governance for the technology? Does the owning/originating company keep sole or controlling ownership of these, or are you actually giving this control to the community or a foundation?
- Shane “BRAND > code” Curcuru (just gave OSCON Ignite talk on that)
Posted my slides, although since it’s an Ignite presentation, I’m not sure how much sense they make without the talk. They note they’ll be posting video of Ignite talks in (a few weeks?).
The essence is:
- Think about the brand - the larger story your project tells to the world.
- As a geek, try to spend at least a little time thinking about what real-world thing your project solves (not just the cool code you wrote).
- Be aware of who owns and governs the brand of any project. It’s not always the same as who governs the code and the community.
For example, Apache/Eclipse own all their project trademarks on behalf of the projects, ensuring the brands will be kept independent. For many company-sponsored open community projects, the company welcomes a community to help govern the project. But the company itself controls the brand and the trademark. What happens when that company goes IPO or is bought out, for example by Oracle?
Not enough people are thinking through the importance of open source project brands yet.
I appreciate this is an older thread, but I recently (6 months ago) tackled this idea from a different perspective.
An in-depth guide to turning a product into a project
Thanks, This is an excellent summation. I particularly like the call-outs for considering community and customers separately and the fact that the value of the technology hasn’t changed, so the pricing can remain stable.
However, since we all know that open source isn’t free to a company, where would you see additional value return to justify the additional costs? Is it in your inertia statement?