Tag Archives: open source

open source, professional, software development

Adobe Brackets: a different type of HTML and JavaScript code editor. Interview with Adobe’s Adam Lehman.

1 Comment

On Adobe’s Tools and Services page there is an intriguing remark about the company’s plans for a code editor. “We think there’s a need for a different type of code editor – we’re working on something and will have more to share soon.”

image

That something is Brackets, a code editor written in HTML and JavaScript (which means, as with all the best tools, that you can code Brackets in itself).

Advertisement

Although Brackets is written in HTML and JavaScript, it is not yet a web application. Instead, it runs on the desktop using Google’s Chromium Embedded Framework (CEF), which lets you embed the Chrome (strictly, the Chromium) browser engine in a desktop application. In the case of Brackets, the wrapper is lightweight, the intention being that in future Brackets may be fully browser-hosted. The consequence though is that currently you need Google Chrome installed and it only runs on Windows and Mac.

The project is open source under the MIT license; anyone can grab the code from Github. Brackets also depends on another open source project, CodeMirror, which is a JavaScript editor component for browsers. I installed it on Windows and soon had it up and running. Note that you should pull brackets_app if you want to run it, as this brings down the Brackets code as well.

image

I spoke to Brackets Product Manager Adam Lehman. “This might be the first project we started with the intent of being open source from day one,” he said.

“Our general intent is that we wanted to provide an editor that web developers felt that they could own. In the past we might have built something in Eclipse, and there would have been this giant gap between the person who knew HTML, JavaScript and CSS, and then having to write a Java-based Eclipse plug-in to extend the editor.

“When we start talking to developers, they’re going back to just text editors, things that don’t do much more than edit and manage a document, and as complex as HTML and JavaScript apps are getting these days, it seemed crazy that our tools weren’t keeping up with us. So the idea was to start this project, add a little bit of our own ideas, and have the community supply their own ideas.”

But how does Adobe intend to use Brackets in its own products, and what is the business model?

“We believe there are two spaces for the editor market. There is the larger IDE, but there’s also these lightweight text editors. We’re finding that the traditional JavaScript and HTML developer, CSS developer, was heading towards the lightweight text editor and not towards the larger IDE. We don’t see Dreamweaver and Brackets as direct competitors because they service two different tastes. It wasn’t a matter of could we add a feature here or there that was going to get people to use Dreamweaver. It was that difference between our larger tool and a much lighter weight tool. That’s where Brackets come in.”

How then will Brackets tie in with other Adobe products?

“That’s the key for Brackets. We wanted to see if we could innovate in the space and we also wanted to have a common language that we could start targeting. When you say, I want to open up an editor from Adobe Edge and start coding, we needed to define what that editor would be, so Brackets would come into that.

“We’re also saying we need to do better tooling around PhoneGap. A lot of people are fine with the command line, but we want to take a step beyond that and so Brackets is the obvious place where we’ll start to build an extension where we can tie into PhoneGap Build, or extensions around the PhoneGap APIs.

“We’ve got a lot of ideas around using Brackets to bring a lot of our HTML efforts together, not only our core HTML products but also a lot of the W3C and WebKit work that we’re doing. Brackets is a great place to put tooling, that isn’t quite ready for mass consumption yet, but we could actually build extensions for something like Shaders where those people who are interested in it can get in and start playing around with it.

“The beauty of building on the web platform is that we can go wherever the web platform goes.”

Initial prototypes of Brackets ran entirely in the browser, which would be interesting for future versions of Adobe’s Creative Cloud as well as other scenarios, but Lehman said this got mixed reactions.

“While we believe that the future of development is heading towards the cloud, and the general consensus from developers is the same, we also heard that it is not ready yet. We decided to focus on a desktop version first, with the idea that towards the end of this year or beginning of next year we’ll start to supplement with other targets, whether it be in the cloud or  a tablet, or embedded in a tool like Edge,”

says Lehman. He adds that a browser-hosted Brackets could end up integrated with the PhoneGap Build site. PhoneGap Build is a service for compiling cross-platform HTML and JavaScript into mobile apps for a variety of devices.

