"Professional-looking project websites" Whatever...
SawyerX, in his ongoing stream of posts regarding marketing Perl, recently blogged about project websites and suggested we all start hiring, and paying for out of our own pockets, designers to market our free offerings. I kinda wanted to smack him after reading that. I try not to comment on marketing or advocacy, etc. because I really just don’t care. I don’t care if new people use perl or what they think of it. I know it’s good and I know it works. I like my hammer, I think it’s a great hammer, and if you judge by the projects I produce, you would find that to be obvious. However, I will say that even though I consider all this marketing talk to be annoying at best, he does have a point: Our OSS code is our resume. When applying to new jobs, it is easy to list things we did on a resume, but often times we are unable to provide cold hard code to employers because our previous employer owns the rights to it or we are bound by NDAs etc. This puts us in the situation where we often find ourselves saying, “Hey Guy, you should give me a job. I’m a great architect, I’ve built some awesome buildings, many of which you have seen. I just can’t show you them, but trust me, I’m good.” That obviously sucks.
So, while I disagree with the need to throw money at designers to make pretty websites for libraries whose target audience is Perl developers who already know how to work CPAN and probably know how the rest of us roll, it’s be nice to have websites for end-user applications. You know, the kind of stuff people who don’t give a damn about the API use, whether it be from the web or the command line. Those are the people that might not know to look in CPAN / perldoc. Those are the people who don’t care about our API docs, they just want interface docs and frequent use cases illustrated. In this case, it makes perfect sense to have pretty, user-friendly websites published. IMHO, you should also have a PDF manual. But for libraries? give me a break guy. We got better things to do.
I blog about Perl.
I have a good mind to simply reply with a post.
I actually mainly refer to putting up websites that are actual applications. A previous post of mine refers to the lack of creating applications from our modules.
Recently when talking about marketing, people go through great lengths to market Perl by speaking, blogging, going to conferences, putting money in grants, etc. etc., when they might have a website that could take very little money to fix up and make it market Perl itself instead of pummeling it into the ground.
So yes, I think that when DBIC produce a beer coaster (which I have right here), they can also produce a website. If it's good enough to advertise on cons with a beer coaster product, it's damn good enough to put up a website for. And hey, it's cheaper to distribute a website (and easier) than distribute a fixed amount of beer coasters. Won't you agree?
I agree, and I disagree.
I agree because paying for beer coasters, designers, flyers and the likes with actual money is a stupid idea because that's money that could be spent on better things. It doesn't take money to get good designs, as the revamp of perl.org showed that was done gratis by the designers at Foxtons. There is designers like myself who, with some communication and patience would happily work for the cost of attribution. I'm sure a lot of companies who do use Perl greatly and have designs teams could, under arrangement allocate designer time as a grant in the similar ways that many motor racing sponsors provide R&D, not cash to the teams.
I disagree towards Guillermo's notion that design and presentation is not important. All that is being said here is "my self interests are being met here, why should I care", completely missing the point of marketing. I guess in some ways it's interesting, you can tell how well programmed a project is, by how ugly the design of its website is. That cliché needs to end, because I think that a well presented, good looking and informative website that shows anyone what distrobution/application/module x can do, how to use it and how simple/fast/powerful/easy it is will attract more users, more contributors. And that is by no means a bad thing that will inflict on your self interests, as it may even enhance them.
Sometimes I think posts such as these stem from either too quick reading or just selective reading.
The original post you're referring to quite clearly specifies what kind of projects should have attractive websites, with examples such as Moose, POE and DBIC. Evidently, the intention was not spending time and money building a professional website for every minor library.
On a more general note, from your comments it seems the only benefit you see in such websites is to make it easier to showcase your personal projects to potential employers.
A great many posts have been written on why this is only a small part of the whole picture of marketing. Shortly, better marketing means the MARKET will better appreciate perl, which means more work and better pay for perl programmers.
I can definitely sympathize with not wanting to put too much work into this, when the possible gains aren't as direct or immediate. But this is still an important and worthy thing to do.
"IMHO, you should also have a PDF manual."
No! Wrong! That's wrong! Where'd you learn that? Stop doing it!
You should *NEVER* have "a PDF manual". You should have a manual, period. It should be available in text form at an absolute minimum, and HTML and text if at all possible. It may also be available in PDF or other forms -- but those other forms should *NEVER* be the only formats available. If they are, you've greatly restricted the usability of the manual, and might as well have not wasted your time on it.
We should _a_ website for Perl projects. That's a single site similar to CPAN. Having multiple sites, scattered all over the place would make it difficult to find them. We need a central repository for them.
I think there is an important idea in what sahqueeks.myopenid.com wrote above - some perl websites have quite a good visibility and can be a great visit cards for designers. I guess this is very similar to how CPAN libraries are visitcards for us programmers.
@ SawyerX:
My initial response still applies. What's the point of a website for Moose or DBIC besides as a way to centralize links to talks etc (which could very well be done in POD too)? I just don't see the added value. They are libraries, they get used by people writing code, people that are already familiar with the CPAN. If you want to make a website for a larger project (like mail/email) and use that as a way to centralize recipes that need multiple dists or as a map of where to find what, that's great. But I see absolutely zero value added to the development cycle by making a website to market a library. It's effort that would have been better spent improving the docs available with the dist itself.
@Shahqueeks:
I never said presentation wasn't important. What is wrong with having our project's CPAN pages be their face to the world? There's nothing stopping you from making them really good docs. There is nothing stopping you from writing good, clear, good-looking documentation. Chart::Cliecker even includes images embedded in the POD!
search.cpan might be plain and not very Web2.0y, but it's not terribly ugly. It works well, it's fast, it's indexed by Google and has its own pretty decent search function and it's a central location. No need to search for a project website, just go to CPAN, you'll find what you need there.
In addition, the redesign of perldoc.perl.org was one of the worst moves the perl community has made in recent memory. The old page was usable, good-looking, uncluttered, and FAST. The new one is borderline unusable.
@TheFinalCut:
I very clearly understood what the original post said. And I still disagree. I don't see *anything* wrong with cpan and housing our documentation, manuals, etc there.
@ shawnhcorey:
I could get behind that. I just think that all yo uare going to end up with is a bunch of un(der)mantained websites to be honest... People have enough of a hard time maintaining the docs that come with their dists. It would be nice if we all had time to make little websites in addition to writing code, tests and docs, but a lot of us don't. Adding more to the TODO list isn't going to increase our tuits.
@dstar
Point well taken. You are right. I should have said it more clearly: You should have a manual that's available in a number of formats, including a PDF version suitable for printing onto dead-tree form. Some of us find dead-tree docs useful when working with new programs. It frees screen space for other things.
That's awful you see no point in websites for libraries.
In the recent year and a half, the Perl community has put so much into marketing (including blogs.perl.org, Iron Man blogging contest, etc.), trying to give Perl a good name. Don't you think that for people to see what awesome libraries Perl has is valuable? Of course if you don't believe that, it's a shame, since that's one of the purposes of Iron Man, to blog and blog and (amongst other things) show off Perl and how cool it is - a library qualifies there.
And if it is valuable (marketing-wise), then having a beautiful website makes it more approachable to people. It's simple logic, I'm surprised you don't see it.
If marketing is important (and to many of us it is), and libraries show coolness (which they do) and nice looking websites make anything more approachable (which is simple stuff we all know), then my reasoning stands.
One other thing that bugs me is that you seem angry. Did I piss you off? It doesn't seem like mere disagreement, you genuinely seem mad.
This is just limited imagination. You want to attract programmers who are not already familiar with the CPAN. In fact you want to attract programmers who are not even Perl programmers. People who don’t already know Perl should be able to realise how awesome our libraries are to the point where the libraries make them want to write Perl.
Your mentality is common, and is exactly what’s causing Perl’s perception problem: we who already use Perl and CPAN know that it’s awesome – and everyone else in the world things we don’t even exist any more. This results in Perl is being decommissioned on grounds of being an old language no one uses any more.
Eventually that will affect you too. That’s why you should care.
I'm not mad, Sawyer, I may just come across like that. The attitude of marketing for the sake of marketing *does* bother me though. It was the principal reason I chose not to participate in IronMan, even though I had plenty to contribute. I think the idea of marketing for the sake of marketing and taking cues from commercial marketing is, quite frankly, mouth-breathingly fucking stupid.
You know what would be useful? People blogging about solving problems. People putting together write ups, whether they be websites or blogs or manuals or articles about meeting a problem and how they leveraged the unique strengths of perl to fix that. Using shinny widgets to say 'look, this is shinny' is not progress. It is quite the opposite. Why concentrate on trying to gain the affections of the lowest common denominator when we can focus on solving problems and sharing with each other how we solved them and why we chose to solve them that way? That would attract the attention we would welcome. I, for one, would rather have 100 real problem solvers using perl than 10,000 people writing hello world programs in Catalyst+Moose+DBIC.
You know what was the worst part about learning Catalyst for me? Being excited by some shinny screencast and then finding absolutely zero information on how to solve real problems. It's the same reason I think one of the only perl blogs worth reading is Yuval's. Easy things are already easy, really, really easy if you are not lazy. We should be thinking more about the making hard things possible part.
People are always trying to lower the barrier to entry. I'm not so sure the barrier really needs lowering.
Guillermo, I totally agree with you that there should be more blog posts on how you solve specific problems. I hope you will also show examples of this.
On the other hand I am not sure where do you take this "marketing for the sake of marketing" thing. While the meaning of the word itself is unclear to most of the people talking about it I think there were quite a number of good explanations why Perl and its tools need more promotion. I think Aristotle gave a very good explanation.
While lowering the barrier of entry is usually a good thing, I don't think the main purpose of those web sites or of the promotion we have been talking about is to lower the barrier of entry.
The idea of promoting and marketing perl is to make it more attractive so people will actually want to climb over that barrier.
As a reminder let me link to the excellent piece by Dave Cross on Why Perl Advocacy Is A Bad Idea. Yes, this is the same dude who runs blogs.perl.org.