I was delighted to see that the GNOME Census presentation I gave yesterday at GUADEC has gotten a lot of attention. And I’m pleased to announce a change of plan from what I presented yesterday: The report is now available under a Creative Commons license.

Why the change of heart? My intention was never to make a fortune with the report, my main priority was covering my costs and time spent. And after 24 hours, I’ve achieved that. I have had several press requests for the full report, and requests from clients to be allowed to use the report both with press and with their clients.

This solution is the best for all involved, I think – I have covered my costs, the community (and everyone else) gets their hands on the report with analysis as soon as possible, and my clients are happy to have the report available under a license which allows them to use it freely.

You can download the full report now for free.

Today at GUADEC I presented the results (Slides are now on slideshare) of the GNOME Census, a project we have been working on for a while. For as long as I have been involved in GNOME, press, analysts, potential partners and advisory board members have been asking us: How big is GNOME? How many paid developers are there? Who writes all this software, and why?

By looking at the modules in the GNOME 2.30 release, made last March, we aim to answer many of those questions, and give deeper insight into the motivations of participants in the project.

GNOME activity over time, horizontal bars are release dates

Here are our key findings:

• GNOME has a rhythm – there is a measurable increase in activity before release time, and after the annual GNOME conference GUADEC
• While over 70% of GNOME developers identify themselves as volunteers, over 70% of the commits to the GNOME releases are made by paid contributors
  

  GNOME committer self-identification - volunteer/professional

• Red Hat are the biggest contributor to the GNOME project and its core dependencies. Red Hat employees have made almost 17% of all commits we measured, and 11 of the top 20 GNOME committers of all time are current or past Red Hat employees. Novell and Collabora are also on the podium.
• A number of top company contributors are consultancy/services companies specialising in the GNOME platform – Collabora, CodeThink, Openismus, Lanedo and Fluendo are in the top 20 companies. As many of these companies grew initially through work on Maemo, this is a sign of the success of Nokia’s strategy around the GNOME stack.

One of the interesting things that we have done for the census is to look at who is maintaining modules by looking at commits over the past two years, and use this data to identify areas of the platform which see lots of collaboration, areas where the maintenance burden is left to volunteers, and areas where individual companies assume most of the maintenance burden.

There are a number of modules in the platform which see a considerable amount of co-opetition, including Evolution, Evolution Data Server, DBus and GStreamer. Most modules in the platform, however, are either maintained to a large extent by volunteer developers, or see the vast majority of their contributions from one company.

I see this information being useful for companies interested in using the GNOME platform for their products, companies seeking custom application development, potential large-scale customers of desktop Linux or customers buying high-level support who want to know who employs more module maintainers or committers to the project.

The GNOME maintenance map, with modules coloured according to the company maintaining them

Update: The release has now been published under a Creative Commons licence on October 1st 2010.

GNOME activity over time, horizontal bars are release dates

Matt Aslett continued his series on Open Core yesterday, and pointed to my post on the subject. He says, and I agree, that we can’t expect companies to call themselves Open Core as a means of differentiating from Open Source if we use pejorative phrases like “crippleware” to refer to Open Core projects.

But that ship has long since sailed. No company has every described themselves as “an Open Core company” to anyone except VCs, as shorthand for their business model. In the software business, Open Core has no-one defending it, and it has no brand value. In fact, in free software circles, Open Core has been a pejorative phrase almost since it was coined – fauxpen source, popularised by Tarus Balog, cites Open Core as a synonym, and pretty much every mention of it which I have found has not been by a vendor referring to themselves, but by an analyst or commentator referring to a class of business models.

In one sense, that’s what is amusing about this – the valuable brand, Open Source, is the one everyone uses,  and vendors who sell Open Core products find themselves in the unenviable position of having to defend calling themselves “an Open Source company” to what they doubtless consider zealots, but there is no other brand they can use which gives the same marketing benefits while providing sufficient differentiation with Open Source.

I don’t consider the OSI or other people decrying this use of the Open Source brand as zealots, they are simply protecting their brand against dilution.

Matt argues that Open Core products don’t deliberately cripple their free software offering (at least, the good ones don’t), they merely “sell value-added features that are designed to be of value to paying customers”. I would argue that is simply a restatement. Regardless, I accept that there are some features which a proportion of the user base will be prepared to pay for, and which most of the rest of the user base won’t care about. If you can ensure that the proportion of your user base which cares about the feature but is not prepared to pay for it is small, then you have the potential for license revenues without damaging your reputation too much.