Since Brackets is built on Google’s Chrome/Chromium platform, what are the implications for cross-browser compatibility?

“There’s two pieces to it. There’s our container that Brackets runs in, and that is running on Chromium.

“The other part is that we have this live preview system which is tied directly to Chrome on the desktop. We happened to just start with Chrome, mostly because there is a remote debugging API that’s pretty fleshed out there.

“With Firefox and Internet Explorer, it’s a little bit different. We talked to Mozilla and they’re just now starting to work on that remote debugging API and trying to get it inline with where Chrome is, so we’re expecting to hear from them in August that they actually might have an API where we can start to build that same functionality, which is our intent.

“We’ve already started engaging with Microsoft about Internet Explorer. Right now their remote debugging API is somewhat private and in the form of a COM object which is not ideal coming from a JavaScript perspective, but we’ve showed them what we’re after, and we’ve started discussion of what a remote API from IE might look like that didn’t require COM. We’re exploring those options. Those are our priorities right now.

“If we build a cloud-based version then it’s going to be a question of what browsers this is going to run in. Our intent is to run in the modern major browsers. We aren’t building anything that’s Chrome-specific, we’re doing our best to stay as browser-agnostic as we can, but we are likely to require a more modern browser. We feel it would be OK to require the latest versions of Firefox, IE or Chrome.”

I asked Lehman whether Brackets might be useful for server-side as as client-side code. He said that Brackets is focused on the client, though a community extension is under way for node.js. He adds that since Brackets is fully extendable, others may do plug-ins for languages such as PHP.

Why is Brackets at Github and not Apache?

“We have a lot of people at Adobe who work for Apache now, and we talked to them before we released Brackets. Our sense is that Apache might be too much of a turn-off for the individual contributor, who just wants to hack and fix a bug and submit it back,”

Lehman told me. Although there are external contributors, all the committers are currently at Adobe, though there are plans for adding external committers by the end of the year. “We don’t want this to be 100% Adobe controlled.”

When will Brackets get to version 1.0?

“We’re being as agile as we can. Every bit we add, it comes closer to being a 1.0 for somebody. The things that I think are missing that you would expect out of a core editor are around code-completion for CSS and JavaScript, and solid and advanced search and replace. In the web world, that’s how we refactor code. We’re hoping to drive those in by November time. But we are on 2.5 week sprints and things change rapidly.”

I also asked about plans for a mobile app version of Brackets. Lehman says that is planned for next year, though the community is working on getting a Linux version working and support for ChromeOS.

Brackets is a fascinating project on several levels. What stands out is how far Adobe has moved from being the Flash company. A few years back Adobe came up with a system for having Flash applications run on the desktop and on mobile devices: Adobe AIR. It also invested in Eclipse and came up with the Flash Builder IDE.

Now here is Adobe with an open source project for a desktop application built from HTML, JavaScript, and a third-party open source browser engine; and in place of mobile AIR it has PhoneGap.

It is a big change, most of which has become publicly known in less than a year, signalled by the repositioning of Flash and AIR versus HTML in September 2011, and the abandonment of Flash for Mobile in November 2011.

As for Brackets itself, it is well worth a look though probably not a tool you want to use for real work just yet. In a few months though, that may well change.

Postscript: Brackets reminds me of another Adobe, or rather Macromedia, HTML code editor. That was HomeSite, an excellent text-based tool that Adobe discontinued in 2009; active development ceased years before that.

google, internet, open source, software, software development

How to brew better software: The Monki Gras in London

I attended The Monki Gras in London yesterday, a distinctive developer event arranged by the analyst firm RedMonk.

This was not only a developer event, with the likes of Andre Charland and Dave Johnson from the PhoneGap team at Adobe, Mike Milinkovich the executive director of the Eclipse Foundation, and Jason Hoffman with Bryan Cantrill from cloud services (and Node.js sponsors) Joyent. It was also a serious beer event, complete with a range of craft beers, a beer tasting competition with nine brews to try, and a talk plus a free book from  beer expert Melissa Cole. An unusual blend of flavours.

