Dimebrain

Development   Speaking   Open Source   Public Domain   Twitter   

Dimebrain is a web development company using .NET technologies to give you an unfair advantage online.

August 9, 2010 at 2:23pm

Nothing has changed, and nobody’s happy

In the last few weeks, Microsoft has shipped WebMatrix and LightSwitch, and further de-emphasized the efforts of IronRuby. This has caused a noticeable uptick in .NET developer anxiety and anger, at least in those who have taken it upon themselves to pursue development by taking cues from other thriving software ecosystems, and to do so loudly.

I don’t think many folks can argue that there is something good about generating interest in software development and providing a path to early productivity for budding developers. But it can, and does, get out of hand. This has happened before with sunset projects like Popfly, whose literature openly promoted the notion that anybody can program, with titles like “Microsoft Popfly: Building Games Without a CS Degree” and the professional developer community on the Microsoft stack normally respond unfavorably to these efforts, citing marketing zeal for the non-programmer or hobbyist.

What I haven’t seen before is the size and consistency of the message that professional developers don’t feel like Microsoft wants them in their community. To wit is open source colleague @jdiller: ”Microsoft has been doing a good job lately in reassuring me that my recent job change out of their ecosystem was the right move”. There are plenty of others making the same observation.

I don’t think it’s navel-gazing so much as Microsoft leadership being completely fascinated by, perhaps since inception, with the automation of software processes and the deconstruction of engineering rigour into pure magic. In other words, “you can do X, without writing a single line of code!” has enjoyed a long run within its walls.

Computer science’s long battle with complexity, perhaps (and hopefully finally) lost just this week with a new proof of P != NP making the rounds, has always been in love with the idea that we can form a description of a problem that’s sufficient to solve the problem itself. In isolation, any programmer with something to prove will invariably flirt with what is essentially the programming equivalent to the perpetual motion machine

Perhaps the isolation is the problem. Another common sentiment of those who would see Microsoft succeed but only through a heavy course of tough love explain that Microsoft’s developer teams suffer from terminal “Not Invented Here” (NIH) syndrome. This means that despite the high availability of existing (and usually open source and free) solutions, Microsoft wants to create their own rather than adopt, acquire, or support the most promising variant.

There is an obvious commercial advantage here, since many Microsoft customers will only use Microsoft supported solutions, despite competent and free alternatives. Microsoft’s customers are quite literally asking for them to do this. It would appear that these same customers do not listen to their developer teams, if they have them, or appreciate that they share their desires to create better software faster.

Outside of marketing there are good reasons to develop a solution amidst available alternatives, and one of the most respected is that the current alternatives are inadequate to the task. This is a valid reason because it implies that the creator of the new solution has dealt with the complexity of the problem head-on, evaluated the state of the art, and found that it came up short. 

Unfortunately, the re-invented solution from Microsoft often displays a demonstrable naivety compared to the existing marketplace. In fairness, this has nothing whatsoever to do with the capability of the developers actually building the software, but everything to do with the complexity of the problem. Usually, the first version of a Microsoft product resembles, at least in spirit, the first version of the competing solution. The difference, is that the competitor already has the years of experience and struggle and hard-won understanding with the problem baked into the shipping code.

I can’t help imagining the end of a conversation that begins one of these projects: “We can do this better than the other guys. Our customers won’t have to worry about relying on scary, risky open source, we’ll support them every step of the way. And our customers’ developers will be delighted. They can accomplish this task without writing a single line of code!”. This conversation could not occur in good faith if there was a true understanding of the complexity of the problem at hand, but the proof of that only shows up much later in the product itself.

The dance of dissent begins and goes something like this: developers in the community decry the Microsoft version of a solution, calling it vastly inferior to existing open alternatives, Microsoft developers who built the product take it personally, as anybody would, and defend that it’s only the first version which will improve over time, some claims to accepting and acting on feedback are promised, and everybody eventually goes back to their desks.

But because complexity seems to be a bad word in the Microsoft culture, we find ourselves at the same crossroads over and over again. Today we face another manifestation of our worst fear as professional developers, and balk at a company whose central theme is, and has nearly always been, the mass commoditizing of the practice of software development, all in the interests of making complexity disappear, like a bad rabbit trick, rather than acknowledging its existence and helping to manage it rather than ignore it.