As you increase the number of features which users need to pay for, however, you will find that the number of people who care about at least one commercial feature who are not prepared to pay for it will become significant. You only have to look at the SugarForge (a nice initiative in community enablement, by the way) to see that the lack of reporting and sales forecasting in SugarCRM’s community edition is something which a lot of people are interested in – the most active & popular community projects are related to those features. Does the decision to omit those features from the core product represent hobbling? Does the presence of modules that implement those features in the Forge show the victory of the Open Source way? Both, perhaps?

SugarCRM is far from the worst Open Core vendor in this space, so I don’t want it to come across as though I’m picking on them. OpenBravo also does a good job of enabling its community to fend for itself. Others don’t fare so well, and in private will admit that their community edition is “not suitable for production environments”. While this may just be a sales tactic to get people to pay for support, the message that this sends to potential customers is “Open Source might be OK to test out & play around with, but when you want to get serious you’d better pony up or you might have trouble”. Not exactly inspiring confidence in the Open Source way there…

Reposted from my personal blog

Open core, Open core,  more Open core… the debate goes on and on, with Monty the latest to weigh in.

When you get down to it this is a fight over branding – which is why the issue is so important to the OSI folks (who are all about the brand). I don’t actually care that much how SugarCRM, Jahia, Alfresco et al make the software they sell to their customers. As a customer I’m asking a whole different set of questions to “is this product open source?” I want to know how good the service and support is, how good the product is, and above all, does it solve the problem I have at a price point I’m comfortable with. The license doesn’t enter into consideration.

So if that’s the case (and I believe it is), why the fighting? Because of the Open Source brand, and all the warm-and-fuzzies that procures. “Open solutions” are the flavour of the decade, and as a small ISV building a global brand, being known as Open Source is a positive marketing attribute. The only problem is that the warm-and-fuzzies implied by Open source – freedom to change supplier or improve the software, freedom to try the software before purchasing, the existence of a diverse community of people with knowledge, skills and willingness to help a user in difficulty – don’t exist in the Open Core world. The problem is that for the most part, the Open Core which you can obtain under the OSI-approved license is not that useful.

Yesterday on Twitter, I said “Open Core is annoying because the “open core” bit is pretty much useless. It doesn’t do exactly what it says on the tin.”

Now, I wasn’t expecting that to be particularly controversial, but I got some push-back on this. Dan Fabulich replied “Ridiculous. Like the free version of MySQL is useless?” Which leads me to think of Inigo Montoya on the top of the Cliffs on MoherInsanity turning to Vizzini and saying “You keep using that word. I do not think it means what you think it means.”

With all this talk of Open Core, clearly some confusion has crept in. Perhaps it’s on my part. So allow me to elaborate what I understand by “Open Core”.

First, companies can’t be Open Core. Products are Open Core. So whereas Monty considers that from 2006 on, MySQL was not an “Open Source company”, I would contend that MySQL Server has always been, and continues to be, Free Software, and an Open Source product. That is, not Open Core.

Open Core for me means you provide a free software product, improve it, and don’t release the improvements under the free software license. In my mind, Mac OS X is not “Open Core” just because it’s based on the NetBSD kernel, it is proprietary software.

Perhaps it would be useful to give some examples of what is Open Core:

• Jahia is Open Core – significant features and stabilisation work are present in the Enterprise Edition are not available at all in the Community Edition
• SugarCRM is obviously Open Core. Key features related to reporting, workflow, administration and more are only present in the commercial editions
• JasperSoft BI Suite is Open Core. Lots of useful features are only available to people buying the product.

The key here is that support contracts and extra features are only available if you also pay licensing fees. To take the oft-cited example of InnoDB hot back-up tool for MySQL, you can purchase this and use it with the GPL licensed MySQL Server – supporting my claim that MySQL is not Open Core.

This is why I say that Open Core products “don’t do exactly what it says on the tin” – the features you see advertised on the project’s website are not available to you along with software freedom.

I have talked to companies who deliberately avoid adding “spit & polish” to the community edition to encourage people to trade up for things like better documentation, attractive templates and easy installation – and don’t provide an easy way for the community edition users to share their own work. Other products have an open source engine that doesn’t do much except sit there, and all useful functionality is available as paid modules. Yes, a persistent, skilled, patient developer can take the Open Source version of the product and make it do something useful. For the most part, however, if you want to actually use the software without becoming an expert in its internals, you’ll need some of the commercial upgrades.