image

In charge of the proceedings was RedMonk co-founder and all round impressario James Governor. I am a big fan of RedMonk and its developer-focused approach; it has been a fresh and heady brew in the dry world of IT analysts.

image

The Monki Gras did seem like an attempt by a regular IT conference sufferer to fix problems often encountered. The Wi-Fi worked, the food was fresh, unusual and delicious, the coffee was superb; though brewing good coffee takes time so the queues were long. Not everything scales. Fortunately this was a small event, and a rare treat for the couple of hundred or so who attended.

That said, there were frustrations. The sessions were short, which in general is a good thing, but left me wanting more depth and more details in some cases; we did not learn much about PhoneGap other than a brief overview, for example.

Nevertheless there was serious content. Redmonk’s Stephen O’Grady made the point succinctly: IT decision makers are ignorant about what developers actually use and what they want to use, which is one reason why there is so much dysfunction in this industry. Part of the answer is to pay more attention, and several sessions covered different aspects of analytics: Matt LeMay from bitly on what users click on the Web; Matt Biddulph (ex BBC, Dopplr, Nokia) gave a mind-stretching talk on social network analysis which, contrary to what some think, was not invented by Facebook but predates the Internet; and O’Grady shared some insights from developer analytics at RedMonk.

I had not noticed before that github now gets nearly double the number of commits than does Google Code. That is partly because developers like git, but may also say something about Google’s loss of kudos in the open source developer community.

Kohsuke Kawaguchi, lead for Jenkins Continuous Integration and an architect at CloudBees, spoke on building a developer community. His context was how Jenkins attracted developers, but his main point has almost limitless application:  “Make everything easy, relentlessly.”

Something I see frequently is how big companies (the bigger the worse) place obstacles in front of developers or users who have an interest in their products or services. Examples are enforced registration, multiple clicks through several complex pages to get to the download you want, complex installs, and confusing information. It all adds friction. If the target is sufficiently compelling, like apps on Apple’s app store, developers will get there anyway; but it all adds friction, and if you are not Apple that can be fatal.

The Joyent guys did not speak about Node.js, sadly, but rather on the distinction between a VP of engineering and a Chief Technology Officer. Sounds dry and abstruse? I thought so too, but the delivery was so energetic that they were soon forgiven. Hoffman and Cantrill moved on to talk about management antipatterns in the software industry, prompting many wry nods of recognition from the audience. “It is very hard for middle management to add value,” said Cantrill.

Milinkovich made the point that the most valued open source projects generally make their way to a software foundation; PhoneGap to Apache is a recent example. He then gave the talk he really wanted to give, noting that as new software stacks emerge they have a tendency to re-implement CORBA, a middleware specification from the Nineties that tackled problems including remote objects, language independence, and transactions across the Internet. CORBA is remembered for drowning in complexity, but Milinkovich’s point is that the creators of exciting new stacks like Node.js should at least research and learn from past experience.

Milinkovich also found time to proclaim that “Flash is dead, Silverlight is dead, browser plugins are dead.” Perhaps premature; but I did not hear many dissenting voices.

I tweeted the conference extensively yesterday (losing at least one follower but gaining several more). Look out also for a couple of follow-up posts on topics of particular importance.

development, linux, open source, php, software development

Top languages on Github: JavaScript reigns, Ruby and Python next

I cloned a github repository today, and while browsing the site noticed the language stats:

image

Git was originally developed for the Linux kernel and is mainly for the open source community. I was interested to see JavaScript, the language of HTML 5, riding so high. PHP, C and C++ are lower than I would have guessed, Ruby and Python higher.

Here are some figures for the venerable Sourceforge:

Java (7,163) 19%
C++ (6,449) 17%
C (4,752) 13%
PHP (3,521) 10%
Python (2,694) 7%
C# (2,481) 7%
JavaScript (2,011) 5%
Perl (1,138) 3%
Shell (757) 2%
Visual Basic NET (688) 2%
Delphi/Kylix (581) 2%

