Open-source platform vs open platform

Today there are an increasing variety of platforms available on which to build innovative new products. It seems like every other day, there's some NewFangled.js framework or Fansy new language getting put up on Github and rocketing in popularity due primarily to its touted openness. It's good that we have such a rich variety of great technologies to choose from, but sometimes I feel like there is too much weight put on the "open-sourceness" of the various platforms. There's this widespread assumption that open-source implies good platform, but that's not necessarily true. For every popular open-source platform, there are many other unpopular open-source platforms that don't receive anywhere near as much attention, and therefore don't really get anywhere. So it's not the open-sourceness per se that makes a platform really great.

Nor is it always the case that a closed-source platform is bad. There's seems to be another widespread belief, especially among Valley entrepreneurs, that closed-source is somehow "evil". Maybe it's the lack of collaboration, maybe it's the inability to make changes to the platform. Yet there are some shining examples where closed-source platforms still manage to be widely used: iOS, .NET, and J2EE come to mind, just to name a few. Love them or hate them, you can't dispute their popularity.

So what is it that makes a platform really great? For me, it's the platform's ability to get me going with a project quickly and to then get the project out freely. That's the key: getting it out freely, and this is what I mean by open platform. When I have to submit my project for review by some third party before it can ever see the light of day, that's not good. It doesn't matter that the platform used is open-source or that my code is on Github. The only thing that matters is that my application complies with someone else's nebulous terms of service, and that's bad. At any given time, my project can be removed and I can be banned. I'm not free to innovate to my full potential. To me, it's much more important that I have this kind of freedom than the freedom to change the underlying platform around to suit my needs. I can work around that by adding layers, glue, or other abstractions. But I can't get around the fact that my application needs to be reviewed. Why did the open platform approach work so well for desktops, yet so terribly for mobile? And no, Android doesn't count as an open platform. It's just open-source.

Does a great UX thwart collaboration?

Shortly after posting my last entry about the goodness of .NET, I read some other great entries about how the things I glorified were precisely .NET's flaws. It got me thinking about how a great design and a collaborative development process in general are inherently at-odds with each other–they are opposite extremes of a continuum. To illustrate, I'd like to use the .NET framework once again as a case study.

A friend of mine put it very nicely: in C#, you code at the speed of thought. There is very little standing in the way between you and the problem you're solving; all of the other stuff like memory management or configurations are neatly abstracted away from you and you get to play in the sandbox Microsoft provided for you. Everything is beautiful in this sandbox, and coding is super easy and super fast. So what's the problem?

Well, there's two actually:

