AT&T Civic App Hack-a-thon Announcement

The Gist:

AT&T

• AT&T will be partnering with RIT to sponsor the 2014 Rochester Civic App Challenge.
• Part of the future of innovation is in the mobile sphere - AT&T is interested in furthering that process.
• We want to engage students in the creation of app technologies, not just the consumption of them. 

Andy Phelps (Magic)

• We want to get students thinking about how things are made and how they could be made - with a focus on civic issues and a sense of usefulness to the technologies that we create.
• Contestants in the Civic App Challenge will be competing for around $18,000 of prize money.
• The deadline for submissions is on April 23rd.
• There will be a "check-in" in March to make sure projects are going well.
• On the 21st, the whole contest is started off with a Hack-A-Thon in the Magic Center.

Joe Morelle (NY State Assembly, Competition Judge)

• A personal focus on innovation and government. 
• Innovation is going to fuel our future economy, we are shifting away from an industrial driven economy.
• In order to keep government smooth, and transparent, and running well - to "peel back the onion" and make things less complicated - we use technology.

Andy Phelps (Magic)

• We don't have expectations - we want to see what people do.
• The goal is to have developers surprise us - and by surprising us to make our lives better.

Thinking about Open Source Design

Last week I was able to interview David White, the original creator of Battle for Wesnoth, about the way Wesnoth’s community has influenced the design of the game.  This has started to evolve into a small side project for me. It started out with me being curious about the way that FOSS games were designed and if there were patterns that emerged from the really good games.

Open Source games tend to have an aura of not being as polished/developed/generally good as their proprietary counterparts, a stigma that occasionally holds true. My goal up to this point is to figure out why that is, and if there are ways to approach community design that compensate for “designed by committee” types of problems.

At this point I still don’t  have any conclusions I want to draw, but I’m running into a number of hypothesis’s that I want to research farther:

• FOSS development lends itself more to derivative games or retreads of existing genres than new IPs or gameplay.
• FOSS development lends itself more to games with high replayability, rather than narrative experiences.
• FOSS  game development goes smoothest when it borrows from proprietary development practices.

Again, these aren’t conclusions, or even likely scenarios.  They don’t represent what I believe, or what I want to believe, or anything like that.  What I’m attempting to do is develop multiple angles to approach research from, so I know what to look for, and I have a context to think about what I find.

They are the most extremely early form of a thought I can have, and they’re serving purely to define for myself what I should be looking for, and what to research next.

Assuming I finish all of this and draw some actual conclusions, I’ll most likely write some sort of essay going over them, and at that point I’ll both describe in more detail what I found and put forward some theories based on those findings.

In the meantime, any readers want to suggest some of their favorite FOSS games, or articles/people they think I should be looking at?

I know I want to talk to the community around 0 A.D, and possibly ToME.  I also want to do some research into some propriety games that have strong community influence in their design – specifically Dwarf Fortress.  There’s not a lot of research being done in this area, and I don’t plan to change that, but I’m really interested in the topic now, so while I don’t think I’ll write or do anything conclusive or scientific, I do want to try and at least start some type of conversation around the topic.

Quiz writeup 1: Principles of Open Source

1. What are titles of each Pillar?

Open Exchange

Participation

Rapid Prototyping

Meritocracy

Community

2. What are the titles of each General Principle?

Make it interesting and make sure it happens : An open source project should be “cool”, it should offer a tangable benefit to the people volunteering.

Scratch and Itch : Give people something they need.

Minimize how many times you need to reinvent the wheel : Don’t do everything from scratch.

Solve problems through parallel work processes whenever possible : Allow people to work on different tasks.

Leverage the law of large numbers: Use your community to solve bugs and other problems.

Release early and release often : Don’t get sucked into chasing perfectionism.

Talk a lot:  The flow of communication fuels development and allows you to draw in more contributors.

3. What are the similarities between Weber’s eight principles, and the five pillars?

Both have an emphasis on quick release schedules, and on effective community involvement.  The principle behind both sources is that when managed correctly, largescale community involvement allows you to more easily surmount obsticals.

4. What are the differences?

That being said, Weber focuses mostly on implementation of Open Source, not on the finished result.  His general principles are designed as advice on how to make an Open Source project succeed, not as a description of the final state of that project, or what ideals it should shoot for.

5. Bonus questions

Weber draws heavily upon Eric Raymond’s writings from the Cathedral and the Bzaar, which is another book I haven’t read but probably should.

Lit Review: The Success of Open Source (Chpt. 3)

This is a pre-formatted review of an article by Steven Weber, written for a college class.  The content being reviewed can be found at : hfoss-fossrit.rhcloud.com.  Additional publication information can be found at the bottom of this review.

Summary : The Success of Open Source details how Open Source projects exist and survive when confronted by various problems.  How and why do people contribute, how are decisions made, and what social structures exist to help a project survive?

The good stuff : 

• An uncommon insight into how Open Source projects are organized and executed.
• A realistic approach to the problems of open development, and one that proposes interesting and innovative solutions to the problem.
• Well written, and easily quotable.

The bad stuff : 

• Limited in scope, the chapter spends more time thinking about the problems of open development and how to avoid them than how they could be fixed.
• No clear picture of how a project could be passed into other hands without forking it.
• Closed, centralized design feels limited, and the article doesn’t really propose any solutions.

Questions : 

• Are there ways to coordinate community into software design without breaking it?
• How do we encourage volunteers to participate in areas that are not glamorous or highly attractive?
• Are there ways we can better control group dynamics and politics in the power structures of Open Source Projects?

 The Review : The Success of Open Source is a long article, and I don’t feel equipped to make any decisions on whether or not I agree with everything in it.  That being said, it’s a fascinating decent into the structure of FOSS communities that paints a picture of a society that is in no way anarchist or unstructured.  Along the way it raises a large number of interesting questions about how group-think can interact with software development and be managed to create incredibly end-products.  As a conversation piece, the article is fantastic; as a reference it’s even better.  The Success of Open Source diffuses a number of misconceptions I had about the nature of FOSS development, and gives a fantastic jumping point for greater analysis and further research.

Final Rating : Out of 10 stars, I give The Success of Open Source a bucket of ice-cream and three puppies, because finite, linear rating systems are just as meaningless and inapplicable to the dissemination of knowledge as this sentence.

Publication Information : author: Steven Weber, date published: November 30, 2005, source:http://hfoss-fossrit.rhcloud.com/static/books/Weber-SuccessofOpenSource-Chap3.pdf.