This comes with a health warning. I have taken the figures from the what you get if you browse the directory and drop down Programming Languages; but the total is only about 37,000, whereas Sourceforge hosts around 324,000 projects. I am not sure what accounts for the discrepancy; it could be that language is not specified for the other projects, or they are dormant, or some other reason. But I hope the proportions indicate something of value.

Github is madly trendy, and Sourceforge ancient, so this tells us something about how open source activity has shifted towards JavaScript, Ruby and Python, and away from Java, C/C++ and C#.

Of course the overall picture of programming language usage is quite different. For example, you can get some kind of clue about commercial activity from a job board like indeed.com, which currently has 77,457 US vacancies for Java, 22,413 for JavaScript, and only 5030 for Ruby.

Nevertheless, interesting to see what languages developers on Github are choosing to work with, and perhaps an indicator of what may be most in demand on the job boards a few years from now.

Finally, looking at these figures I cannot help thinking how short-sighted Microsoft was in abandoning IronPython and IronRuby back in 2010.

adobe, professional, software development

Adobe: no new features for open source BlazeDS data services

Adobe’s Damon Cooper, who runs the BlazeDS and Data Services team at Adobe, has posted about BlazeDS vs the paid-for Data Services.

It is a curious post, in that he simultaneously highlights new features coming in Data Services 4.6 while also giving a number of reasons not to use BlazeDS.

BlazeDS is the free and open source version of Data Services, for publish/subscribe messaging and remote object invocation of Java objects in a Flash or AIR application.

He points out that the LGPL licence may be problematic; he emphasises that BlazeDS is unsupported; he says that while it is open source there are no non-Adobe committers; and as the knock-out punch adds:

Additionally, while we will absolutely be making sure we keep BlazeDS fresh and the bug fixes flowing, we don’t currently have any major new features planned for BlazeDS. That could change, but we’re currently full-out on delivering innovation to our customers have asked for in Data Services and we are full steam ahead there. 

It does sound like a retreat to me; and while I do not think Adobe is under any moral obligation to continue developing BlazeDS it does make me wonder what has changed between the moment in 2007 when Adobe decided it was a good idea to open source part of its LiveCycle Data Services, and today.

At Adobe MAX last week Adobe announced the acquisition of Nitobi and with it the open source PhoneGap project. PhoneGap is heading to the Apache Foundation – probably a good thing considering that Adobe sometimes seems to struggle when it comes to managing open source software.

delphi, embarcadero, professional, software development

Delphi and RAD Studio XE2 gets its first update as Embarcadero confesses copyright issue

Embarcadero has posted its first update for Delphi XE2 and C++Builder XE2. Whether this shows commendable responsiveness, or that that the original release was buggy and premature, is a matter for debate.

Either way, the list of fixed bugs is extensive. There is also a copyright issue, since Embarcadero says – note use of that mightily abused word “may”:

We were recently made aware that some code in the 3D support in FireMonkey may be similar to code in GLScene, an MPL open source project. We worked with Eric Grange, a key contributor to the GLScene project to remedy the issue and replace the code in question.

Unfortunately applying the patch means a full uninstall and reinstall, though Embarcardero says that future patches will be based on this new build which I presume means this surgery will not be required again.

.net, apple, linux, microsoft, mobile, windows

Miguel de Icaza talks about Windows 8 and the failure of Linux on the desktop

29 Comments

At Microsoft BUILD earlier this month I arrived early to hear Anders Hejlsberg talk about the future of C#, and found myself next to Miguel de Icaza, co-creator of the GNOME desktop and of Mono, the open source implementation of Microsoft .NET. I took the opportunity to ask a few questions, which I have his permission to post.

I recall that when .NET was first announced in 2000, it was not long before de Icaza announced Mono. I was interested therefore to know his reaction to Windows 8 and the new Window Runtime which powers “Metro-style” apps. Will we get an open source implementation of Metro-style on Linux?

