I hate to hang on Mark’s every word, but something he said is STILL bothering me. Since the class videos still aren’t up (capstone team or Cantaloupe responsible?), I’ll try my best to paraphrase what Mark said during class:

Open Source just isn’t profitable. I don’t like it. You’re not going to find a lot of companies out there that are profitable after maybe Red Hat.

I don’t think Mark could have been more misinformed or incorrect in his statements. Try googling “open source isn’t profitable” and then “open source is profitable” and see what kind of results you get. My results were all pro open source profitability and one article stating that “Microsoft SharePoint-based Solutions: More Profitable than Open Source” (typical) Here are some of the other headlines that came up:

If you haven’t already, go see Revolution OS and learn why open source is not only important but better. When I tweeted about what Mark said on Monday, it was very fitting that my first reply was from an entrepreneur who has moved from Bloomington to the Silicon Valley.

My Tweet: Mark Hill doesn’t like Open Source and thinks no one profits from it. I know what I’m blogging about this week for his class!

First Response: @maxbeatty example #471 of why we left the Midwest

The real problem I have is that a class focusing on entrepreneurship in informatics (read: Indiana) comes out and says,”Open Source isn’t profitable so don’t start a business based on it”, but at the same university where the class is taught, only Open Source languages are taught to undergrads. During my time at IU, I’ve had classes in C, Perl, Scheme, XML, MySQL, HTML, CSS, and some JavaScript – all open source and open standard languages. I know other informatics undergrads have had classes in Python, Java, and recently Processing. Even the capstone projects of the school of informatics focus on open source technologies!

If proprietary languages like C#, .NET, and SAP are such coveted skills, why am I along with the rest of my classmates not being properly prepared for the real world? My roommate is currently in the MSIS program of the Kelley School of Business and he is learning C#, .NET, and SAP. Does that mean you have to grad school before you really know anything?

If Mark is right, the university and school of informatics are wrong. If Mark is wrong, what happens to his creditability with the class? There’s always the fallback argument that a mix of proprietary and open source solutions is probably best, but either way such blanket statements as “open source isn’t profitable” should stop unless you can back it up. The floor, which happens to be WordpressMU that’s coded in PHP that runs on an Apache web server that’s installed on a server running Red Hat Enterprise Linux, is open (source) for you, Mark.

On to this week’s questions:

1.  As a company grows, why might someone that was successful and engaged in the business become less successful and disenfranchised? With that in mind, what would be an important trait of someone going to work in a small company?

People change, lose interest, or are replaced by someone else better fit for the job. Greg Oden was great in high school, pretty good in college, and now hasn’t played any sort of substantial roll in the NBA. This could very well directly correlate with his engagement with basketball. At each new level, basketball became less important to Oden as other responsibilities like celebrity status and business deals took over. If a coder comes into a company loving to code and puts out great code, he’s probably going to earn a promotion that may or may not take him away from what he loves- coding. If he’s in the corner office budgeting expense reports he has no idea about, he’s not going to be successful or engaged.

An important trait of someone going into a small company is knowing their roll. Do they code, design, or manage? If they can code and manage, they should manage coders. If they can only design, they should stick to designing until their skill set expands to manage or code. Until then, they should know their roll and keep to designing. If they can’t expand their skill set, they probably aren’t going to be very successful because they can’t adapt to change.

2.  When hiring early members and/or partners to the team, what are two important things to think about?  How would you ensure that those are thought about?

Early members and/or partners to a team should have a shared vision of the project and have complimentary skills. If everyone isn’t on the same page, they can’t progress at the pace they need to. There are surely going to be differences along the way, but everyone’s description of the “big picture” should be in the same ballpark.

Having everyone on the same page doesn’t require everyone to be clones. In fact, it is best if the team’s skills compliment each other in order to maximize potential. For example, if you have two people who do great backend development but neither does frontend development, you aren’t maximizing potential. Instead, having one backend developer and one frontend developer would allow you to put out a complete product unlike the last combination. Ideally, the smaller the team, the less overlapping of skill sets.

3.  When a manager hires into a specific role, what is a common mistake and how might one avoid it?

A manager in too specific of a role may want to branch out and thus ignore his initial responsibilities. Being new to an organization and their definition of roles may also be hard to adjust to. Instead of busting in on a new scene and trying to be a hero, it’s often better to lay low and take notice of your surroundings. Once you understand your setting, take action.