There is another name for this which is even more pejorative, Crippleware. Deliberately hobbled software. And that’s what I think gets people riled up – if you’re releasing something as free software, then there should at least be the pretense that you are giving the community the opportunity to fend for itself – even if that is by providing an “unofficial” git tree where the community can code up GPL features competing with your commercial offering, or a nice forum for people to share templates, themes and extensions and fend for themselves. But what gets people riled is hearing a company call themselves “an Open Source company” when most of the users of their “open source” product do not have software freedom. It’s disingenuous, and it is indeed brand dilution.

That said, let me repeat – I have no problem with companies doing this. I have no problem with them advertising their GPL-licensed stuff as Open Source. I would just like to see more of these companies providing a little bit of independence and autonomy to their user community. But then, that’s potentially not in their long-term interest – even if it is difficult to imagine a situation where the community-maintained version outstrips the “Enterprise” edition in features and stability.

Reposted from my personal blog

Who knew that educating people in simple sabotage (defined as sabotage not requiring in-depth training or materials) could have so much in common with communicating free software values? I read the OSS Simple Sabotage Field Manual (pdf) which has been doing the rounds of management and security blogs recently, and one article on “motivating saboteurs” caught my eye enough to share:

Personal Motives

• The ordinary citizen very probably has no immediate personal motive for committing simple sabotage. Instead, he must be made to anticipate indirect personal gain, such as might come with enemy evacuation or destruction of the ruling gov­ernment group. Gains should be stated as specifically as possible for the area addressed: simple sabotage will hasten the day when Commissioner X and his deputies Y and Z will be thrown out, when particu­larly obnoxious decrees and restrictions will be abolished, when food will arrive, and so on. Abstract verbalizations about personal liberty, freedom of the press, and so on, will not be convincing in most parts of the world. In many areas they will not even be comprehensible.
• Since the effect of his own acts is limited, the saboteur may become discouraged unless he feels that he is a member of a large, though unseen, group of saboteurs operating against the enemy or the government of his own country and elsewhere. This can be conveyed indirectly: suggestions which he reads and hears can include observations that a particular technique has been successful in this or that district. Even if the technique is not applicable to his surroundings, another’s success will encourage him to attempt similar acts. It also can be conveyed directly: statements praising the effectiveness of simple sabotage can be contrived which will be pub­lished by white radio, freedom stations, and the sub­versive press. Estimates of the proportion of the population engaged in sabotage can be disseminated. Instances of successful sabotage already are being broadcast by white radio and freedom stations, and this should be continued and expanded where com­patible with security.
• More important than (a) or (b) would be to create a situation in which the citizen-saboteur acquires a sense of responsibility and begins to educate others in simple sabotage.

Now doesn’t that sound familiar? Trying to convince people that free software is good for them because of the freedom doesn’t work directly – you need to tie the values of that freedom to something which is useful to them on a personal level.

“You get security fixes better because people can read the code”, “You have a wide range of support options for Linux because it’s free software and anyone can understand it”, “Sun may have been bought by Oracle, but you can continue to use the same products because anyone can modify the code, so others have taken up the maintenance, support and development burden”, and so on.

Providing (custom tailored) concrete benefits, which comes from freedom is the way to motivate people to value that freedom.

In addition, the point on motivation struck a cord – you need to make people feel like they belong, that their work means something, that they’re not alone and their effort counts, or they will become discouraged. A major job in any project is to make everyone feel like they’re driving towards a goal they have personally bought into.

Finally, you will only have succeeded when you have sufficiently empowered a saboteur to the point where they become an advocate themselves, and start training others in the fine arts – and this is a major challenge for free software projects too, where we often see people with willingness to do stuff, and have some difficulty getting them to the point where they have assimilated the project culture and are recruiting and empowering new contributors.

For those who haven’t read it yet, the document is well worth a look, especially the section on “General Interference with Organisations and Production”, which reads like a litany of common anti-patterns present in most large organisations; and if you never knew how to start a fire in a warehouse using a slow fuse made out of rope and grease, here’s your chance to find out.

I’m delighted to announce the availability of GNOME Developer Training at GUADEC this year. It’s been brewing for a while, but you can now register for the training sessions on the GUADEC website.