I don’t think so. To be honest, with Linux on the desktop, the benefits of open source have really played against Linux on the desktop in that we keep breaking things. It is not only incompatibilities between Red Hat, Unbuntu, Suse, but even between the same distribution.  Ubuntu from this week is incompatible with the one nine months ago. And then there are multiple editions, the KDE version, the Gnome edition, the one that is the new launching system.

When you count how many great desktop apps there are on Linux, you can probably name 10. You work really hard, you can probably name 20. We’ve managed to piss off developers every step of the way, breaking APIs all the time.

I’m heartbroken, that’s the bottom line.

What about compiling your Metro app for iOS or Android?

I think that Linux has a tough time on the desktop. And the desktop is starting to not matter any more. On the other hand, building WinRT is going to be a significant amount of work. A large chunk probably could be reused from Moonlight. But it is a lot of work, to be able to reuse existing Windows apps, and in the case of iOS they already have their own stack, and Mac has its own, Cocoa is really nice and we have .NET bindings for it.

So I think we’ll learn interesting lessons from Metro. There is stuff that will be useful on other platforms like the JSON reader. But I’m not going to spend any time on WinRT for other systems.

And we can speculate about how well Metro will work in the market …

They are Microsoft, it’s going to succeed. In three years they are going to have this thing on half a billion computers, so it will be out there.

It seems like they are going to use their muscle for two things. It’s going to be a tempting space [for developers], but if you want to go into the right distribution channel for that half a billion computers, you need to abide by the Metro guidelines. They are not going to give you full API access, they are going to give you the sandboxed version. Which is good, because it can finally fix the security problems on Windows. They are going to use their muscle to reset the rules for Windows.

Especially on ARM

Right, and it is needed, they definitely need to fix this mess, a lot of malware, spyware, and the fact that everybody is sysadmin, and has to reinstall their machine every so often.

I’ve heard the word “safe” a number of times.

Right, and think of an iPad, you don’t need to be a sysadmin.

Now, you could argue that by WPF not being available to everybody and being bound to .NET they limited the effect WPF would have had, whereas Metro gives this to C++ developers, but they’re saying, hey, you can’t call Win32, there is all the Win32 stuff you can’t call. You have to use Metro. So they might be repeating that [mistake], but maybe it’s eclipsed by the fact that there’s going to be a rush to the app store. It seems like there is a big enough carrot now.

How are you getting on with the Windows 8 tablet?

I have to say, I actually like Windows 8. I am not a Windows user. It’s probably the first time that I would use a Windows machine.

Miguel de Icaza is now at Xamarin, providing cross-platform tools for using C# and .NET to build apps for Apple iOS and Google Android.

apple, development, google, mobile, nokia, open source, professional, software development, symbian, Web

Android only 23% open says report; Linux, Eclipse win praise

Vision Mobile has published a report on what it calls the Open Governance Index. The theory is that if you want to measure the extent to which an open source project is really open, you should look at its governance, rather than focusing on the license under which code is released:

The governance model used by an open source project encapsulates all the hard questions about a project. Who decides on the project roadmap? How transparent are the decision-making processes? Can anyone follow the discussions and meetings taking place in the community? Can anyone create derivatives based on the project? What compliance requirements are there for creating derivative handsets or applications, and how are these requirements enforced? Governance determines who has influence and control over the project or platform – beyond what is legally required in the open source license.

The 45-page report is free to download, and part-funded by the European Union Seventh Framework Program. It is a good read, covering 8 open source projects, including the now-abandoned Symbian Foundation. Here is the result:

Open Governance Index (%open)
Eclipse 84%
Linux 71%
WebKit 68%
Mozilla 65%
MeeGo 61%
Symbian 58%
Qt 58%
Android 23%

The percentages are derived by analysing four aspects of each project.

  • Access covers availability of source code and transparency of decisions.
  • Development refers to the transparency of contributions and acceptance processes.
  • Derivatives covers constraints on use of the project, such as trademarks and distribution channels.
  • Community structure looks at project membership and its hierarchy.

