I love polls and surveys, because they tend to clarify almost any situation enormously. Data has a way of stripping away doubt and uncertainty.
Strawberry Perl exists in the form it does largely because of Michael Schwern's Perl Community survey. His discovery that 10% of respondents worked primarily on Windows, but 40% of respondents worked on Windows "At least once a year" essentially defined the target market, and brought about the current Strawberry mission statement.
"A 100% Open Source Perl for your Windows computer that is exactly the same as Perl everywhere else"
With the about-to-be-released Strawberry October 2009 release, I think we've finally met that challenge. The entire core crypto module set now builds properly, finally giving Windows support for https:// URLs and Module::Signature support (a long-time bugbear). Thanks to hard work by kmx, we can now also include C libraries in a manner that is protected from PATH collisions.
As far as the 40% of people that use Windows once a year goes, Strawberry Perl is now basically "done".
So it's time to turn our attention to the remaining 10% that use Windows every day, and particularly the newbie subset of this group. These people now make up the majority of people that we see arriving in the #win32 channel.
As a general rule, they arrive in the #win32 support channel having successfully downloaded and installed the headline Strawberry release from the front page. But because it is installed Unix-style as just the language, they have no idea what to do next.
There's a notable expectation amongst maybe a third of arrivals that the language comes with an IDE built-in, and questions like "How do I run a program" are common.
Looking at the recent Perl IDE and Editor Poll results, you can see the result of this lack of assistance.
Looking at the lower-percentage results, you can see that a significant number of people are using generic programmers text editors for Perl work, when superior options are now available.
While Padre is not yet a fully capable alternative to EPIC and Komodo, and will likely not be competing with vi(*) or Emacs any time soon, anyone currently using Ultraedit or Notepad++ (the two biggest Windows-specific editors) could easily switch to Padre and see productivity improvements (particularly in the case of Notepad++).
Taking over these groups would triple Padre's market share even from the Padre-biased respondents, it gives us a well-identified target market we can aim at, and it would mean thousands more potential Padre contributors.
We know from Ashton's Law ("Just make it fucking easy to install") that the ease of procurement of software is twice as important to market share as the quality of the software.
So as good as Padre is becoming in its own right, we can amplify the adoption rate enormously by simply making Padre so easy to procure that users don't even need to think about it.
Given the clear and significant benefits to both the Strawberry and Padre that would come from working more closely together, and the increased maturity and reliability we are seeing in both codebases, I think the time to finally start serious work on the long awaited "Chocolate Perl" concept has arrived.
With regards to the name itself, a number of people have mentioned that it would be a bad idea to go with this as the real name of the product, due to brand confusion. And I agree.
So while we will keep the name Chocolate as a codename in the short term, the more likely product name will be something like "Strawberry Perl Professional" (in keeping with the principle of least surprise) and will become the primary download link on the front page of the website.
The current Strawberry Perl product will probably be renamed to something like "Strawberry Perl Lite" or "Strawberry Perl Express" and will be potentially be moved off the front page to prevent confusion and limit the users of it to people that understand specifically what they need.
Looking at my currently installed Strawberry Perl, which contains a reasonable sample of the additions that will be included in Chocolate, I would say we can expect a download size of around 100meg and an installation footprint of around 500meg (not including data cached by the CPAN client), making Perl truly "Enterprise Grade" software :)
On top of a bundled copy of Padre, the list of included modules will be long and extensive, and will include four main categories.
1. A set of all significant (working) Win32:: modules, as well as modules for Excel integration and so on.
2. The most popular module sets for specific common project types (BioPerl, Catalyst + plugins, POE + plugins, PDL, SDL, Imager/GD, WWW::Mechanise, and so on)
3. All of the CPAN Top 100 that install on Windows.
4. A set chosen from the most-downloaded modules off http://cpan.strawberryperl.com/
Given how long this installer will take to build, the availability of a true production grade Perl 5.10.1, and to preserve CSJewell's sanity, I would anticipate that Chocolate will only be released as a Perl 5.10 variant.
Anyone savvy enough to know they need 5.8.9 should be reasonably capable of using the current lighter Strawberry product and installing the additional required modules themselves.
Since most of the pieces needed for Chocolate now install quite well (on the October release) I imagine we can produce a fairly decent beta by Christmas, with the first production version arriving as part of the January 2010 Strawberry release.
Wow! What can I say? I'm very pleased and very supportive. +1 to all the new contributors who have been making this possible.
-- dagolden
Having an entire usable environment, and not just perl and a compiler, might make me pay more attention to Windows.
It would also be nice to have a downloadable OS X version of Padre. Right now, it's just too much of a pain in the arse to bother with. Presumably it would have to come with perl itself bundled somewhere in the Padre.app directory.
How about "Strawberry Perl Workstation Edition" and "Strawberry Perl Server Edition"? It seems to me that most folks would only want the "lite" edition for running code on a server where they have no UI.
--Theory
Re:Naming
Alias on 2009-10-28T04:56:52
Potentially, although the problem I find now is that there's isn't really a clear separation between the two. Not enough to make a client/server split the obvious way to break them up.
Re:Naming
jdavidb on 2009-10-28T21:34:09
I don't get it at all. Serve your target market, but I will always want Perl to be just Perl. When I install Java, I just want Java. When I want an IDE, I go out and install Eclipse. When I install Perl, I just want Perl. I decide what editor or IDE to use with it.
This is probably a good idea, but I can tell right off I'm not in the target market at all.
Re:Naming
Alias on 2009-10-29T04:51:41
The newbie market doesn't know HOW to "decide what editor or IDE to use".
They are going into a new area blind, and they already have to learn the language itself. It's important to not distract them from this by providing an option that removes all the other decisions and provides sensible defaults.
Re:Naming
jdavidb on 2009-11-06T16:03:10
Do people think of IDEs are part of their programming language today, then? To me, if you know how to program, you know what editor or IDE to use, or, you know how to find out (such as by Googling "Perl IDE"). To my way of thinking, the only way that can be true is if either:
- Newbies do not know how to program, or
- Newbies think of an IDE and a language as one package
I honestly don't know what it looks like out there. I am presuming 2) is the case.
Re:Naming
Alias on 2009-11-11T06:17:09
It's a bit of each, actually.