Fernando Herrera, Claudio Saavedra, Alberto Garcia and myself will be running the two-day course, covering the basics of a Linux development environment and developer tools, the GNOME stack, including freedesktop.org components, and the social aspects of working with a free software project, being a good community citizen, getting your code upstream, and gaining influence in projects you work with.

The developer tools section will go beyond getting you compiling the software to also present mobile development environments, and the tools you can use to profile your apps, or diagnose I/O or memory issues, dealing with the vast majority of performance issues developers encounter.

This is the first time I have seen a training course which treats the soft science of working with free software communities, and given the number of times that people working in companies have told me that they need help in this area, I believe that this is satisfying a real need.

We are keeping the numbers down to ensure that the highest quality training & individual attention is provided – only 20 places are available. The pricing for the training course is very competitive for this type of course – €1500 per person, including training, meals and printed training materials, and a professional registration to GUADEC, worth €250.

If you register before June 15th, you can even get an additional discount – the early bird registration price is only €1200 per person.

I’m really excited about this, and I hope others will be too. This is the first time that we will have done training like this in conjunction with GUADEC, and I really hope that this will bring some new developers to the conference for the week, as well as being a valuable addition to the GUADEC event.

I was visiting a prospective client this morning, who was interested in using SalomeTMF as a test management framework, and we were discussing whether there was any risk in choosing it as a tool.

To prepare for the meeting, I had a quick look at the project, and while what follows is not a complete analysis, it certainly reaised some red flags and some gold stars about the project.

Background:

SalomeTMF was a project created by France Telecom, and it’s hosted on ObjectWeb, as part of the OW2 consortium. It is a modular test management framework written in Java, with plug-ins for various testing and bug tracking tools like JUnit, Bugzilla, Mantis, Beanshell and more. After a healthy start to the project, with a great many incremental releases over a period of years, releases appeared to have stopped in 2007, and the original developers and maintainers appear to have become dormant.

Analysis:

Currently the project appears lacking an active maintainer, but has many users and several developers. Its user forums are quite active, and a call for new maintainers (made by a disgruntled user) shows that there are a number of people interested in ensuring that the website, wiki and software get regular updates and releases. The best placed candidate for new maintainer is a developer who made a new release of the software in September 09.

There is one email from the historical maintainer which raises a red flag for me: he says “it has been a long time since we’ve actively maintained the project, but rest assured that it has not been abandoned… We are working with partners and users of Salome to ensure future maintenance and development of the project. I will keep you posted.” This sounds to me like the old maintainers are not quite ready to completely hand over control of releases and maintenance of the website to those who are working off the OW2 forge.

In this situation, project take-overs should generally be placid. If there is a possibility of conflict, the historical maintainers will retain the benefit of thedoubt until proven wrong, in which case many more months may pass. The alternative is an aggressive take-over where someone proposes themselves as (perhaps interim) maintainer, and makes releases, reviews patches and updates the website.

The bug database shows that there are not many bugs getting closed at the moment, suggesting that the user community is waiting for someone else to do the project maintenance.

I would have liked to analyse the source repository also, but I could only find a CVS repository in the ObjectWeb forge, which versions files rather than the repository. Most of the files I found have not been modified for 2 years or more. This is not necessarily conclusive evidence that the project is inactive – it is possible that other files I didn’t look at have been heavily modified, or that development has moved to another SCM.

Summary:

The project presents considerable risks -  no active maintainers, and a community which appears to be finding its way to the point where all of the keys to the house are available to a new maintainer. The documentation for the product architecture is good, as is thedocumentation for writing new plug-ins, but there is next to no documentation of the community governance structure, and the various community resources, who has access to them, and how one gains access.

Three options exist for a company interested in using the tool in the medium to long term:

1. Consumer – use the product as it is, do some basic work-arounds and bug fixes to get it working for you, and no more
2. Passive fork – develop the product to have features and functionality which you are interested in, and send patches back to the user forum & patch tracker. Have design discussions in public on the user forum. However, do not assume or try to assume control of the project.
3. Aggressive take-over – Ask the original maintainers to hand over access to all project resources to a community member – perhaps a developer in your team – and if this does not happen in good time, take your case to ObjectWeb administrators. If that fails, fork.

An aggressive take-over has the potential to be counter-productive, and expensive, and is as such not to be favoured. Perhaps encouraging the most prominent active community member to become an active maintainer is the best way to achieve the same end.