What is wrong with Android? I am not sure how the researchers get to 23%, but it scores badly in all four categories. The report observes that the code to the latest “Honeycomb” version of Android has not been published. It also has this to say about the Open Handset Alliance:

When launched, the Open Handset Alliance served the purpose of a public industry endorsement for
Android. Today, however, the OHA serves little purpose besides a stamp of approval for OHA
members; there is no formal legal entity, no communication processes for members nor frequent
member meetings.

By contrast, Eclipse and Linux are shining lights. MeeGo and Mozilla are also praised, thought the report does mention Mozilla’s “Benevolent dictators”:

In the case of conflicts and disputes, these are judged by one of two Mozilla “benevolent dictators” – Brendan Eich for technical disputes and Mitchell Baker for non-technical disputes.

Qt comes out OK but has a lower score because of Nokia’s control over decision making, though it sounds like this was written before Nokia’s Windows Mobile revolution.

WebKit scores well though the report notes that most developers work for Apple or Google and that there is:

Little transparency regarding how decisions are made, and no public information provided on this

Bearing that in mind, it seems odd to me that WebKit comes above Mozilla, but I doubt the percentages should be taken too seriously.

It is good to see a report that looks carefully at what it really means to be open, and the focus on governance makes sense.

adobe, bbc, flash, google, linux, open source, professional, software development, Web

Cross-platform concerns as Adobe abandons AIR for Linux

Adobe is giving up on AIR for Linux – at least, in a fully supported manner:

To support the variety of Linux-based platforms across PCs and devices, we are prioritizing a Linux porting kit for AIR (including source code), which Open Screen Project (OSP) partners can use to complete implementations of AIR for Linux-based platforms on PCs, mobile devices, TVs and TV-connected devices. We will no longer be releasing our own versions of Adobe AIR and the AIR SDK for desktop Linux, but expect that one or more of our partners will do so. The last Adobe release of AIR for desktop Linux is AIR 2.6.

This is a curious message. OSP partners include ARM, Intel, the BBC, Google, Toshiba and other big names; but which of these might build an AIR SDK and on what sort of terms might it be supplied? Or it is more likely that, say, the BBC will deliver BBC iPlayer for LInux in a bundle that includes the AIR runtime? Or is it just wishful thinking?

Adobe’s open source evangelist Dave McAllister has a go at defending the decision, pointing out that the growing client operating systems are Android and iOS, not desktop Linux, and that AIR for Linux accounts for only a 0.5% download share. However, Linux developers observe that Adobe’s AIR for Linux effort has always been half-hearted and tricky to install, especially on 64-bit installations. AIR itself is still 32-bit, as is the Flash Player on all systems, though there is 64-bit version in preview codenamed “Square”.

Most people run Windows or Mac desktops, and will not miss AIR for Linux. That said, decisions like this do undermine confidence in the Flash platform as a cross-platform proposition. The problem is, Flash technology is not open source and ultimately whether a particular platform is supported is a matter for Adobe, with all the commercial and political factors that implies.

The risk for Adobe is that when it abandons smaller platforms, it make open standard alternatives and in particular the collection of web technologies we call HTML5 more attractive.

.net, cloud computing, microsoft, open source, php, professional, software development, web authoring, windows

Would you consider running PHP on Azure? Microsoft faces uphill battle to convince customers.

1 Comment

Yesterday Microsoft announced Windows Azure SDK for PHP version 3.0, an update to its open source SDK for PHP on Windows Azure. The SDK wraps Azure storage, diagnostics and management services with a PHP API.

Microsoft has been working for years on making IIS a good platform for PHP. FastCGI for IIS was introduced partly, I guess, with PHP in mind; and Microsoft runs a dedicated site for PHP on IIS. The Web Platform Installer installs a number of PHP applications including WordPress, Joomla and Drupal.

It is good to see Microsoft making an effort to support this important open source platform, and I am sure it has been welcomed by Microsoft-platform organisations who want to run WordPress, say, on their existing infrastructure.

