November 23, 2010
General
9 Comments
Novell will be bought by a North American group called Attachmate that appears to be made up of financiers buying assets as investments. As someone who has seen one acquisition of a company by financiers up-close, and an acquisition of legacy products, where they languished as cash cows, I feel partly qualified to guess what might happen to Novell post acquisition – although I am often wrong about these things, so take all this with a pinch of salt.
The first hint is that Novell is being split into two groups – traditional Novell activities (mostly identity, security, systems & resource management) and Linux business (Suse Linux – presumably including things like Mono, the desktop group, OBS, Suse Studio and other related interesting stuff). In summary, looking at last quarter’s results (PDF link), old stuff that still generates a lot of revenue but little growth, and new & growing business, which just recently became profitable.
If you are a Dark Hand type of guy, the financier who wants a return on investment and doesn’t really care about innovation or changing the world, then your goal is to buy assets, perhaps sell a subsidiary or two to recoup some of the costs of the deal, perhaps change the management team, and keep the profitable business for a 5 year horizon before selling it on to make a profit. Your anticiated ROI for this type of deal would need to be around 8% to 10% per year.
So you sell on some patents & copyrights that you’re not really interested in (presumably with a free license to use said patents for a period of time), you split your business up into the cash cow moneymaker (Old Novell) and the new, growing business that can sell at a high valuiation relative to its earnings (Suse Linux), and you line up a buyer for the speculative Linux business. With $450M for patents and perhaps $800m for the Linux business, you get old, profitable business with limited growth potential, but with regular earnings (~$600M for the last financial year, as far as I can tell, in legacy revenues, with an operating net margin of >10%) and $300M cash on hand (after subtracting liabilities & deferred revenues from cash on hand).
Let’s do the sums, then: let’s say, for arguments sake, that Suse ends up being worth $800m (not unreasonable given annual revenues in the $300m range, with great growth prospects). This represents probably a 3x valuation of (Suse + Ximian), given that Suse was bought in 2003 for $210m – certainly not unreasonable given the growth of Suse and Linux since then, this might even be on the low side. Add in the $450m for patents, and $300m cash assets that they’re getting as part of the deal.
That means Attachmate will be getting all of Novell’s legacy business for $650m, around one year’s revenue. With an annual return of >10% per year on revenues. Presumably, there will be some cost cutting to increase that margin further, and some growth will be expected, so I’m sure that Attachmate are confident that they will find a buyer for Novell after a few years for around the same price, giving them that 50% return in around 4 or 5 years.
I’m sure that some people here more familiar with the financial markets, SEC filings and annual reports, and generally “the way things work” will point out the half-dozen flaws in my thinking here, but this is what I expect to happen – a lot of people in non-core areas will be laid off in an effort to reduce costs and “streamline” the company (ie. make it a more attractive acquisition target), Suse will be sold on, and Novell will be kept as a cash cow.
To all the friends I have working with Novell, I wish you well. Acquisitions are uncertain times, and morale sapping at the best of times. The dust will settle soon.
November 14, 2010
community, maemo
4 Comments
As part of the early bird events before the MeeGo conference this week, I ran a lollipop bridge building contest last night at the conference venue. The rules were simple: 100 lollipop sticks, a glue gun, and you have to bridge a 40cm gap, and resist as much weight as possible. We had about 40 participants, and 10 bridges entered.
There were two awards: prettiest bridge and strongest bridge. Obviously, the prettiest bridge contest was judged first.
Before...
The results were really impressive! The prettiest bridge was designed by Team Symbio, Ville Kankainen, Ilkka Maki, Henri Ranki and Márton Ekler. It was a beautiful arch bridge.
Team Symbio working on the prettiest bridge
The winning bridge, made by the team “The Unbreakables”, Casper van Donderen, Dan Leinir Turthra Jensen and Sivan Greenberg, survived the shopping basket we used as the breaking tool, with 25 1L bottles of water on top – impressive! The bridge was eventually broken when Chani tried to hang off it.
The Unbreakables - looking very smug
Some of the bridges held quite a lot of weight – and broke very spectacularly!
...and after
November 8, 2010
maemo, work
2 Comments
Some of you may be interested in a guest article I wrote for the VisionMobile blog reviewing the state of MeeGo eight months after its announcement: “The MeeGo Progress Report”
Some excerpts:
On the state of the MeeGo application developer story:
From the point of view of tools, documentation and software distribution channels, MeeGo is undoubtedly behind its primary competitors – but for such a young project, this is to be expected. The success of the project among application developers and the free software community will depend to a large extent on the project’s ability to fill these gaps and provide developers with an excellent development experience.
On the openness of the project:
[…] In the mobile platform development world, it is fair to say that MeeGo is second to none in terms of its open development model.
On comparisons with Android and iOS:
It does not feel fair at this point to compare MeeGo, a project which came into being 8 months ago, with iOS or Android, but this is the yardstick which will be used when the first MeeGo smartphone comes on the market. The project has come a long way since its inception, in particular in working towards an open and transparent development model. There is still some way to go but improvements have been happening daily.
November 6, 2010
community, gnome
2 Comments
When I was growing up in the small village of Bangor Erris in the West of Ireland, we had a bitter rivalry with people from Belmullet, the next town over. In sports, and in school, it was always “them” and “us”.
I went to boarding school in a much bigger town, Ballinasloe. It’s fair to say that not everyone in Ballinasloe knew everyone else. Our idea of “them” and “us” changed – “we” were the boarders, the townies, the bus students. There were even smaller factions – Creagh, Ahascragh, Kiltormer, …
Malcolm Gladwell mentions Dunbar’s Number, the magic figure of 150 as the maximum size of a village in the Tipping Point – the same figure is cited in David Wong’s article “the Monkeysphere”. Beyond around 150 people, groups start to segment into smaller clans, identifying differences and similarities on ever smaller scales. Towns don’t organically grow with huge rates of change, but companies, projects and industries do. And as these grow, our self-identification evolves with them. You go from being “a Google guy” to “a Google Mountain View guy” to “a Google AdWords guy” or “a Google Docs guy”.
When GNOME was young, “us” was GNOME, “them” was KDE. But GNOME has turned into a bigger town, and “us” is different now. How do GNOME developers self-identify now? By employer (Red Hat, Collabora, Novell, …), by area of participation (l10n, docs, art), by geography? And how can we recognise these sub-communities and start building bridges between them?
October 28, 2010
gnome
8 Comments
I was more than a little amused when (in a vanity exercise) I re-read Joe Brockmeier’s 2007 profile of me while I was OpenWengo community manager. Among the topics we talked about was where I saw GNOME going, and I said this:
Neary says he thinks GNOME will either grow into different projects — such as a One Laptop Per Child (OLPC) GNOME, a Home and Small Office GNOME, and Enterprise GNOME — or the project will shrink to the GNOME development platform, “which will then be re-used by third parties to build the interfaces they’re interested in on top of it.
“We have already started to see this trend. Distributors cherry-pick the applications they are interested in for their own desktop projects, which are then themed and targeted for their core audience. The variety of platforms and human interfaces being built upon the GNOME platform is dazzling. These go from small-form-factor interfaces like the Nokia N800 and the Maemo application framework and OpenMoko and GPE through to innovative interfaces like Sugar from OLPC, which is totally unfamiliar to someone used to the GNOME desktop, but which is undeniably GNOME-based.”
It isn’t just the embedded or odd form-factor devices that are customizing GNOME, says Neary. “Even the major distributions have modified the GNOME interface to suit their needs. The openSUSE, Red Hat Enterprise, and Ubuntu desktops all behave in different ways, and have different target audiences.”
From memory, I don’t recall mentioning Home & Small Office or Enterprise GNOME, but I certainly remember saying that I thought we should adopt Sugar as “GNOME Education”, maybe Maemo as “GNOME Mobile”, moblin as “GNOME Netbook”, etc.
So it looks like the latter scenario has started to come to pass. The GNOME project is concentrating on defining the core platform and distributors are building usecase-specific or brand-differentiating user interfaces on top. Is it too late for GNOME to embrace this trend, or have we become technology suppliers only?
October 26, 2010
community, freesoftware, gnome
59 Comments
Having slept on it since writing my initial reactions yesterday I now have a proposal for Canonical & GNOME, which I hope the people concerned will consider.
Yesterday, I said “the best possible outcome I can see is that one of the two projects will become an obvious choice within a year or so”. So my proposal is this: let’s have a bake-off, Unity vs GNOME Shell, under the big tent of the GNOME project.
What needs to happen? Unity would have to agree to sync to the GNOME release schedule. Canonical will need to drop their copyright assignment requirement for Unity, and should ideally commit to using some of GNOME’s infrastructure. How much will need to be discussed. I’m sure that the Unity developers will want to continue to use Launchpad for bug tracking and bzr for source control, but perhaps the development mailing list could move to gnome.org, and the Unity website could be gnome.org/projects/unity or unity.gnome.org instead of unity.ubuntu.com?
GNOME will have to accept Launchpad as a platform for the development of GNOME software – there are potential integration issues, it is a headache using Launchpad & Bugzilla, co-ordinating Rosetta & upstream translation teams, and so on. But right now there is a general feeling that gnome.org is for “official” GNOME software, and Launchpad is for Ubuntu. We need to change that perception if we hope to be inclusive of Canonical and the greater Ubuntu developer community in GNOME. In fact, broadening the definition of what we call GNOME software was a key plank in the release team platform for 3.0 – resolving this question (and the equivalent question for projects hosted on Google Code and Sourceforge) will go a long way to growing the big tent. The GNOME project should also work to make it easy to switch from one shell to the other.
Developers who feel drawn to one philosophy or the other should work to make sure that their vision is the best it can be by September 2011. And at that point, presumably at the Desktop Summit in Berlin, GNOME, as a project, should choose one of the two, and put our full weight behind it.
This is potentially naïve on my part. Over the years, we have allowed a lot of animosity to build up between Canonical and Red Hat, among others. As a community, we’ve stood passively by while this has happened. Some will point to efforts to engage which were rebuffed. Others will point to a lack of real commitment to engage.
In situations like this, no-one is 100% right, no-one is 100% wrong. All we can do is look at the current situation, and ask ourselves: how do we get to where we want to go, from where we are? We have two choices – we can, like the Mayoman asked for directions to Galway by tourists, respond “If I was going to Galway I wouldn’t start from here at all”, or we can roll up our sleeves and try to make things a little better.
So – how about it? Is this a non-starter, or is it worth starting some conversations about it?
October 25, 2010
community, gnome
59 Comments
At this stage, most people will have heard the news: Ubuntu 11.04 will ship with Unity as the default desktop shell. This raises a few questions: what does this mean for GNOME, and the adoption of GNOME Shell? Will this further affect the relationship between Canonical developers and others working on the same problems?
First things first: what Canonical is doing here is not new, by any means. Novell developed the slab on their own, based on their user testing and to their own design, before proposing it for inclusion in GNOME once it was released in Suse Linux Enterprise Desktop. Nokia have developed custom user interfaces on top of the standard Linux desktop shell for the past 5 years, built with GNOME technologies, and have actively participated in the development of core components through the GNOME project – they are now developing a custom interface based on Qt, for smartphones, using the same standard desktop stack. OpenMoko did the same thing with the Freerunner. Intel built a custom shell for netbooks in the Moblin project, which is now the netbook interface for MeeGo. OLPC built a custom designed user interface for educational computing devices. GNOME allows and enables this kind of work, because of the great platform and infrastructure we have provided over the years to all Linux software developers.
In such illustrious company, forgive me if I think that Canonical’s management has seriously underestimated the difficulty of the task in front of them.
At the time, the slab further damaged the relationship of Novell developers and the GNOME project – Dan Winship wrote a scathing mail to a GNOME list when asked why Novell had not worked in the open on such a significant development, saying in short that it was impossible to work in the open in the project – the logical conclusion of the siege mentality bred by the negativity around Mono development and the numerous acrimonious debates at the time.
Nokia have had repeated issues coming to terms with open development, and reconciling the need to differentiate and the desire to create an open collaborative project. Their conclusion – to increase the openness of their software platform and collaborate in the MeeGo project – bears witness to the difficulties they have had over the past five years developing a high quality, innovative mobile user experience alone.
OpenMoko repeatedly ran into performance and flexibility issues, and frequently changed software strategy, to the point where the project was no longer viable. Their success was in creating a vibrant independent developer community, which has allowed their dream to live on in projects like Hackable Devices, and its distribution Hackable:1.
Intel have followed a similar path to Nokia – creating an independent vendor-let user interface project, having trouble getting a high quality product out the door, and they are now in the process of opening up and collaborating on the netbook user interface through the MeeGo project.
OLPC had many teething problems with the Sugar desktop environment. Bugs, stability and performance issues plagued the project for many months, to the point where they abandoned the development of the stack as the primary target platform for the devices. The project lives on in Sugar Labs, thans to a broad and vibrant developer community.
There is not one out-and-out success story of a company building a great high-quality custom user interface on the standard Linux stack, except Android, which is hardly a model of collaborative software development.
Is this because of problems in out platform? A lack of developer tools? Insufficient documentation? Perhaps – but if that’s the case, don’t all of the aforementioned have a shared interest in improving those raw materials?
There is another possibility which seems to me more plausible: building a rock solid and functional desktop is hard. Really hard.
So why do people do it? Because working with old code is painful. After years of use, and bug fixes, and nasty hacks, the code gets to look ugly. Really ugly. I’ve been in the situation myself – you’re working on crusty, crumbling, slow code from 10 years ago, and you say to yourself “I could write better than this in a weekend”. And you do get to a decent proof-of-concept in a few days. And then you have to harden it. And you spend months and months fixing bugs until finally it does everything the old code did, better, and a few new things, but it took you 2 years of development. And it looks just as hairy as the old code did. As Joel Spolsky wrote: “there is absolutely no reason to believe that you are going to do a better job than you did the first time”.
Astute readers might notice that I did not include Red Hat and GNOME Shell in the list of “custom user interfaces” in my list. That is because of the way this project started, and is being developed. The project grew from the ideas of the Pyro Desktop and the Online Desktop & BigBoard, both show-cased at GUADEC back in 2007 in Birmingham, the core design grew from a User Experience Hackfest in 2008 which happened during the Boston Summit, and has evolved in a public wiki. The source code has been public from the start, with a public mailing list, and a designer who has been openly communicating design thinking, and crying out for outside contributors.
I have been telling people for a while that transparency does not equal democracy, that it is possible to have a coherent design in a community-developed project – all you need is a designer that the developers trust who can communicate what is important about his design, who is not afraid to adapt his design based on feedback, but who has the last word on what gets written.
Canonical, and other vendors, do this by appointing a designer, and basically forcing developers to implement what he comes up with. But there’s no reason it can’t be done in the community – as it has been in the past (Seth Nickell’s design of the desktop file chooser, mostly implemented by Federico Mena Quintero, comes to mind).
I fear, however, that this is just another step in a pattern which has been coming for a while. Jeff Waugh said it well today on Twitter: “ as default shell == brand before community, differentiation before collaboration.” Canonical values the Ubuntu brand, as they should – but in recent times there has been a move to favour that brand over a better core product that all can share. Unity and Ayatana are merely the most recent in a chain of projects pointing in that direction. Canonical has long had to defend a relatively low contribution level to upstream projects, preferring to position themselves as an integrator, adding fit & finish. Even for public projects like 100 paper cuts, I have been told that there has been limited success in getting patches integrated upstream – I have heard anecdotal accounts of patches that were “evil hacks”, or fixes which were expeditiously made to Ubuntu or worked around a symptom without fixing the root cause. I can’t attest to this – a spot check of 5 paper cuts showed me one Ubuntu-specific fix, one “CLOSED INVALID”, one fix which was rejected, and two fixes integrated upstream.
Back in July, when the GNOME census came out, I commented on Jono Bacon’s blog entry on the subject:
Canonical’s strategy is to develop new features for the desktop, which have not (yet) been included in GNOME.
This is a strategy which has back-fired on a couple of people in the past – it’s not enough to work on something and then propose it for GNOME as a “take it or leave it” choice – the GNOME developers often have feedback on design decisions and request some changes which you mighht not be prepared to make in developed software, but which might be OK to make in a spec […]
One thing I really want to avoid is the creation of a siege mentality of “Canonical vs Rest of the World”, which is counter-productive to the goal of increasing the contribution of Canonical to core GNOME. It’s good to be aware that Canonical are not maintaining core modules, and look for easy ways we can help that happen. Proposing new modules is one path toward that, and contributing to the maintenance of some modules which need it is another.
Unfortunately, this choice of Unity as the desktop user interface, instead of supporting the steadily progressing GNOME Shell project and trying to influence the direction of that project, is another step on the path to the siege mentality. This move will inevitably garner some support from within Ubuntu, and much criticism from the rest of the GNOME ecosystem, further isolating Canonical and the Ubuntu community from the rest of the free desktop development community.
The best possible outcome I can see is that one of the two projects will become an obvious choice within a year or so – and at that point either GNOME will adopt Unity (if Canonical drop the copyright assignment requirement) or Canonical will adopt GNOME Shell (if, as I expect, Canonical struggle to get Unity to the quality standard their users expect). A worst case scenario would see both projects suffer from the competition, putting the free software desktop another two years behind in its quest to beat Apple & Microsoft on features & functionality.
http://twitter.com/jdub/status/28694608944
October 21, 2010
community, freesoftware
22 Comments
There has been a lot of commentary in recent days about the OpenOffice.org community council decision to ask people who have aligned themselves with The Document Foundation (TDF) to resign their seats on the council. So, of course, what we need is a little bit more commentary.
First, when reading the minutes, it’s worth noting that this was not a voted decision. At 21:50, Louis Suarez-Potts proposed “that the TDF members of the CC consider the points those of us who have not joined TDF have made about conflict of interest and confusion [and] resign their offices, so as to remove the apparent conflict of interest their current representational roles produce”. He then proposed a deadline of Tuesday “to deal with this” – by emergency meeting of the council. So there was no decision to expel anyone, Louis made a proposal which did not obtain a consensus decision. That said, reading the minutes, there is clear alignment between supporters of TDF on one side and the rest of the council on the other side. And “the rest of the council” is Louis Suarez-Potts, Andreas Bartel, Eike Rathke, Juergen Schmidt, Matthias Huetsch and Martin Hollmichel on behalf of Stefan Taxhet – all Oracle employees.
Second, let’s put this in perspective. Louis is the OpenOffice.org community manager, and has been for several years. Andreas, Eike, Juergen, Matthias and Stefan are all former Sun employees, and as best as I can tell, also former StarDivision employees. So this is hardly an Oracle corporate decree. It is a group of long-time contributors to OpenOffice.org taking a position on the community council vis à vis LibreOffice. I have been telling people for years that corporations don’t get to be members of free software communities – although their employees might. Let’s apply that same standard when commenting on actions by individuals, and assume less cloak-and-dagger. “Oracle” have not decided anything here.
That said, looking at the council structure, it’s clear that it has been set up so as to make it very difficult for Oracle/Sun employees to ever find themselves in a minority on the council, if they do decide to act as a block.
Third, let’s look at the substance of the discussion itself. The Document Foundation defines itself as “an independent self-governing meritocratic Foundation, created by leading members of the OpenOffice.org Community”. Implicit in this is a criticism of OpenOffice.org: the project is not independent, self-governing or meritocratic. Calls for OpenOffice.org to be managed by an independent not-for-profit are not new – in fact, I was one of those calling for it over the past few years. So clearly, the creation of The Document Foundation is a reaction to perceived and actual dysfunction in the operation of OpenOffice.org. In fact, in its initial communications, The Document Foundation clearly stated that the name LibreOffice was provisional, and that they hoped that Oracle would allow the foundation to use the traditional OpenOffice.org name – in other words, TDF wants LibreOffice to supersede OpenOffice.org as a project.
How, then, can people who have aligned themselves with the new initiative keep a straight face and say they are not trying to undermine OpenOffice.org? Traditional contributors to OpenOffice.org are now faced with a choice: will I update my source code daily from OOo, or from LibreOffice? I have met project volunteers who had no prior knowledge of the split who are now torn between two groups. They feel like they have to decide. For the instigators of the revolution to pretend otherwise is disingenuous.
I’ve been told that I’m conflating “OpenOffice.org” the project, and the OpenOffice.org community council, which was created to represent “the OpenOffice.org community” – and that all of the non-Oracle community representatives feel it’s in the best interests of the OOo community to align with TDF, and as such it is Oracle representatives on the council who are in conflict of interest with what is best for the community they are representing. That may be the case, I’ll leave you to decide. It seems to me that supporting LibreOffice implies withdrawing support for OpenOffice.org, and thus forfeiting any mandate you might have to represent the OpenOffice.org community. Individual community members will surely make up their own mind.
A fork is like a schoolyard football game. Tommy brings a ball to school, and gets to be captain of a team every time, picks the best players for himself, because if he doesn’t, he threatens to take his ball away. After a few weeks of this, the other players get annoyed, and everyone chips in to buy a ball for the group. At this point, Tommy has lost all power – he still has his ball, but he’s not team captain any more. He gets left standing against the wall till the very end to teach him a lesson in humility. So he sits out the games for a while in protest, starts a competing game at the other end of the yard with his ball and his rules. All the best players go to the other game, though, and some of the kids make fun of “Tommy’s” game – invitations to give up his game & join the new one seem more like taunts than honest efforts to include him. After a while, he realises that playing football with others is more fun, and more important, than playing with his football.
I welcome the creation of The Document Foundation. I believe that it will be good for office software on the free desktop. I would prefer supporters of TDF to be dignified and forthright during the split, and to come straight out and say “we think TDF offers a better future for OOo than OOo does – so come join us”. Let the dust settle, and maybe in 6 months or a year, when the functionality gap between LO and OOo has widened a little, propose once more that Oracle and IBM engage with the foundation. At that point, such a proposal will seem like an honest effort at reconciliation. Right now, it feels more like rubbing Tommy’s nose in it.
Updated to reflect feedback, 11:30, 2010-10-21
July 29, 2010
community, freesoftware, gnome, guadec, work
8 Comments
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.
July 28, 2010
General
71 Comments
(Reposted from Neary Consulting)
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.
The GNOME heartbeat - pre-release peaks and GUADEC boosts
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
- 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.
Company |
Commits |
Percentage |
Volunteer |
101823 |
23.45 |
Unknown |
73558 |
16.94 |
Red Hat |
70790 |
16.30 |
Novell |
45349 |
10.44 |
Collabora |
21684 |
4.99 |
Intel |
11160 |
2.57 |
Fluendo |
10218 |
2.35 |
Lanedo |
10090 |
2.32 |
Independent |
8922 |
2.05 |
Sun |
8862 |
2.04 |
Nokia |
6183 |
1.42 |
Openismus |
5303 |
1.22 |
Codethink |
5276 |
1.21 |
Eazel |
4734 |
1.09 |
Litl |
4620 |
1.06 |
Canonical |
4487 |
1.03 |
Movial |
2988 |
0.69 |
Mandriva |
2504 |
0.58 |
The Family International |
2130 |
0.49 |
Entropy Wave |
2056 |
0.47 |
(Academia) |
1894 |
0.44 |
Mozilla Corporation |
1040 |
0.24 |
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: Two significant omissions in the maintenance map were pointed out to me. After correctly associating a number of commiters to a company, Lanedo is responsible for 16.5% of the commits in GTK+ over the past two years, and volunteers are also responsible for at least 17%. Red Hat are still the largest contributor, with 32% of all commits to the module. libsoup is maintained by Dan Winship, who left Novell to join Red Hat in 2007, where he developed and maintains the module.
Update 2: As I announced in this post, the report is now available as a free download via neary-consulting.com licensed as Creative Commons by-sa 3.0
« Previous Entries Next Entries »