I been thinking about it for a few days, and of course consider I know nothing about grammar parsing or how any of this works. I wish the my $var; syntax would go away... or at least be less necessary. In almost all cases you want a lexical variable and use strict; doesn't allow you to use $var anyways. So what'd I'd like to see is my become a mostly unnecessary reserved word, make $var a lexical variable by default, e.g. my $var; be the same as $var. my would only be needed for redeclaration's and back compat. It could be enabled with a pragma or something like use feature 'lexical';. There might be some reason I'm completely wrong or stupid, but this doesn't seem like a bad idea, and of course our, state, local would still need to exist.
UPDATE: the point of this would be to make variables lexically scoped by default as opposed to there current global default.
the ; is a comment in ini, now dzil won't use that plugin. But people will say well you don't want to do that of course I want that plugin enabled. Here's why you may not temporarily. Casual user X has a bug in /your/ module that's using dzil, they code up a patch, and they want to run your test suite. The can't, because [pluginXTests] won't even install properly on their system due to a non perl dependency. They could have just commented it out, but now because you've used this PluginBundle it become difficult. They can't just comment it out.
They might be able to
[@Filter]
-bundle = @USERNAME
-remove = pluginXTests
IF they can get your bundle installed in the first place. This requires them find a way to install your Bundle without installing said broken module.
as I stated at the top my problem is with [PodSpellingTests] it itself isn't broken, but it's dependency Test::Spelling is on some systems, due to the lack of a 'spell' command.
Yes I know there's a workaround... I could just copy a shell script into my path that makes aspell or something work, but really that's not the right solution. No I'm not packaging GNU Spell for my system either, the other spell programs work much better (from what I've read).
Also I find modules with your own username in them to be fairly obnoxious.
If you'd like less code, can't we start making a few more generic Bundle's? I wouldn't minde seeing a Bundle for Tests, and maybe another one for other stuff. I think 1/3 of the lines in my dist.ini's are tests.
This is a pseudo reply to Jason Calacanis for what he said about using an Open Source game engine to build a game in This Week in Startups #54, Ask Jason segment. For more shows ThisWeekIn.com.
I believe Jason is implying that you can't make money with open source software(that's not a support contract variant) directly, but it's a good resume builder. True there aren't any big billion dollar open source companies, and companies like Red Hat make money off support, but I don't believe he's correct. But there are 100 million dollar open source companies (Red Hat), and companies that make billions, and have a successful open source strategy, not all of which is support.
For starters I am not a lawyer, successful entrepreneur or venture capitalist, I am a student about to start ~ his last year of his CS bachelors. I will mostly be referring to the GPL family of open source licenses, as a generalization on open source, so if what I say doesn't match your specific OSI approved license that's why.
Piracy
Probably the biggest concern you have with open sourcing your software is that people will be able to use it for free. Guess what? almost all software worth using is available for free if you know where to look. Those that aren't are usually web only or have there distribution channel well locked (e.g. like apple store not available on cd). All this DRM-ed software out there has people distributing it and making cracks and keys available for it. So even if you built everything and locked it all up with DRM people would still find a way to not pay for it.
Licensing
Selling
Absolutely nothing in Open Source says that you can't sell your product or your source code. In fact the GPLs explicitly allow it. Not only can you sell the resulting binary and medium that it's distributed on, but you can sell the source too, you just have to make it available.
Using
All versions of the GPL allow you to modify the code for the use of the entity (business or personal) so long as you do not redistribute that code (meaning you can modify gpl to your hearts content inside of a business and not have to give anything back).
LGPL
The LGPL specifically allows you to call their API in a proprietary piece of software, and only if you modify the LGPL software itself do you have to share that code.
GPL
Mandates that you share any code that is a derived work of the GPL work under a GPL Compatible License. In the specific case of wordpress themes, what derived meansiscontested. I particularly like this:
Seem's the GPL FAQ clarifies all various circumstances in the next few sections. I certainly wouldn't want to be a python programmer... I do believes this means you can't make any python code that uses a core python library proprietary.
One way around it may be how NVidia releases their drivers when the Kernel is GPL2. They create a small wrapper module in kernel and release a binary blob outside.
Another way is if your program is served by a server, technically under the GPL this is NOT considered derived as the program runs on YOUR server, thus you don't have to share the changes. A webapp based on GPL software can be as proprietary as you want it to so long as you aren't distributing it (Not sure about the legal case on software hosted by a hosting company). It also means if it's your companies hardware, you don't have to open source it (this has been pulled on 'rented routers').
AGPL
This is the strictest of licenses, and is meant to insure open code in the event of the final paragraph of the last section. You must share code if anyone outside of your entitity is using the software.
Binaries
Nothing says you have to release the source of your games with your binaries. If your game hits the shelves of best buy and works.. most people will never bother to look see that the source is available, and that is completely legal.
There are 2 types of game(er)s... casual like Farmville, and Bejeweled... and hardcore games like Half-Life, StarCraft, Neverwinter Nights, to name a few. Casual gamers are usually not sophisticated computer users. "I should update my antivirus? what's a browser?", are not things I would be surprised to here them say. Hardcore gamers are however, and most can probably rattle of their system specs and know not only to update their AV but how to disable while gaming, many even know how to overclock their system.
Casual gamers won't be able to figure out how to assemble your source to even begin to consider pirating it. Many Hardcore gamers could, and might just to try to get more performance out of it. Most would still pay for it though, because your code doesn't include any DRM, which is becoming more annoying to them (and of course you made a great game worth buying right?).
Building software binaries isn't easy, I don't think that any license in open source requires that you include documentation on how to do so. Although you might be seen in a negative light for doing this and someone else will figure it out and publish it. This will require your users to download a toolchain of software and use it. This is not corporate IT, most of them haven't done this and it'd be too intimidating for all but the most determined (for novice software builders).
Contributers
Almost all of the Really long lived games such as Half-Life, and StarCraft had the ability to be modded, sure the source code for the engine wasn't available, but you could make your own 'mini games'. That couldn't be played with out the original. If people had the source for your game engine too they could do even more than standard modding to make your game better. Heck, they might even port your game to a new operating system where you could make money on it from the game. As your company grows you could recruit these contributors to your company.
Marketplace
Or should I say Mod Store, why not create a marketplace for gamers to sell or give away their modules. They can pay you a percentage of royalties.
MMO
Did I mention that whatever is on your servers doesn't have to be Open Source? what good is World of Warcraft without the servers? and how much is it really hindered by a free competitors on their software like The Spirit Realm. Which just to clarify is a free version of World of Warcraft built on proprietary WoW run on their own servers. I don't see Blizzard bleeding money over it, or suing.
Giving your competitor an advantage
This is the main reason that games don't open source their engines, they are afraid the competition will steal it. I don't really get that, you're a gamer, you play good games, and you play and buy more than one. Most of the time you only buy one copy so it's not like they'll make more money convincing you their product is the best. But you can charge to license your engine. What'd be wrong with that?
My conclusion is that I don't know really understand why a company that's big enough doesn't try it. EA and Activision both release enough crap to try it with one game. I honestly think you can make money on any quality Open Source software that you could make money on if it were proprietary. If you do it though, much like Red Hat, you may not be able to expect to be a leader financially, but that doesn't mean your revenue's will be anything to sniff at.
so the whole 'open source' has no warranty thing keeps coming up as a defensible reason that I'm wrong.
Microsoft offers a 90 day limited warranty that the software will work to some degree or another as advertised or some such. If you really want to consider what they're saying... it should work if it doesn't we can send you another disk or you can return for refund. which really is what you could have done at the store anyways. I suppose it also means it won't fry your hardware, does anyone know any stable open source software that does that? I suppose a few things could if tweaked right..
Open Source generally doesn't distribute a physical medium, or fry peoples boxen, so what would we even use a warranty for? oh right... a CYA. We really don't want to be sued because someone downloaded our software and it didn't work or broke something of theirs.
Generally your software warranty doesn't really cover support, and if it does it's for a very limited time, and very limited support. Warranties are more for physical medium. For example my Dell came with a 1 year warranty, but because I ordered it with Ubuntu they would provide hardware support only.
The point is that if you're claiming we shouldn't support our software because it is without warranty... the warranty as far as I can tell doesn't have much to do with the software and everything to do with the medium.
Really, the CYA is a good thing. I don't disagree with it... however, it shouldn't be used as an excuse to do nothing. It just means you can't be legally harmed if you do nothing.
people seem to think that I'm saying support should be a #1 priority. will someone please cite where I said that? yes I said it should be a priority, I said you should do it. I did not say where on the list it should fall. Even if you're an employee at a company making $100k a year, if you're wife is dying, your priority is that, hopefully your children come before said company in most cases too. Understand, that I'm not saying put your software (paid or unpaid) before your life. That would be stupid. I'm saying get this stuff worked into your schedule for working on software. Support is part of the software lifecycle. If you have 2 hours a day to code set some of that aside for support and documentation (pooma number).
Yes, I think I've proven that volunteering to do open source comes with a responsibility or obligation. However, since there is no governing body, and no one has given us rules of good behavior. What that good behavior is, is what is subject to debate.
So hopefully we can stop arguing that we have no responsibility due to being unpaid volunteers and a license, which is really (I believe) just meant to protect us from lawyers. Once we do that we can actually discuss what it is that we actually should consider ourselves responsible for, and more importantly how we can communicate it.
Software licenses is general do not communicate these things. I think David Golden said is on the right track. Keep in mind some Open Source projects (e.g. PostgreSQL discuss a support policy outside of their licensing ) I think postgres policy is excellent for a project of its size. However, I don't expect anyone to support a single release of a small project for 5 years. 1 year might be appropriate for a Major release version.
Actually, PostgreSQL is an exemplary example of how Open Source should be conducted. I've requested stupid features and been told why they were stupid, and no one cried foul of users requesting features. I've asked for help and always received excellent support for my problems. I personally have never been able to locate more than a minute documentation bug in Postgres, and it seems that all new features are adequately documented as part of their QA.
Why is it that we don't all strive for this level of quality?
p.s. the reason postgres created that policy in the first place was that some people started thinking they were supporting old versions (like 7.4) for too long.
UPDATE: I'm locking comments. I'm tired of people commenting when they obviously haven't complete read what I've written. Either that or there grasp of English is poor. It's irritating to be constantly misquoted.
So, I'm heavily criticized for my unpopular opinion that open source volunteering is a job. I would like to point out the definitions of Volunteer and Work from answers.com I have removed a few irrelevant definitions, like those of 'botany'.
n.
A person who performs or offers to perform a service voluntarily: an information booth staffed by volunteers; hospital volunteers.
Law.
A person who renders aid, performs a service, or assumes an obligation voluntarily.
v., -teered, -teer·ing, -teers.
v.tr.
To give or offer to give voluntarily: volunteered their services; volunteer to give blood.
v.intr.
To perform or offer to perform a service of one's own free will.
To do charitable or helpful work without pay: Many retirees volunteer in community service and day care centers.
also
n. 1. a person who freely enrolls for military service rather than being conscripted, especially a member of a force formed by voluntary enrollment and distinct from the regular army.
2. a person who freely offers to take part in an enterprise or undertake a task.
3. a person who works for an organization without being paid.
v.
1. freely offer to do something: he volunteered for the job.
2. offer (help) in such a way: he volunteered his services as a driver for the convoy.
3. work for an organization without being paid.
4. commit (someone) to a particular undertaking, typically without consulting them: he was volunteered for parachute training by friends.
You'll note 'service' and 'work' mentioned. Examples include things like 'fire fighters'and 'hospital' workers and 'military personel'. Imagine if these 'volunteers' didn't feel any responsibility for the work they did. ( actually some open source people do like definition #4 here. I've been volunteered several times in this way )
n.
Physical or mental effort or activity directed toward the production or accomplishment of something.
A job; employment: looking for work.
A trade, profession, or other means of livelihood.
Something that one is doing, making, or performing, especially as an occupation or undertaking; a duty or task: begin the day's work.
An amount of such activity either done or required: a week's work.
The part of a day devoted to an occupation or undertaking: met her after work.
One's place of employment: Should I call you at home or at work?
I don't think these definitions say something other than what I have said. I believe they will be similar to what is found in other English dictionaries.
Ultimately, I do not understand why people are so vehement against this definition for open source 'volunteers'. I can't make you believe this is true, or do it. But my believing it and others believing it hurts nobody. In fact those who are helping and believe it probably produce good, perhaps better, work.
Agree, or disagree, for the most part I don't think I'm going to change anyone. It seems I've only angered good people. My thoughts on the matter aren't going to change. If people want to take their contributions more seriously, that can only be a good thing, in my humble opinion.
UPDATE: I shouldn't have said what I said about RJBS and have apologized publicly
Test Driven Development should be Test and Documentation Driven Development. I don't want to read your code to figure out how to use it. I don't really care if you write the Test, documentation, or the feature first. But you should do all three before moving on to the next one.
I'm gonna pick on Dist::Zilla this seems like a very good tool. Except it's documentation is so sub par it's not funny. The new documentation is quite good, although, I have not decided that I like the 'choose your own adventure' format. However none of the documentation on CPAN is good. It ranges from significantly less than the new tutorial, to virtually non-existant, to completely inaccurate.
You know what? It's not acceptable not to write documentation, especially not when you were apparently paid to do it and have shown that you are capable of doing it. Some people I've talked to think not documenting things is ok. I don't think it is, and it's yet another one of my unpopular opinions. Sure you can not document them... If someone else has volunteered and is actually doing it.
Yet maybe this is one of the reasons perl has fallen by the wayside. Documentation is usually either cryptic, incomplete, or inaccurate. Even the core docs like perlintro has inaccurate and potentially damaging information. Why are we so surprised that so many people don't know how to program perl in a modern way if the documentation is so bad?
Documentation should explain who, what, when, where, why and how. Who should use this module, what they should use it for, when they should (and shouldn't) use it, where they should use it, why they should use it, and how to use it. Unfortunately most documentation fails at all but the how, and the what. Who is an Abstract, and Description thing, you should consider who doesn't need it. Why why can be tightly related to who, but really I want to know why this module and not another, consider who needs a templating engine vs why it should (or shouldn't) be HTML::Zoom. When is also closely related to the previous 2 and will probably be answered with them, although consider when to use a for loop vs when to use a while. Where could be anywhere from top of file, to your view in a catalyst program. How is obviously the actual code and should be covered in the synopsis. Sometimes you'll have to think if you've answered all these, but if you manage to answer them all in a comprehensive and complete manner then you're documentation is probably good enough to be useful.
I don't expect people to be perfect in this, but some effort is better than none. Also if you write documentation, you may end up answering less questions, and save people many hours finagling a problem.
I'm sure even my modules fail to meet my own standards.
The best documentation I've seen is PostgreSQL's and Gentoo's.
