No More Relics!

Gonna be completely honest: I’m freaking out right now.

The semester is winding down, and it’s go-time for Fortune Hunter.  My team has been working for weeks on refreshing this old game for the OLPC  laptops.  I’m the artist, which is a welcome change of pace and an awesome way to increase my game designer well-roundedness, but I’ve come to a horrible realization.

You see, when you write code, you may have your own style.  However, code is code.  You don’t perceive it in the same way as art.  If it works, it works.

Art is different.  Style is hard to imitate.  You can get close, but the point is that it’s difficult.  I would hate to leave this overhaul incomplete.  It would be a tremendous disservice to whoever decides to pick the project up in the future.  In fact, it would be worse than doing nothing at all.  It’s discouraging.  It’s taunting.  I hate finding art relics, and I refuse to perpetuate this nonsense.  It’s the least I can do.

So, tl’dr: I’m going to finish this art overhaul even if it kills me.

Feel free to peruse the repo too.  Some of my stuff is already up. 😀

Advertisement

Thoughts on Evgeny Morozov’s “The Meme Hustler”

Here it is, if you’re interested: http://hfoss-fossrit.rhcloud.com/static/books/evgenymorozov-thememehustler.html

Published 2013

This article is entitled “The Meme Hustler,” and it’s all about Tim O’Reilly, founder and CEO of O’Reilly Media.  The articles serves to analyze O’Reilly through the lens of his published work.  Morozov tears deep into O’Reilly, as he attempts to show that O’Reilly is actually a bit of a self-perpetuating monster with flawed ideals and too much power.

The Good

• Clear and consistent voice, an easy read.  Not super-academic or dry.
• Stays focused on picking apart O’Reilly’s actual words instead of simply attacking him out of opinion
• Provides context by mentioning the people around O’Reilly (friends, foes, and influences), like Richard Stallman and Alfred Korzybski

The Bad

• Progresses chronologically and conceptually, which can be confusing
• Ends abruptly
• Not a clear indication of a specific point to be made other than “This guy is kind of awful”

I’m still wondering…

1. What does Tim O’Reilly think of this article?
2. Just how much influence does he realistically have in government and politics?
3. Who is O’Reilly’s main, current opposition?  Is there an anti-O’Reilly with a similar amount of power?

What I think…

I liked this article.  It stuck to the facts, and Morozov is clear about exactly what he doesn’t like.  Every section of paragraphs serves to show something clear and focused, with plenty of quotations from the man himself.  Morozov thinks that O’Reilly is a bit of a madman, but in Morozov’s defense, O’Reilly isn’t doing himself any favors.

Morozov attacks his topic from multiple angles, and while I would have love a better organizational scheme for these angles, they are there nonetheless.  I learned about O’Reilly’s philosophical roots, his vast self-marketing resources, and examples of self-contradiction abound.  Clearly, this author has done his homework.  Actually, he does talk about that a bit in the author’s notes at the bottom of the page.

Anyway, I wouldn’t take this article as the definitive guide to Tim O’Reilly.  Everyone has bias of course.  What I will say is that Evgeny Morozov has done a wonderful job of saying his piece without sounding like an angry, bitter old man with a grudge.  Even if you disagree, and you totally love Tim O’Reilly, give it a read first and be salty later.

5/5 for doing your homework and delivering an enjoyable read.  Good job, Mr. Morozov.

Easiest Bugfix Ever?

Why do we not fix bugs?

Before you spout out your answer, focus on what I didn’t say.  I didn’t say “Why do we not find bugs.”  I specifically asked about fixing them.  Yes, there is a story for this one.

I was semi-frantically looking around the cramped, crowded alleyways of GitHub for a small bug to fix.  I’m no code-vigilante, it was an assignment for my Free and Open-Source Software class.  Intentions aside, I stumbled upon the strangest phenomenon.

In the Issues section was a bug observation that actually contained the solution.  Now, I’m not simply applauding my own luck for finding a fixed-but-not-actually-fixed bug to easily complete my assignment.  Rather, I’m quite puzzled.  This person seemed quite competent, so why didn’t he fix it?  It was literally a single line of code.  That was all it took to fix this issue.  In fact, to even notice the problem, he had to have been looking at the code.  I didn’t see a pull request.  Was he waiting for the core team to fix it?  Do a lot of people do that?