1. There is a lower barrier to entry because everything is so simple, so the .NET framework sees a higher percentage of grunt, code-monkey, 9-5 developers than other frameworks. These are the people who simply memorize Microsoft's versions of all the abstractions without really understanding the problems the abstractions are solving, and they don't really understand how those abstractions work. A good developer must understand why the abstractions (s)he's using exist, and should at least be able to imagine implementing them*. I've seen too many .NET developers who don't have this understanding and end up posting exactly the kinds of questions on forums that leave you wondering if they even know what they're talking about.
2. Very few engineering-minded people have a great sense of UX, so even if a good developer offered a FOSS abstraction for .NET, the result would probably be a very complicated/convoluted API that's frustrating to use (sounds familiar?). The effect is further amplified by the number of people collaborating on the API. It's just very hard to get things right without any central leadership. (This lack of UX goodness is my main personal gripe with open source software in general, there's no visionary leadership directing its future; design is not a democracy)

Both problems (but especially the second**) lead to an attitude among .NET developers of "well, let's wait for Microsoft to do it for us." There is little incentive to do it yourself because even if you did, Microsoft would make a way better version of it once they get around to it and completely trump your version. This is the reason there's little collaboration in the .NET community. It is absolutely NOT because the .NET framework is somehow lacking in power or customizability, or is otherwise difficult to build things with. Frankly, I think it's one of the best platforms on which to build things. There is little collaboration simply because Microsoft sets a very high bar on what you should expect from the .NET framework, and when you compound that with the problems above, very few people are actually motivated to create things and share them with the community for fear of wasting their time once Microsoft addresses the same issue themselves. Is it a bad thing? Depends how you're reading "it" in that question. If you're reading "it" as "the lack of collaboration", then yes, it's bad. If you're reading "it" as "the great UX of the framework", then no, it's not bad. For better or for worse, they're two sides of the same coin.

I'm interested in learning of some FOSS development platforms that you found to be absolutely beautiful and satisfying to work with, and I'm also curious to hear about instances when .NET has miserably failed as a platform for you, so leave some comments and share your thoughts.

* I don't have the hard requirement of necessarily being able to implement them outright. Some abstractions are actually huge and take a team of people to develop. But you should at least be able to picture what such an implementation would involve and be able to explain the various use cases–that's what I mean by "imagine implementing them".

** Hell, maybe the effect of the second problem is so strong that the first problem doesn't matter. In fact, maybe I'm unfairly assessing .NET developers and the first problem isn't even true. Let me know in the comments.

Why Leaving .NET is Hard

A while back I read a very interesting blog entry about a developer who got fed up with the .NET developer community and posted an excellent critique of the environment. He has many valid points and correctly points out its deficiencies. However, there are two sides to every coin, so as a (former) .NET developer, allow me to explain the other side.

First, a disclosure is in order: I am an Apple fanboy. There, I said it. I'm as stubborn as they come, and I refuse to consider any other hardware or consumer software. I'll try to avoid ranting, but the tl;dr of it is that Apple focuses on the user experience and they have some of the best talent on the planet working on it. No other vendor does this. Instead, other vendors focus on packing the most tech in as cheap a package as possible, often resulting in shoddy, overheating/underpowered junk that's cumbersome and frustrating to use.

Why is this disclosure necessary? Well, notice how I said hardware or consumer software. That's an important distinction. As a developer, I've gotten to use the various tools and frameworks out there and I have to say that hands down Microsoft makes them the best. So, another full disclosure: I am also a Microsoft development fanboy. Do I wish there was a more vibrant, collaborative, and open community? Of course. But I gotta say, every time I step out of the .NET "bubble", I'm disappointed. Other than Java (which I'll critique later), there are generally two scenarios I find myself in when I start looking through source code and working on a project outside of .NET, neither of which are particularly pleasant.

1. There are all these magic strings and magic typeless variables held together by magic bash scripts and magic commands that have me delving into countless man pages just so I can familiarize myself with all the -parameters. Didn't work? Oh, yeah, that's because you didn't pass the -o -m -f -g options to the "wtf" command before running the "rebuild.all" script. And don't forget to sudo it.
2. The environment is generally no better than in the last scenario; it's loosely held together by magic scripts and makefiles. Everything is defined twice, each in a different place (h and c(pp)), because clearly they hadn't thought of compiler inference when the language was invented. There are yucky preprocessor directives at the top which define hideous #imports and MAGIC_MACROS. The code itself is covered in sweetgum balls: prickly eye-sore asterisks which make the code hard to follow. Much of the meaning of the code is obscured by low level, arcane memory management or bit-twiddling, miserly optimizations. Half of the code deals with this crap rather than the problem at hand. Rarely is there a pressing enough need for those last few ounces of performance-gaining contortions to make the code manageability worth sacrificing. It's 2011 people, use a garbage collected language and stop being your own janitor!

Enter the .NET experience:

1. Install the latest edition of Visual Studio (there are even free versions).
2. Open whatever project you need to work on.
3. Done. That's it, it's that simple. Start debugging in the excellent debugger.

Here you may be thinking that the Java experience is similar.
It's not.
Java is a hideous language and I have yet to find a truly great IDE for it.

