In OSCEdays Berlin, we had 2 workshops with Veolia who were curious about the Open Source methodology and the potential to create very different projects and business models than they have had in the past.
Imagine Zero Rainwater Pollution
Imagine Zero Waste
@Justine asked @Lars2i and I for a summary of some of the business models which could be presented to their CEO to show the benefits of the open source approach. My short answer is 'build and share infrastructure with others, and sell unique services.'
For a more in-depth answer, both of us recommended the links Lars referred to in his first post in this topic:
I also want to add a few thoughts about the pros and cons of a large ‘traditional’ company like Veolia trying the open source approach. It’s a bit long, but Justine, feel free to edit as you like!
##Open Source for Veolia
Building or taking part in open source projects could reap sustainable, long-term benefits for large companies like Veolia. However, they need to be aware of the many differences with traditional product development and business models that exist in the open source world, and take the time to develop trust with their potential contributors and collaborators.
There are many financial and not-directly-financial benefits to an open source approach - for example:
-
Unexpected innovation: a diverse group of people who are encouraged to experiment, to solve their own problems and work with unlikely partners can produce a much wider range of developments, ideas and insights than one company could ever produce alone.
-
Lowered R&D costs: if multiple actors share common goals, or require a common tool to achieve different goals, the costs of developing the infrastructure of this common tool or solution can be shared amongst them. Normally activity would include a mixture of contributions to the core of the project, and also some specific customization for one’s own business or personal use case.
-
Ethical boost for the brand: If a company is working collaboratively with others, and sharing the benefits of a open source project, this will generally have a positive impact on the perception and reputation of that brand - especially if their project has a worthy goal (eg rainwater solutions/circular economy).
-
Adaptation to different/local markets: having a community of users and contributors in a variety of locations and situations means that projects are often adapted for local use, and are often designed for easy adaptation. Encouraging and keeping an eye on this process is a cheap, low-risk and effective way to test out different potential markets and use cases.
-
Enabling otherwise impossible collaboration: Imagine if Veolia reached out to a diverse group of sustainability activists, creative hackers and artists, local neighbourhood groups, small businesses, and their direct corporate competition, and asked everyone to work together on a project for Veolia’s exclusive benefit.
Insanity, right?
There are clear limits to whom Veolia can work with on a ‘©Veolia, All Rights Reserved’ project. Even when partnerships do occur between large corporate players, it requires careful diplomacy and complicated contracts to ensure effective collaboration.
Open Source simplifies the transaction - an open license can work as a social contract, and creates a neutral ‘safe space’ with clear, standardised rules. It gives everyone access, and allows unusual collaborations to occur by ensuring that anything developed remains available to anyone, anywhere, to study, use, modify or sell.
In general, Open Source projects require a comparatively low financial investment compared to many other areas of R&D. However, there are many caveats to the above statements.
The first is that open source is not magic. There are many reasons and motivations for people to contribute to open source projects, whether that be personal development, status, money, social aspects, altruism, political purposes… it’s important that anybody wanting to steward an open source community takes the time to understand these motivations, and works with the community to slowly build trust and understanding.
For a collaborative open source project to survive - and to thrive - those coordinating it must keep contributors’ motivations in mind. They must design and guide the project so that motivations are met, contributions are valued, new potential contributors are welcomed, and development is as smooth and effective as possible. There are best practises to help achieve this, but each community is different, and there is an element of trial and error. Careful listening and engagement with the community, and the development of trust is key.
Although open source development has a relatively low financial cost, it takes time and effort to learn and get used to this working method.
Even if a project is well-designed, well-explained and well set-up for contributions, it still needs another key aspect to get people involved: it has to be more than just an idea - you need a proof of concept, a working prototype, or a useful resource to build upon. This emphasises that the project is real, there’s momentum, and there’s a committed, capable team behind it, who have already made the project’s first contribution to the commons. The first interaction should not be to ask for help, but rather a no-strings-attached offer of something useful, as a way to build trust and start a conversation:
“Here’s something I made. You can have it. Is it useful? How do you think I can improve it?”
The ethical boost can only work if it’s honest. You can’t hide anything in an open source project - it’s very difficult, and extremely risky, to say one thing and do another in the field of open source - because the evidence, the truth, is right there for anyone to see in the ‘source code’, the license, and the communication with the community. If you alienate your community of contributors through malpractice or dishonesty, the project loses its reputation, its developers, its marketers, its customers and its business partners. Of course, you may make honest mistakes - but those mistakes should always be acknowledged and learnt from in order to maintain the relationship with a project’s community.
An open license can create a safe space, but it requires that potential collaborators have an understanding of how open source works. They also need to understand the motivations and direction of the person, people or company guiding the project. In software development, most people understand how open source works, so you just need to say “it’s open source, under this open source license” and people understand what they can do with it. The groundwork is laid for collaboration.
But in areas without so much open source development or open source history, convincing people is going to be more difficult, or take more time. This is especially crucial if the central role is played by Veolia, a company with no track-record in open source and one whose motivations may be viewed with a fair amount of scepticism by many people.
In one conversation during the workshop, I talked with someone from a small company who worked in resource management - they were wary of collaborating with Veolia on a shared project because they felt that their small independent company could never compete with a giant like Veolia.
But in this case it’s important to emphasise that you can share infrastructure without competing on business models.
Using their logic, I might look at Google, IBM or Samsung’s investment in (and use of) the Linux kernel and think "Well, I’m not going to contribute to Linux because it will just help the big guys, and they will crush my business."
But in reality, my small independent business probably has a very different business model to Google. Yes, if I as a tiny company try to compete directly with Android, I will indeed be crushed. But there are a huge number of smaller-scale, flexible and local solutions that also make use of Linux - you can build a fridge, a film camera, a spacecraft, or thousands of other IoT devices using Linux, and you’re not going to be competing directly with Google.
If you think of it in terms of our natural ecosystem, and the way that different organisms have evolved to find their niche, you’ll remember that Darwin’s phrase was not “survival of the biggest, the strongest, or those with the sharpest teeth” but “survival of the fittest” - those who best fit their environment, and who can carve out their own particular role amongst the other organisms, no matter who big or strong they may be. Or, to put it another way, an independent taxi driver and a multinational truck company both use the same road, but they don’t necessarily ‘compete’.
SUMMARY
Taking part in or leading an open source project can be an worthwhile and valuable endeavour for a company like Veolia - particularly as open source and online collaboration is rapidly growing and moving into new areas. There are also particular areas and problems which are best served by an open source approach - the rainwater issue is one of them.
However, I would recommend taking the time to build relationships, build trust, and understand the open source methodology and community before launching your own project.
Supporting an existing open source project, aligned with your interests and goals, can be a relatively low-cost, low-risk endeavour with the potential for opening up whole new fields, ideas and partnerships. This can be with time, with money, connections or other resources (preferably all of the above). Another approach would be finding and supporting people experienced with open source, who might be interested in helping you develop a project.
This is likely to be gradual process rather than an overnight success - but on the other hand, a large company has the resources and business experience to make rapid changes, so it remains to be seen.
Through engagement with the existing open source community, through listening, learning and gaining experience in this way of doing things, large, traditional companies can develop effective open source projects. To do so they must be transparent and communicate clearly, they must back up words with actions, and they must keep the needs and motivations of the project’s community in mind.
