Not really a secret

I have already voted for Piratpartiet in the Swedish EU elections. For people who know me that can hardly come as a surprise. I just wanted to briefly talk about why I went with PP instead of MP (that I usually vote for), when they actually have the same opinions about integrity and the future of Internet. I think it can be summed up in: I wanted to make a statement. There you have it. I want people in "power" to understand that it's not OK to ignore these questions (internet, freedom, integrity), it's not OK to push through new laws (FRA, IPRED) without consequences.

I might be naive, thinking that voting for PP is a "consequence" for the sitting parties. At least it seems like most politicians seems to understand that they have to tackle this question these days, that's a start.

Let's keep internet FREE, as in speech.

Apple: Be more transparent!

Apple is a very secrative organization, they value their secrecy because it builds up a hype around the products. I love Apple products, I am what most people call a Apple fan-boy. But I think recent events regarding the App Store aproval process must be addressed in a negative fashion.

I love the fact that Apple have created great development tools for the iPhone and they have done so for free. This have given the iPhone eco-system a great boost and in less than a year they have succeeded in creating a development community that it’s competitors haven’t succeeded with yet.

I really believe that the App Store is a big reason for the success, all applications gathered and easy to browse / search. But the App Store is also the big sign of weakness in the iPhone eco-system. As you might already know, Apple is the gatekeeper for everything going into the App Store to make sure that “malicious” and “offensive” applications stay far away from the iPhone. While this makes sense (you don’t want viruses spreading via the App Store) in some ways the big problem is actually that Apple have so far refused to share any details on the approval process.

This creates big problems, not only because it’s hard for developers to know if their application will ultimately be accepted or not, but also because currently it seems like the process is very random, some of them have gotten a lot of attention. The latest application that have gotten the metaphorical cold hand was Nine Inch Nail own application. The application was actually first accepted (and put on the “featured” page in App Store), when NIN then submitted a minor update it was rejected because of “objectionable content”.

Probably this occurred because different people reviewed the first submission and the update. This really makes the flaw in the process really apparent, the developer can never trust the Apple approval process. If this continues I wouldn’t be surprised if small indie developers think twice before they start develop iPhone applications and that would really be a shame, because it will in the long run kill the community.

I think that Apple have to be more transparent, really post the guidelines that are used for the approval process or even better, small developers should be able to “test drive” their idea and get a pre-aproval. That would make it easier for the small developer to justify the investment they need to do to create a iPhone application.

Maybe another solution would be to “do a Maemo”. Maemo have a staging area called the “garage” where third party developers can upload basically anything they want, users needs to manually install them. This would allow Apple to review applications for the App Store, but applications that are deemed “offensive” can still be installed on willing users iPhones.

Please Apple, don’t destroy a good thing you have going on here, a free SDK was a great idea, the App Store was a super idea as well but your approval process can throw it all overboard. Be transparent, let the developers in on the secrets in this case.

Open Source is about Participation

As I have talked about earlier I am holding an education for company management about Open Source Communities. Since I can't release the slides directly I am going to blog a bit about what these slides contain.

One of the things I am trying to get across the table is that getting involved in a Open Source Community as a company is hard work and often counter-intuitive to old business practices. To illustrate this I have created some case studies about companies that have tried to involve them-self in the community and the different outcomes of that. In my examples I use Nokia, Apple, Google and Sun as examples (and some more of them), all these companies are interacting with the Open Source community in different ways. All of these companies have both succeeded and failed with their interactions (I won't comment on the individual cases in this blog post, but I am still interested in your feedback, what do you think about the companies listed above and do you have other examples of companies failing or succeeding with Open Source?).

While I was researching these different companies (most of my research was based on google searches like "opensource at X") I ran across Sun's Open Source webpage, this page states that 'Open Source is about Participation'. I think that is one of the most accurate one-liners about Open Source I have ever heard. In order to be able to accepted and successful with a Open Source Community you must show that you can participate, create code and work together with the community with it rules.

I think very few Open Source Communities would accept companies that tries to 'buy' their way into gaining influence over a certain project. But companies that can send relevant, well written patches that implements a feature or fixes a bug in a project they are using can succeed. Many nerds just care about code and that is the way it should be.

Interacting with a Open Source Community is not like interacting with business partner, few communities will implement features that they don't like just because your company needs it. Many community volunteers have a lot of pride invested in their projects and will place code-style and technical aspects before the needs of their end-users. This is very different from how a company works, because companies needs to see to the user needs before the technical aspects of the actual code (this might actually explain why most proprietary code is such a mess - "We need this now, or else!").

This means that companies have to care about things like this when they are contributing to Open Source projects, otherwise they might never get their patches merged.

So to sum up, if you want to gain the trust of a Open Source Community, participate and show them the code!

Open Source Community Eduaction

Purple Scout was contracted to do a Open Source Education a while back. The customer wanted a education that gave them the history, business and legal aspects, but they also wanted a section with some "real life" stories, from someone that have worked in a Open Source community already. While both my bosses handled the business and legal aspects I tackled the community section.

After almost a month of preparation, we held the pilot in front of a smaller group today. I was a bit nervous at the start but managed to hold a very engaging talk about the different inner workings of a community and a generalization of what drives open source hackers. It was a fun and interactive group that I managed to provoke a couple of times :-)