Attracting PHP developers to Azure may be harder though. I asked Nick Hines, CTO for Innovation at Thoughtworks, a global IT consultancy and developer, what he thought of the idea.

I’d struggle to see any reason. Even if you had it in your datacentre, I certainly wouldn’t advise a client, unless there was some corporate mandate to the contrary, and especially if they wanted scale, to be running a Java or a PHP application on Windows.

Microsoft’s scaling and availability story around windows hasn’t had the penetration of the datacentre that Java and Linux has. If you look at some of the heavy users of all kinds of technology that we come across , such as some of the investment banks, what they’re tending to do is to build front and middle tier applications using C# and taking advantage of things like Silverlight to get the fancy front ends that they want, but the back end services and heavy lifting and number crunching predominantly is Java or some sort of Java variant running on Linux.

Hine also said that he had not realised running PHP on Azure was something Microsoft was promoting, and voiced his suspicion that PHP would be at a disadvantage to C# and .NET when it came to calling Azure APIs.

His remarks do not surprise me, and Microsoft will have to work hard to persuade a broad range of customers that Azure is as good a platform for PHP as Linux and Apache – even leaving aside the question of whether that is the case.

The new PHP SDK is on Codeplex and developed partly by a third-party, ReadDolmen, sponsored by Microsoft. While I understand why Microsoft is using a third-party, this kind of approach troubles me in that you have to ask, what will happen to the project if Microsoft stops sponsoring it? It is not an organic open source project driven by its users, and there are examples of similar exercises that have turned out to be more to do with PR than with real commitment.

I was trying to think of important open source projects from Microsoft and the best I could come up with is ASP.NET MVC. This is also made available on CodePlex, and is clearly a critical and popular project.

However the two are not really comparable. The SDK for PHP is licensed under the New BSD License; whereas ASP.NET MVC has the restrictive Microsoft Source License for ASP.NET Pre-Release Components (even though it is now RTM – Released to manufacturing). ASP.NET MVC 1.0 was licensed under the Microsoft Public License, but I do not know if this will eventually also be the case for ASP.NET MVC 3.0.

Further, ASP.NET MVC is developed by Microsoft itself, and has its own web site as part of the official ASP.NET site. Many users may not realise that the source is published.

My reasoning, then, is that if Microsoft really want to make PHP a first-class citizen on Azure, it should hire a crack PHP team and develop its own supporting libraries; as well as coming up with some solid evidence for its merits versus, say, Linux on Amazon EC2, that might persuade someone like Nick Hine that it is worth a look.

agile, open source, software development

QCon London kicks off with call to rediscover Agile, use open source

I’m at the QCon developer conference in London – one of my favourite developer conferences of the year because of its breadth and energy.

The opening keynote was from Craig Larman who spoke on doing lean and agile development – in particular, the Scrum methodology – with large multi-site teams. He means sizeable product groups of 500-1500 persons, though he also remarked that development on this scale is really a bad idea and that a team of 10 smart folk is much better.

Still, I guess large teams are an inevitability, and Larman has written books on the subject. I am not going to summarise the talk exactly, interesting though it was, but I am going to pick out a couple of asides which interested me.

Agile methodology is really about promoting communication; and one of Larman’s themes is that if you do what seems obvious, that is to break down a project into components and give one to each small team, then you end up with numerous teams that do not communicate well with each other. Agile becomes something you do in name only.

Larman spent a bit of time on which collaboration tools to use. One of his points was not to use any commercial tool that describes itself as being for agile project management or similar. I can think of several. He says these tools are just the commercial tool vendors repackaging their old non-agile tools. Whiteboards, spreadsheets on Google docs, wikis and other simple tools are his recommendation. For source code management he suggests Subversion, Git or other open source solutions. Never use Rational Clearcase, he added, it always causes problems.

In fact, he went on to say that any commercial tools cause problems when mutli-site development extends beyond to teams in developing countries. They cannot afford the licences, he says, so avoid them.

It seems to me that the common theme here is how easily agile development intentions become non-agile in practice, especially in these large project groups.