An evolving relationship with open source
When I first started working with NGO’s and government agencies, I don’t think I fully realized how lucky I was to be at an organization building enterprise software, that was supportive at any level of open source. It wasn’t a perfect relationship by any means, but they could see the value in distributing the work load, getting more than one set of eyes on a problem and not needing to reinvent the wheel. However, when the code started to include a business process or a tool for doing their work better, they quickly became more concerned about competitive advantages or liability then building something with a community. I found that more than a little ironic, since most NGO’s and governments have community representation and build or rebuild communities as part of their core mission, but I could see their point for the most part.
Open source wasn’t, and maybe still isn’t, totally about community building, as much as it is about sharing, getting feedback (hopefully constructive) and making a new tool or an existing one better. The community is an afterthought in most cases, and sustaining and growing it comes well after that. Some of it is just in the way the rules and process have grown organically around open source, and some of it is maybe due to keeping parts of the control to ourselves, as developers, and only letting the “worthy” in to participate.
Maybe in some cases it’s okay to build in isolation and focus on your idea alone, I don’t know. But I do know that the projects I use the most tend to have inclusive and large communities built around them, as well as some minimal way for the maintainers and contributors to sustain themselves from it.
Why Open Source is important
There are a number of ways being open is important to some projects and people. To me, though, the biggest benefit I see is that the best ideas, the most transparent processes, tend to win out, and that almost always ends up driving the creation of the best tools.
A few years ago when I helped build a project management system for an NGO, I wasn’t thinking “how will this best benefit just this one NGO?” I was thinking “who else could benefit from this?” or “how can we standardize the industry around a tool or data format?” and “what can we learn from a huge user base using this for many different projects and share that information with each other?” I knew that open sourcing that project and getting other agencies involved was the best way to ensure it was sustainable. Beyond that though, I knew that Projects and Project Management are universal to almost every field, and it wasn’t a stretch to see that other companies in differing industries might be interested in seeing or adapting some of the practices NGO’s were refining in this tool. From years of globally distributed workforces, KPI management, and working in complex or challenging political environments NGO’s have to work harder and more efficiently then most for-profit companies or government agency and they end up with some unique takes on typical processes.
Building a community and getting consensus on tool and processes in these types of organisations is hard work though. Everyone has a slightly different variation on a process or naming convention and little time during a crisis to talk out the differences, meaning customisation would rule over standardisation. Without the funding for the project long term and the will to invest in it, the project would begin to slowly die in the organisation. It led us, though, to the kernel of an idea around a platform for building these types of tools. Reusable and scaleable, but with simple customisation options, but with a solid financial incentive for contributing, and a way to sustain it in the long run.
Sharing Economies
Open source, as it is defined now, is also to a certain extent about complete openness. There is some room for interpretation, but in the end, by the current accepted definition, transparency doesn’t matter unless anyone can take it and do almost whatever they want with it.
This is where we have tried to adjust the model and maybe definition a bit. We want to build a new category of license for future platforms that remove the limitations against selling or reselling a version of open source software by simply adding the requirement to share the compensation one would gain from using the work of others. It also will allow room for a type of Open that is more about the code and sharing and learning, while pushing innovation without removing the ability to resell and earn a living.
In the end this sort of a license structure will allow us all to benefit from making a product or tool better, but financially and in a way that doesn’t require a donation. In this process, we can build communities around these tools that can be sustained through financial and quality advancements. Yes, some of the old guidelines and rules need to still be in place for contribution, but in the end, the community will vote on what contribution is best by using the best tool.
Intellectual Property
New licenses and new models. You own what you build and you can share it, sell it and distribute it on our platform. It’s really as simple as that. You can decide to share it and get more developers involved, or you can keep all to yourself. What matters, though, is that it’s open. If I want to use it or connect to it, I can see the code, I can see how it was built, and I know how to interact with it if I want to combine it with something else. I can even help you debug it or enhance it if you want, or suggest a library that might be better or faster. Either way, it’s still open source, just with a slightly better model for you to make a living off of it.
We really see this as a way to keep the spirit of open source, both your personal and our maybe more general definition of it, with a license and IP model that is focused on building these sustainable communities and tools for enterprise software development. This way we reduce the dependency on large corporate organizations to fund open source projects, and then eventually control them, but rather independent developers or organizations who can work together to solve a problem and share it while still retaining a financial stake in their hard work.
What you have instead of a completely open and shareable project is a transparent and open code base along with a way to build together as a community, share credit where it is due and build financial and project sustainability. It’s not against the standard definition of open source but more of a subset that allows a new business model to evolve while keeping with the spirit of the original.
If you curious we have an open source project for our Angular front end framework with the license in it here: https://github.com/Humanitec/midgard-angular/blob/master/LICENSE
Yes it's based on the Affero GPL license which has some of it's own historical hangups but the adaptation we have made makes it fit our new Commerce Open Source definition. Take a look, keep an open mind and tell us what you think.
Top comments (0)