Most Java IDEs are rather cluttered and sluggish compared to VS (maybe because they were written in Java?), but that's not the worst of it: they’ll all install just fine without an actual version of Java configured for your project. Out of the box, your code will probably not compile because you have to know to pick a version of the JDK for your project. That step is for you to figure out. Things not working out of the box is a huge detractor in terms of first impressions. I've come to learn that it means that I need to brace myself for sysadmin-style work, because now before I can code I have to learn how to deal with the inner workings of the thing I'm using to code.

And even just looking at the Java language itself, it leaves much to be desired. It’s as if the people over at Sun (or Oracle?) put a fresh coat of paint on C++ 10 years ago and let all their language developers take an indefinite leave of absence. They then realized that there were still big things missing in Java, but without the language guys around they were forced to start ad hacking things like preprocessor-style annotations instead of more elegant constructs like attributes, auto (un)boxing of primitives for generics instead of just allowing primitives, no extensions, forced exception handling, and don't even get me started on the lack of functional-style constructs like list comprehensions or lambda expressions. .NET has all of these things in your choice of Basic, C++, C#, or F#, depending on what language style you prefer, and they all come preinstalled with VS and they all work out of the box. And the debugger in VS is the best one I've ever seen. It's not any one feature of the debugger that makes it better, it's just better polished than other debuggers I've seen… Try it, you'll see what I mean.

At the end of the day, we developers are also users, users of our development tools. Like Apple, Microsoft focuses on the user experience first and the tech second. The programming languages they make (notably C# and F#) are very innovative, with features that don't exist in any other mainstream typed languages that I've seen. Being typed here is important: I understand the pains of having a strict type system and the appeal of an untyped environment like RoR or PHP. The added burden of types has never been worth it to many developers, especially on the web where structure and behavior are very dynamic. Microsoft is working on this problem at a language level in a very innovative way. And if you really want sweetgum balls or magic typeless variables, you got it. They're still there and supported. As a bit of a language geek, I'm genuinely excited for the things planned for upcoming versions of .NET and their corresponding languages, despite likely not being an active user for quite some time to come (continuations for asynchronous code ftw!). I honestly can't say the same thing about any other language.

Are you a recent .NET departee? Do you miss it, or is it the best decision you've ever made? Other thoughts? Do tell.

The Importance of UX

I took a look at the recently announced Windows Mobile 7, and I'm so glad to see that Microsoft is finally taking UX seriously. They're only about 3 years and 53 days too late, but better late than never (a virtual pat on the back to whomever figures out the significance of that timespan).


What's UX?
UX stands for User eXperience. It doesn't just mean the look and feel of the application, it means everything: from the moment the user first sees the application to when the user finishes the task at hand and quits. Was it inviting? Did it perform the job quickly and cleanly? Was it clear how to navigate through the application? Were all interface elements intuitive? Most importantly, would you use the application again?


Engaging the user (i.e. having a great UX) is key to an application's success. Twitter is a perfect case in point: it has grown rapidly to be the leading micro-blogging technology out there, and it still doesn't have a well-defined business model. Have you ever wondered how Twitter makes money? They have some ideas, and as of late they may be in the early stages of finally getting some kind of cash flow, but there's still technically no revenue. Yet ironically, it employs over 100 people and is backed by investors. They focus so much on the UX that they refuse to put ads on their site. They would make a fortune, mind you, but they just don't want to ruin the UX with flashing banner ads. So how do they keep from going under? Well, millions of people find value in Twitter. That's why people are willing to use their service, that's why people are willing to work for them, and that's why people are willing to invest in them. They realize that there is some value in the application.


Some venture capital firms say that they would rather fund an application that is generating and keeping a user base without an obvious revenue model (notice: obvious revenue model, not no revenue model) than the other way around. The reason for this is pretty simple. If the application doesn't generate and keep it's users engaged, then nobody is getting any value from the application--it isn't valuable. As long as the application has value to its users, somebody will pay for it. Perhaps not the users themselves, it may be some company interested in the data that the users produce, but nevertheless, somebody will pay.


There's more to be said and plenty of examples out there, so stay tuned for more.