What we did:
My team and I researched MonoGame primarily through its Github page, main website, and Google. Before the project, I had crawled through the MonoGame source and interacted with its developers on Github. We attempted to augment our own research with git_by_a_bus, but the way the git_by_a_bus was written caused it to keep eating up the machine's memory.
Some context and history:
"From the website: MonoGame is an Open Source implementation of the Microsoft XNA 4 Framework. Our goal is to allow XNA developers on Xbox 360, Windows & Windows Phone to port their games to the iOS, Android, Mac OS X, Linux and Windows 8 Metro. PlayStation Mobile, Raspberry PI, and PlayStation 4 platforms are currently in progress.
In 2009 José Antonio Leal de Farias, an active member of the XNA community, started an open source project called XNA Touch with the goal of porting simple 2D XNA games to mobile devices. He started from Bill Reiss’s SilverSprite and some bits of Mono.XNA and in December 2009 the first release which only supported iPhone was posted on Codeplex.
...
In March 2011 the project was renamed MonoGame and was moved to GitHub. That same year support for Android, Mac, Linux, and OpenGL on Windows appeared. Dominique Louis who joined the project in 2009 took over as the full time project lead."
What is the community?
Monogame has had 8 main developers over the course of its entire life. Currently there are 4 : Steve Williams, Tom Spilman, Andrea Magnorksy, and Jacob Anderson, who also approve patches. Over the course of the project there have been 138 contributors, and 6,089 commits. Tom Spilman acts as the lead developer for the project, and is probably the best person to contact if you have additional questions.
Monogame has a large community of developers behind it, which has steadily been growing as more and more indie developers use it and give credence to the project's credibility and stability.
Would the project survive the raptor test or if 20% of contributers were killed?
My assumption is that because monogame is starting to get essential, and because the people using it are in a position to also write code for it, it would get picked up again. While killing a large portion of the developers would be a huge detriment to the project, it would probably recover. One of monogame's strengths is that its userbase is often involved in development - this means that there are a lot of people with stake in the project, and an ability to code and improve upon it.
Monogame's Documentation/ Bug Reporting/ Quickstarts to contributing:
Monogame has a large amount of documentation by pure virtue of being able to use most of the old XNA documentation. It's very easy to start using.
The source code itself is also well documented; there's a good quickstart guide and the code is well-commented. Outside of that though, you'll be somewhat on your own as to finding what bugs/features to work on.
Bugs/issues/milestones are managed through GitHub's issue tracker, which is managed by the lead developers. This is also where most of the conversations take place - it's here you'll find talks about release schedules, future changes and merges, and so on. Monogame has no mailing list and little activity on any IRC channel.
Is contributing to Monogame right for you?
It depends on what you want. Monogame isn't terrifically helpful getting you set up or helping you through problems. That may be something you like (independence, less scheduled accountability) or it may be a problem for you (less help when you run into problems, harder to talk about specific issues, harder to get people to work on things)
Any conclusions?
- There are a small number of people in charge, but those people are taking input from a large number of independent contrubuters, each with a fair amount of power over the direction. Merging in large amounts of code requires communication and getting to know the community.
- There is a large sense of independence in the project. The largest amounts of development are being done in forks by other people, and then after significant amounts of development (getting a game released, etc...) then merging it back in. There are positives and negatives to this approach.
- The community doesn't do a great job holding your hand, but there's room to experiment. There's a strong DUI ethos, at least that we saw.
Callaway Coefficient of Fail :
For what I had seen from FOSS development in the past the standards of the Callaway Coefficient of Fail were no surprise to me. The FOSS community isn't all the sunshine and rainbows that my professor may paint it out to be; a lot of the FOSS community is highly critical of Windows and proprietary software developers.
-------------------------------------------
Size: + 0
Source control: + 0
Building from Source: + 50
Bundling: + 0
Libraries: + 20
System install: + 20
Code oddities : + 20
Communication : + 15
Releases : + 0
History : + 10
Licensing : + 10
------------------------------------------
145 - So much fail, your code should have its own reality TV show.
Our assessment:
Monogame is here to stay. The community is still growing and the project is still maturing, but nothing's going to get rid of it anytime soon. It is, by all sane measures, a highly successful project.