If not for FOSS, would I have done that?  Hmm…

Extra Random Thoughts on Weber’s Open Source ch3

So, Weber has these 8 Principles…

1. Make it interesting and make sure it happens
2. Scratch an itch
3. Minimize how many times you have to reinvent the wheel
4. Solve problems through parallel work processes whenever possible
5. Leverage the law of large numbers
6. Document what you do
7. Release early and often
8. Talk a lot

And opensource.org has these 5 Pillars…

1. Open exchange
2. Participation
3. Rapid Prototyping
4. Meritocracy
5. Community

Weber’s principles are functional. They deal with the “how” of FOSS.  In contrast, the pillars are descriptive and explain the “what.”  As such, the principles can be seen as demonstrations of the pillars.

• Principle 1 demonstrates pillars 1 and 5, as communities form around making cool stuff and talking about it.
• Principle 2 deals with pillars 2 and 5, as people come together naturally to solve problems that they encounter themselves.
• Principle 3 is best viewed through the lens of pillar 5, as one should rely on the community’s efforts to avoid doing that which has been done already.
• Principle 4 is pillar 3 in motion, but draws on the advantage of pillar 2. With enough prototypes and branches, progress is made in an evolutionary way.
• Principle 5 to me is purely an expression of pillar 2. The law of large numbers is basically used here to show that when a lot of people work on a project, more bugs are found and more progress is made. Pretty simple.
• Principle 6 may be hard to relate to the pillars for some, but I’ve found it to be closely related to pillar 5. Documentation is like the constitution of an open-source project. The understanding granted by it is a unifying factor in its community.
• Principle 7 is the pure form of pillar 3 and is a strange phenomenon, akin to a carefully moderated, intelligently designed evolutionary process. Basically, it’s iterative development. Fail a lot, then profit.
• Principle 8 is the fuel for the community (pillar 5). Communication is the lifeblood of a community (hence the same root). If developers didn’t talk, nobody would be able to get a feel for what is going on or what needs to be done.

Steven Weber drew heavily upon the analysis of Eric Raymond, specifically his essay “The Cathedral and the Bazaar” which is closely related to Fred Brooks’s “Conceptual Integrity.”

http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/

Thoughts on Steven Weber’s “The Success of Open Source” (chap 3)

If you’re interested in the part that I’m talking about…

http://hfoss-fossrit.rhcloud.com/static/books/Weber-SuccessofOpenSource-Chap3.pdf

Published 2005

The chapter is called “What is Open Source and How Does it Work?” and that basically describes it. It breaks down the process of open-source development as well as the problem it tries to solve.  Basically, it’s a primer for open-source, explaining its inner-workings in a functional manner.

The Good

• Focuses on process, not product
• Points out misconceptions about open-source development
• Provides modern-ish examples of open-source communities and sites

The Bad

• Spends a long time mulling over graphs of estimated numbers of Linux users
• Spends a bit too much time on software-development in general (not open-source specific all the time)
• Generally a bit too verbose at times

I’m still wondering…

1. What does a failed open-source project look like and how does it work?
2. How does a project transition into open-source development?
3. What do current open-source trends say about where the movement is going?

What I think…

This chapter is pretty well-written. If you’re curious about open-source development, read it now. Seriously, stop reading this review and read the chapter.  It starts chronologically, getting into the history of Linux and continues to reference Torvalds periodically throughout the chapter.  This works well, as he set a fine precedent for open-source developers in both practice and temperament.

After that, Weber starts knocking out topics one-by-one.  He covers the fundamental problem that open-source sets out to solve, and does a good job of providing examples and principles to simplify his explanation.  He can get a bit caught up in explaining software development as a whole, which may bore those already familiar with that.  However, that’s better than not explaining enough.

Another good title would be “The Open Source Process Explained.”  He frequently answers the question of “How does an open-source team deal with/do _____?” which is very helpful no matter what type of software you’re willing to develop.

Overall, this is a great entry point to learning about open-source development.  Read this if you’re curious at all about it.

In short: 5/5 (Awesome)