I hate to hang on Mark’s every word, but some­thing he said is STILL both­er­ing me. Since the class videos still aren’t up (cap­stone team or Can­taloupe respon­si­ble?), I’ll try my best to para­phrase what Mark said dur­ing class:

Open Source just isn’t prof­itable. I don’t like it. You’re not going to find a lot of com­pa­nies out there that are prof­itable after maybe Red Hat.

I don’t think Mark could have been more mis­in­formed or incor­rect in his state­ments. Try googling “open source isn’t prof­itable” and then “open source is prof­itable” and see what kind of results you get. My results were all pro open source prof­itabil­ity and one arti­cle stat­ing that “Microsoft SharePoint-based Solu­tions: More Prof­itable than Open Source” (typ­i­cal) Here are some of the other head­lines that came up:

If you haven’t already, go see Rev­o­lu­tion OS and learn why open source is not only impor­tant but bet­ter. When I tweeted about what Mark said on Mon­day, it was very fit­ting that my first reply was from an entre­pre­neur who has moved from Bloom­ing­ton to the Sil­i­con Valley.

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

First Response: @maxbeatty exam­ple #471 of why we left the Midwest

The real prob­lem I have is that a class focus­ing on entre­pre­neur­ship in infor­mat­ics (read: Indi­ana) comes out and says,“Open Source isn’t prof­itable so don’t start a busi­ness based on it”, but at the same uni­ver­sity where the class is taught, only Open Source lan­guages are taught to under­grads. Dur­ing my time at IU, I’ve had classes in C, Perl, Scheme, XML, MySQL, HTML, CSS, and some JavaScript — all open source and open stan­dard lan­guages. I know other infor­mat­ics under­grads have had classes in Python, Java, and recently Pro­cess­ing. Even the cap­stone projects of the school of infor­mat­ics focus on open source technologies!

If pro­pri­etary lan­guages like C#, .NET, and SAP are such cov­eted skills, why am I along with the rest of my class­mates not being prop­erly pre­pared for the real world? My room­mate is cur­rently in the MSIS pro­gram of the Kel­ley School of Busi­ness and he is learn­ing C#, .NET, and SAP. Does that mean you have to grad school before you really know anything?

If Mark is right, the uni­ver­sity and school of infor­mat­ics are wrong. If Mark is wrong, what hap­pens to his cred­itabil­ity with the class? There’s always the fall­back argu­ment that a mix of pro­pri­etary and open source solu­tions is prob­a­bly best, but either way such blan­ket state­ments as “open source isn’t prof­itable” should stop unless you can back it up. The floor, which hap­pens to be Word­PressMU that’s coded in PHP that runs on an Apache web server that’s installed on a server run­ning Red Hat Enter­prise Linux, is open (source) for you, Mark.

On to this week’s questions:

1.  As a com­pany grows, why might some­one that was suc­cess­ful and engaged in the busi­ness become less suc­cess­ful and disenfranchised? With that in mind, what would be an impor­tant trait of some­one going to work in a small company?

Peo­ple change, lose inter­est, or are replaced by some­one else bet­ter fit for the job. Greg Oden was great in high school, pretty good in col­lege, and now hasn’t played any sort of sub­stan­tial roll in the NBA. This could very well directly cor­re­late with his engage­ment with bas­ket­ball. At each new level, bas­ket­ball became less impor­tant to Oden as other respon­si­bil­i­ties like celebrity sta­tus and busi­ness deals took over. If a coder comes into a com­pany lov­ing to code and puts out great code, he’s prob­a­bly going to earn a pro­mo­tion that may or may not take him away from what he loves– cod­ing. If he’s in the cor­ner office bud­get­ing expense reports he has no idea about, he’s not going to be suc­cess­ful or engaged.

An impor­tant trait of some­one going into a small com­pany is know­ing their roll. Do they code, design, or man­age? If they can code and man­age, they should man­age coders. If they can only design, they should stick to design­ing until their skill set expands to man­age or code. Until then, they should know their roll and keep to design­ing. If they can’t expand their skill set, they prob­a­bly aren’t going to be very suc­cess­ful because they can’t adapt to change.

2.  When hir­ing early mem­bers and/or part­ners to the team, what are two impor­tant things to think about?  How would you ensure that those are thought about?

Early mem­bers and/or part­ners to a team should have a shared vision of the project and have com­pli­men­tary skills. If every­one isn’t on the same page, they can’t progress at the pace they need to. There are surely going to be dif­fer­ences along the way, but everyone’s descrip­tion of the “big pic­ture” should be in the same ballpark.

Hav­ing every­one on the same page doesn’t require every­one to be clones. In fact, it is best if the team’s skills com­pli­ment each other in order to max­i­mize poten­tial. For exam­ple, if you have two peo­ple who do great back­end devel­op­ment but nei­ther does fron­tend devel­op­ment, you aren’t max­i­miz­ing poten­tial. Instead, hav­ing one back­end devel­oper and one fron­tend devel­oper would allow you to put out a com­plete prod­uct unlike the last com­bi­na­tion. Ide­ally, the smaller the team, the less over­lap­ping of skill sets.

3.  When a man­ager hires into a spe­cific role, what is a com­mon mis­take and how might one avoid it?

A man­ager in too spe­cific of a role may want to branch out and thus ignore his ini­tial respon­si­bil­i­ties. Being new to an orga­ni­za­tion and their def­i­n­i­tion of roles may also be hard to adjust to. Instead of bust­ing in on a new scene and try­ing to be a hero, it’s often bet­ter to lay low and take notice of your sur­round­ings. Once you under­stand your set­ting, take action.