Which alternative is best will depend on the choices available. Alternatives to using SalomeTMF might be sourcing an equivalent commercial tool, or developing an alternative internally.

If the alternative is sourcing another application, then a cost-benefit analysis of choosing the commercial solution over modifying Salome is required. If SalomeTMF is close to meeting your needs, a passive fork is an attractive choice.

I’ll be at the Open World Forum in Paris tomorrow, October 1st, and Friday October 2nd, in the Eurosite Georges V. I’ll be giving two presentations: GNOME Mobile at 12h10 on Thursday, as part of the FLOSS Mobility Summit, and Does working with Free Software have to be so hard? at 12:00 on Friday, as part of the FLOSS Vision track.

Come by & see me!

Mal Minhas of the LiMo Foundation announced and presented a white paper at OSiM World called “Mobile Open Source Economic Analysis” (PDF link). Mal argues that by forking off a version of a free software component to adjust it to your needs, run intensive QA, and ship it in a device (a process which can take up to 2 years), you are leaving money on the table, by way of what he calls “unleveraged potential” – you don’t benefit from all of the features and bug fixes which have gone into the software since you forked off it.

While this is true, it is also not the whole story. Trying to build a rock-solid software platform on shifting sands is not easy. Many projects do not commit to regular stable releases of their software. In the not too distant past, the video codecs produced by the MPlayer project, universally shipped in Linux distributions, had never had a stable or unstable release. The GIMP went from version 1.2.0 in December 1999 to 2.0.0 in March 2004 in unstable mode, with only bug-fix releases on the 1.2 series.

In these circumstances, getting both the stability your customers need, and the latest & greatest features, is not easy. Time-based releases, pioneered by the GNOME project in 2001, and now almost universally followed by major free software projects, mitigate this. They give you periodic sync points where you can get software which meets a certain standard of feature stability and robustness. But no software release is bug-free, and this is true for both free and proprietary software. In the Mythical Man-Month, Fred Brooks described the difficulties of system integration, and estimated that 25% of the time in a project would be spent integrating and testing relationships between components which had already been planned, written and debugged. Building a system or a Linux distribution, then, takes a lot longer than just throwing the latest stable version of every project together and hoping it all works.

By participating actively in the QA process of the project leading up to the release, and by maintaining automated test suites and continuous integration, you can mitigate the effects of both the shifting sands of unstable development versions and reduce the integration overhead once you have a stable release.At some stage, you must draw a line in the sand, and start preparing for a release. In the GNOME project, we have a progressive freezing of modules, progressively freezing the API & ABI of the platform, the features to be included in existing modules, new module proposals, strings and user interface changes, before finally we have a complete code freeze pre-release. Similarly, distributors decide early what versions of components they will include on their platforms, and while occasional slippages may be tolerated, moving to a newmajor version of a major component of the platform would cause integration testing to return more or less to zero – the overhead is enormous.

The difficulty, then, is what to do once this line is drawn. Serious bugs will be fixed in the stable branch, and they can be merged into your platform easily. But what about features you develop to solve problems specific to your device? Typically, free software projects expect new features to be built and tested on the unstable branch, but you are building your platform on the stable version. You have three choices at this point, none pleasant – never merge, merge later, or merge now:

• Develop the feature you want on your copy of the stable branch, resulting in a delta which will be unique to your code-base, which you will have to maintain separately forever. In addition, if you want to benefit from the features and bug fixes added to later versions of the component, you will incur the cost of merging your changes into the latest version, a non-negigible amount of time.
• Once you have released your product and your team has more time, propose the features you have worked on piecemeal to the upstream project, for inclusion in the next stable version. This solution has many issues:
  • If the period is long enough, your feature additions will be long removed from the codebase as it has evolved, and merging your changes into the latest unstable tree will be a major task
  • You may be redundantly solving problems that the community has already addressed, in a different or incompatible way.
  • Feature requests may need substantial re-writing to meet community standards. This problem is doubly so if you have not consulted the community before developing the feature, to see how it might best be integrated.
  • In the worst case, you may have built a lot of software on an API which is only present in your copy of the component’s source tree, and if your features are rejected, you are stuck maintaining the component, or re-writing substantial amounts of code to work with upstream.
