Talking WebSharper with Adam Granicz
InfoQ: 2011 has been a big year for WebSharper. What are some of the achievements that you are the most proud of?
Web-based mobile applications are now an intriguing choice for mobile developers and offer a relatively painless path to develop with solid standards and multi-targeting in mind. You can now use WebSharper to develop Android and Windows Phone applications from the same F# code base, and you can easily hook in other packaging technologies to extend your platform coverage even more.
Overall, WebSharper solidified its #1 position in F# web programming and proved the path for web-based F# mobile applications, and we are quite happy about the direction this is taking.
InfoQ: Can you explain what you mean by tooling support? What kinds of things are you now offering in that area?
Furthermore, we now also support various cloud hosted .NET environments and automated deployment hosts like AppHarbor, making it super easy to scale WebSharper applications into the cloud. This is an important enhancement and removes literally all obstacles from seamlessly migrating WebSharper web and mobile applications into the cloud. We continue to invest heavily in this area and, among others, are working on a cloud-based WebSharper IDE that enables development teams to develop and collaborate on various WebSharper projects without the need for installed software, all on the web. Developers can expect the first beta releases of WebSharper IDE in 2012 Q3.
InfoQ: How has your HTML5 support changed since the early versions of WebSharper?
In the upcoming 3.0 version of the product, we will also be providing an alternate compilation path that is based on .NET IL code instead of F# metadata. This will allow developing parts of or entire WebSharper applications in C# and other .NET languages, but at the same time keeping F# as a powerful and popular choice for both client and server-side code.
InfoQ: Why did you decide to release WebSharper as an open source project?
Primarily, this move reflects our ongoing conscious effort to increase the visibility of the project. We are faced with quite a challenge: even though F# has a quickly growing and steady mass of developers, there are relatively few who are web developers, and there are even fewer who are not only both but are also willing to pay for an expensive product. So by going open source, we are aiming to get a much larger slice of the growing F# developers by enabling authoring open source software at no cost, bringing in new web developers to F#, and turning more F# developers to web developers. Furthermore, we believe that there are a healthy number of derived opportunities such as trainings, basic and custom support plans, and other innovative, subscription-based services that we can build around WebSharper to make transitioning away from strictly selling a product easier and worthwhile.
Going open source also lifts the limitation that WebSharper is a closed and opaque product of a small company, which was a concern before to several larger and Fortune 500 companies with a more managerial mindset about the risks of innovating development approaches with a relatively new product backed by a smaller company. Now with WebSharper open source, there is clear transparency and no longer any fear about investing in a product that may disappear, and this also allows us to grow more synergically and to innovate in various new ways and build new and related services.
InfoQ: Can you explain why WebSharper went with a modified AGPL license and how the exceptions work?
WebSharper is both a framework, an SDK that facilitates and eases the development of web and web-based mobile applications, and in part a set of source files that are included in those applications, similar to any library.
Most developers who use WebSharper use it as a tool and a library: a tool to compile and build web and web-based mobile applications from F# code, and a library that is included within those. As such, these WebSharper applications include code from, and benefit from WebSharper directly. Here, developers have two choices: they either open source their entire application on GNU AGPL v3 or another open source license from the exceptions, or keep it closed as long as they have a valid developer license for each developer participating in developing that application.
This dual licensing model caters to both open source and closed source developers and seems to be a popular model with similar projects. AGPL fills an important hole over GPL in server-side scenarios such as client-server web applications, and even if AGPL is not favored or outright ruled out in an organization, their entire application code base can be licensed in any one of the license types listed in the WebSharper AGPL license exceptions, keeping only the code of WebSharper and its associated library components under AGPL.
The only significant exception is building other development frameworks based on WebSharper, which is not covered by the above dual licensing model and in turn requires special licensing. This, once again is not unheard of, several other open source projects apply similar restrictions to ensure that no work is taken unethical advantage of.
InfoQ: Lately there has been a lot of talk about the difference between open source and open development, the latter meaning the project accepts source code contributions from the general public. Do you see WebSharper moving into an open development model?
Many of these community efforts are truly inspiring and represent a great deal of energy going into the platform. For instance, some are working to enable WebSharper applications to run in new web containers and are integrating with upcoming standards such as OWIN or Web.API.
You can surely expect these to make their ways into the main WebSharper code base at some point as we are moving to gradually embrace the open development model and starting to take code contributions in a controlled manner.