I would love to share the slides I did, but unfortunately they contain some information that I can't spread, therefore I will try to blog a bit about the conclusions that I managed to draw from all of this.

Also a question: What do you people think is the driving factor for participating in open source communities as a company, i.e. not for you personally, but what would drive your company to work with open source?

Sony Reader PRS-700

I got myself a Sony Reader PRS-700 the other day. Imported from the USA of course, since we can't get fancy things like that here in Europe. Actually I am evaluating this unit for some friends and co-workers so they know what Reader to buy later.

So far I must say that I am impressed. I have been using it on my weekly trips back and forth to Malmö and more or less left all my books at home. The built-in light is pretty slick, I can actually read books in bed without disturbing my lovely fiance.

A word about the display, a lot of people hate it because it "glares", my guess is that these are the same people that "can't" use a glossy macbook either. I on the other hand have never had any problems with it. So I will continue to read my books digital going forward, no more big books that weigh a ton in my backpack.

Google Summer of Code 2009

XMMS2 got the good news again! It feels awesome, not only because we get to participate in this fantastic program once again, but also the prospect of going to a mentor summit later this year is awesome :-) Thanks Leslie, you know we love you! ;)

But, I heard someone whispering that our proposed projects was less interesting this year! Let's do something about that! Do you have a good idea? File it at our wiki, TODAY! :-)

Official XMMS2 client should be written in Qt!

I read the that theefer did the other day and I just wanted to voice out my opinion about the Official client. I don't doubt that all people in the XMMS2 community probably already know my position about this, but I wanted to make it perfectly clear!

I think the official XMMS2 client should be written in the Qt toolkit and these are my reasons for it:

1. Qt works natively on all the platforms that XMMS2 runs on. More important, it actually looks good on all the platforms that XMMS2 runs on. It even looks good under GNOME these days.
2. The Qt API is very clean and easy to use.
3. You can write Qt applications in C++, Python or Ruby (see my language discussion further down).
4. Qt bundles with QtScript, which is a ECMA compliant language, which means that we can extend the official client in QtScript. This means a very low entry-level for people that want to add functionality to our client. QtScript is (IMHO) not fast enough to be the sole language we should use, but that might change soon.
5. Upcoming features like QtKientic will bring awesomeness to our client.

I also think that the base client should be written in C++, but supported by QtScript. First we had the idea that we should write the whole client in QtScript, just have a small C++ loader. I have researched this possibility but I don't think QtScript is ready for that. QtScript is slow, and you need the qtscriptbindings to bind the full Qt API to QtScript, that takes 2 hours to compile on my master macbook pro.

Writing the application in Python or Ruby would probably be more rapid than writing it in C++, but it will be a bigger pain to deploy. Qt/C++ is easiest to deploy because all the tools are already there and users don't have to install yet-another-lib. My second choice would be Python, mostly because I know Python, I don't know Ruby :)

How about xmmsclient bindings?

The last thing I would like to touch is about xmmsclient bindings. Right now I have Qt4 bindings that are native, that means that it doesn't use libxmmsclient beneath, they are not merged into the mainline, but could be found here. I think these bindings could be a good candidate to use in the client, but we would need to make it complete and merge it into XMMS2 first.

See this post as a material for discussion, I would love to hear your opinion. Let the flames rain!