Having spent a long time in the FLOSS world both in community and industry roles, I started to see a serious disconnect between the industry and community perspectives on FLOSS about 5 years ago. I mean a disconnect that went beyond philosophical and into the practical, and this is largely because is a rapidly expanding userbase and industry around FLOSS. Community participants in FLOSS have a different understanding and expectation of openness than people in industry, and this difference is unfortunately being used to undermine the core values that make FLOSS more than just another technology set. The issue is that for all the well meaning of the 4 freedoms of the FSF or the Open Source Definition of the OSI, people can simply take those licences and not subscribe to any of the other attributes of openness that are expected of a FLOSS project and still get the good name of being a FLOSS project.
Openness has been proven time and time again to be the way forward. We saw it with TCP/IP, with HTTP, and now with FLOSS projects like Apache. Openness provides a platform for innovation, collaboration, an open and competitive market, and a sustainable approach to a digital future. In the same vein, a more closed approach may in some cases also be appropriate. For instance some popular and successful FLOSS projects have relatively closed development models controlled by an individual or a single company. An understanding of the degree of openness in software helps people understand the implications of the software model and also the implications in using the software.
In the spirit of discovering the core principles of openness, Jeff and I spent some time working on a model to help explain openness in such a way that it couldn’t not be undermined. We came up with 5 Foundations of Open:
- Open Source – the conditions surrounding the project source code. Usually defined within the licence terms.
- Open Standards – the data, communication and other standards used within a project, for example, APIs, protocols, & documentation norms.
- Open Knowledge – the documentation, project information, decision making, communication archives and any other content related to the project.
- Open Governance – the structure of the organisation that defines who participates in a project and the terms of participation. Includes decision making, and any practical or policy limitations on participation.
- Open Marketplace – the ability for any organisation to build a business around a project. Includes practical, legal and technological limitations to building an open marketplace around the project.
As we can see, above is a far broader understanding of openness than is generally subscribed to. A project may decide to have a more closed approach to any of these 5 vectors, and sometimes for good reasons, however by looking at all software (not just FLOSS) using these vectors people will be able to have a good understanding of how open the software is and what that means for using it, developing on it, building a business around it and so on and so forth.
I’m currently building some metrics around this to help determine the openness of any software, and will announce here when it is done.
Edit: This is an idea Jeff and I have worked on for some time, so I can’t take all the credit 🙂 Thank you Jeff!
A summary of why each kind of openness is important would be useful 🙂
ps. your comments feed (or at least, the link to it at the bottom of the page) is borked.
Academia was where the grey bears like RMS learned about and used open standards, open knowledge, studying the source, building on ‘the shoulders of giants’ and about the need for proper attribution. the Gnu Manifesto and the GPL were the early basis for free software embodying what was learned in Academia . Open governence was developed out of the ideals of open knowledge and the democratic/merit-based ideals of many early projects. And the open marketplace was what RMS envisioned as the way for folks to earn a living in this software/information economy. And Eben fits in there too.
I believe that you are confusing FL/OSS (i.e. software) with the projects that surround it.
Freedom, of any sort, requires the ability of an individual to act with the consent/support of any organisation or group, hence the specific freedoms outlined in the Gnu Manifesto, the DFSG and the OSS definition. Personal freedom in the context of an individual project is, AFAICT, unworkable, so freedom in the context of software development requires:
(a) access to source code by developers (N.B. “preferred form” not just “input language for compiler”; obfuscated- and machine-generated- “source” doesn’t count)
and
(b) the right, and the technical means, for those developers who choose to do so, to create and share derivative works.
By focusing on institutional structures (project governance), rather than on individual freedom, and in particular by promoting the line that inclusive governance is more important than, or even as important as, the individual freedoms embodied in the source licensing arrangements, you risk doing a very serious disservice to the FL/OSS community.
For concrete examples, consider SugerCRM, EGCS, QPL, GNOME and MPL.
– For the sake of argument, assume for the moment that SugarCRM’s governance arrangements are to your liking (I actually assume that they are not, but they provide a useful starting point for a thought experiment). That being the case, then the fact that they are using trademark law to interdict forking should not present a problem, right?
– Maybe I’ve not made my point strongly enough and you actually think that it would be OK for a project with acceptable governance arrangements to forcibly prevent forking. What then do you make of EGCS/GCC-2.95? This example is particularly important in that not only does it demonstrate the point, but given that it is GCC there is also an unequivocal win here for the entire FL/OSS community. Had forking (individual freedom, licensing arrangements, the ability for developer[s] to create and publish a fork not merely without the support of the project, but against its strong opposition) not been possible, EGCS would never have gotten off the ground, and GCC would still be a second-rate compiler. That this fork was possible, even against the GCC project’s opposition, made this possible.
– You may, or may not, recall the acrimonious arguments about early versions the QPL and its careful prevention of forking; the FAQ going so far as to claim that “everybody knows that forking is bad” in justifying this. Eventually common sense prevalled; the ability to fork (and the individual freedom that it entails) was recognised and the license was fixed.
– Interestingly, had QT’s developers gotten this dilemma the right way around the first time (individual freedom via licensing arrangements is vastly more important than institutional arrangements), GNOME would never have gotten off the ground…
– Finally, the MPL was seen as a way to get good stuff into the project, but prevent others from taking control. Again, after some time passed, the freedom of individuals to act independently of the established “project” was recognised and the proposal (mine, in fact) that Mozilla be multiple-licensed was finally implemented.
I’ve focused a little too closely on forking, but consider it a placeholder for a broader problem. The moment that you raise any other value to the same priority as freedom to work independently on source code, you risk reverting to ESR’s cathedral.
– A body of source for which this freedom does not exist cannot meaningfully be considered FL/OSS, regardless of the presence of the other interesting attributes that you mention.
– For a body of source for which this freedom does exist, the other attributes are an aside; their absence certainly doesn’t warrant putting it down as less than FL/OSS, or a lesser form of FL/OSS.
Thanks for the interesting comments.
Roland, I want to briefly touch upon yours. You are in violent agreement with exactly why we built these foundations 🙂 I know of all the cases you used above, and all of these demonstrate exactly why we need to be understanding freedom beyond a licence. RMS built a great base for freedom, a base that encouraged useful behaviours that promoted openness and freedom. The problem is that people who are not participating in the spirit of freedom and openness are able to comply to the letter of a licence (GPL, MPL, whatever) and yet be very closed in their way of doing things by closing the development model, basing the project on proprietary standards they own, using things like trademarks to close the opportunities to do business and having little to no documentation about the project to close the opportunity to learn about/from the project.
To break it down further, if a company wanted to be closed in their approach, for whatever reason, and yet wanted the good will of being seen to be a “FLOSS project” they could simply take some of their software, put it under the GPL and advertise as such. Then they could easily make the source code available in a useless format that requires a proprietary compiler (and only make it available to customers, not freely downloadable or anything), they do all their development inhouse behind closed doors, there isn’t any knowledge available or participatory governance model and noone else can build a market around it. It is still a GPL project, it is technically a FLOSS project, but it is about as closed as you get. It certainly isn’t conforming to the spirit of the freedoms expressed in the GPL. however it is following the letter of the licence.
We need a way to recognise these kinds of behaviours to ensure we maintain the spirit of freedom that the licences have tried to encapsulate.
By the way, I believe the power to fork is extremely important to a FLOSS project, and and don’t see this model as replacing or being more important that the FLOSS licences. I see this model as a useful way for both users of FLOSS and FLOSS projects themselves to evaluate how open they are, how free they are, from a few different angles.
The problem here is what Pia and Jeff want as to the rulesof engagement is the same as the academic world telling business what it should be doing. It is all nice to have, great in a vacuum, all the right virtues etc but companies who will decide themselves which of the principles they want to adopt and which they don’t. There is very little anybody can do about it once they decide on a course of action.
I realise in the greater world of love and harmony things may be different and all the things you hope to achieve may be realised, but I have a voice at the back of hte mond that says this is highly unlikely, especially as software starts to move from the hoby developer to organisational developed apps
Fred,
People will always decide upon what they want to do regardless. The point of this model is not to pretend to change that, we can’t. The point is to give users, people who want to adopt FOSS (and any software for that matter) better tools to evaluate whether it meets their goals, and also to understand the tangible ramifications of the various types of openness down the track/
Then, if it becomes useful as a tool to evaluate software from a users perspective (and keep in mind that it is _very_ hard for many people who are new to this space to evaluate and understand openness, so this could be quite handy). If that does become the case, then that could both lead providers of software to want to be more open _and_ it could make it plainly obvious when someone is not being very open even if they say they are.
We’re doing this to create a practical tool to help people. It’s hardly academic 🙂 If you think it’s about love and harmony then you’ve missed the point.
Fred Nerk, these are not “rules of engagement”, but elements of a model to understand engagement. It can be used by individuals, communities, businesses, on either end of the openness carrot (or stick, as the case may be).
So if it is a carrot and stick approach it sounds like rules of engagement to me as you really have no choice then, bit like the Microsoft EULA where it prescribes specific actions, bit like a stick approach