• Develop your feature on the unstable branch of the project, submit it for inclusion (with the overhead that implies), and back-port the feature to your stable branch once included. This guarantees a smaller delta from the next stable version to your branch, and ensures you work gets upstream as soon as possible, but adds a time & labour overhead to the creation of your software platform

In all of these situations there is a cost. The time & effort of developing software within the community and back-porting, the maintenance cost (and related unleveraged potential) to maintaining your own branch of a major component, and the huge cost of integrating a large delta back to the community-maintained version many months after the code has been written.

Intuitively, it feels like the long-term cheapest solution is to develop, where possible, features in the community-maintained unstable branch, and back-port them to your stable tree when you are finished. While this might be nice in an ideal world, feature proposals have taken literally years to get to the point where they have been accepted into the Linux kernel, and you have a product to ship – sometimes the only choice you have is to maintain the feature yourself out-of-tree, as Robert Love did for over a year with inotify.

While addressing the raw value of the code produced by the community in the interim, Mal does not quantify the costs associated with these options. Indeed, it is difficult to do so. In some cases, there is not only a cost in terms of time & effort, but also in terms of goodwill and standing of your engineers within the community – this is the type of cost which it is very hard to put a dollar value on. I would like to see a way to do so, though, and I think that it would be possible to quantify, for example, the community overhead (as a mean) by looking at the average time for patch acceptance and/or number of lines modified from intial proposal to final mainline merge.

Anyone have any other thoughts on ways you could measure the cost of maintaining a big diff, or the cost of merging a lot of code?

Jono Bacon asked on the Art of Community blog for successful governance stories, and while I’m happy to comment on the blog, now that I’ve taken the time to write some down, I thought I might as well share them

Governance comes in many shapes & sizes of course. My favourite governance stories are about federating individuals, who manage to channel community efforts, maintain a meritocracy where code talks, and yet don’t come across as authoritarians.

Outside of Linus (who’s a good example), Ton Roosendaal of Blender has this kind of presence. Talking to Ton, it is easy to see that he cares about Blender and about the Blender Community. The care and attention that he brings to projects like “Elephants Dream” and “Big Buck Bunny”, or to the supporting documentation and conferences he organises for the community, illustrate the esteem in which he holds his users and his developer community. Even the way the Blender Foundation came into being was amazing.

One of my favourite communities is Inkscape. When they broke from Sodipodi, there was this acrimonious flame war, and something of a bitter taste in people’s mouth. So what Bryce Harrington, Nathan Hurst, MenTaLguY and Ted Gould did when they split was decide to throw open the doors, and accept code from all comers. They set a direction and some ambitious goals, but they were very clear from the start – come right in, you’re welcome. And this gave the project some great results, especially early on when it was still establishing itself. Bryce describes one of them in this article.

The success of the Inkscape project’s governance model is borne out by its ability to escape founder’s syndrome – Bryce, Nathan and Ted have now backed away from the project to some extent, they’re still there as wise heads, but they have passed off the direction of the project to other capable people.

I think the way that Drizzle was born bears some resemblance to this, and I really like the way they have consciously broken down the walls which were necessarily up around MySQL. Brian Aker’s been something of an inspiration on this. His mission statement at the announcement of the project was astounding.

Subversion‘s governance model is an exemplar of best practices too. Set a clear project scope (“Subversion is a compelling alternative to CVS”), clear goals, establish transparent and fair community processes, and open up the gates. Anything within the scope of the project is fair game. And once again, code talks. This story, from Karl Fogel’s “Producing OSS” illustrated the robustness of their governance, and the confidence the project’s leaders had in their ability to influence the project.

The Maemo Community Council has the potential to be a very good governance structure, I think.  The idea of a governing body of the community, by the community, for the community, whose goal is to canalise the efforts of a disparate group into something coherent, and to provide a legitimate point f contact for technical decision-makers in Nokia, is a novel one, and hasn’t been tried, as far as I can tell, by other companies.

Counter-examples of good governance are all around, I won’t name any in particular to protect the guilty. But many of them stem from a misguided belief in absolute free speech, to the detriment of the quality of discourse and code in the project (“we are all created equal”) which results in very chatty, but unproductive, individuals taking senior positions in the community, or a sort of shyness of the founder or leader, who doesn’t believe that it’s his place to set a direction and tone.In company-run projects, excessive control or influence is an equally toxic characteristic. Companies who retain a veto on community decisions are companies who do not trust their communities.