I find it surprising that we are consistently surprised by something you can almost set your watch to. It’s not as if we haven’t seen this before, that we won’t see it again, and that the solutions we have today, right now, aren’t as viable as ever.

The gorilla in the room? The rest of the world doesn’t need a vendor guarantee that their software will work to make it work for them. Great companies are building great products on supposedly inferior and fragile open source technologies when compared to vendor-supported software. Open source companies trade up to recent revisions to stay relevant, vendor-supported companies upgrade their purchases. The difference, other than the sunk cost, is literally non-existent.

August 2, 2010 at 12:28pm

Projects vs. products

Over my short career I have worked on several open source projects as contributor and creator, and throughout it all I couldn’t shake the feeling that there was something uncomfortably out of place, that stewardship of open source software in the .NET community wasn’t nearly as rewarding for all concerned as it could be, or already was, in other software communities.

I think this is what I’ve learned: when we treat our open source software like products, we create product expectations.

When we have a product we get customers. Customers are not the sort of people who are out to help themselves, by definition. You are there to help them because they are entitled to it. Customer’s don’t contribute, and open source at a certain point must rely on contributions to survive.

Normally customer entitlement is earned by paying money. In this case, while no money has changed hands, your marketing message (and you do have one) has promised customer-like treatment. This is accomplished through public code comments, tutorials, wikis, blogs, et al. You are creating this marketing collateral and at the same time reinforcing the notion that there is a proprietor-customer relationship at work.

Perhaps the reason this mentality has such safe haven in our particular community is because we exist in a proprietary world, regardless of how much it has evolved since its beginning and what alternatives exist today. We’re used to being provided with source code and libraries because we are customers in the Microsoft universe. It’s hard to change that mindset when someone else is providing you with code while at the same time claiming active support and giving you a place to make requests.

Our community is further incentivized by a tacit reward system for those who contribute to the developer community: the coveted Microsoft MVP award. This distinction provides the developer with what essentially is early access and dialogue with Microsoft’s own developer teams, and it is a great privilege.

It’s likely that this reward system is perceived as fair payment by many open source consumers, who become customers rather than contributors, regardless of whether it’s related or valid. The impression is that someone isn’t creating the software for the sake of community but rather for their own individual aspirations, and communities never respond well to the desires of the individual if the group is at stake. In a proprietary world it’s easy to assume this is the case.

Another interesting aspect of marketing open source is confusion on the end goal. Presumably the reason to provide a high level of support for your open source software is adoption. The more people who find your work useful, the more they will talk about it among their colleagues who have similar issues that need solving, and you’ll get more users. On the bright side, there’s lots to feel good about if you are personally motivated by helping the greatest number of people as you can.

Where this breaks down is that at a certain point, if your open source software isn’t financially supported, and most are not, despite powering some of the largest enterprises (and I assume the corporate mentality is a similar one of customer entitlement, as they already make large investments in proprietary systems, open source software written by community leaders that operate within those systems is expected) the number of users expecting a product experience will exceed your capacity to support them. Providing that product experience is hard work and it doesn’t scale. You need to respond to customer requests, fix bugs and regressions, and test many scenarios that you don’t personally encounter using your own work. If you happen to have created a product that didn’t arise out of solving your own real need, but rather an intellectual pursuit of a problem or a perceived need, it gets worse for you, because you’ll have an even harder time anticipating the needs of a customer whose shoes you’ve never walked in.

I’m not trying to vilify the Microsoft MVP award as the reason .NET open source communities devolve from collaboration into individual agendas on the part of either the producer or the consumer. I don’t think they are truly related at all, but I believe there is a perception that all community efforts are selfishly routed, and this perception doesn’t exist in other developer ecosystems.

In the end we should see that treating open source like products is a recipe for frustration. In the business world we might call this problem “having the wrong customers”. There is plenty of room for a true community if we can break the habit of viewing our open source as having a single direction from creator-celebrity to consumer-customer, and possessing the qualities of free software products.