And now you've gotten lesson #1 on why F/OSS solutions have one huge advantage over their proprietary counterparts: If the original developers of a F/OSS app decide to drop it, you have choices. In the best case, another group of devs may simply fork the project and keep it going, or you ('you' in the general sense here) may choose to bring development in-house, or contract with a 3rd party to maintain and upgrade the app.
Now you might argue that some of those choices aren't that appealing, or that it's not guaranteed that someone else will pick up the app and run with it... but look at the scenarios with a closed-source, proprietary app: If the devs drop it, you're f%!#d, end of story.
Yes, F/OSS has that huge advantage... but even though I'm an F/OSS advocate, I think it's naive to ignore the economics of such projects. They have a much harder time getting off the ground, especially those aimed at a mass market to which you'll have trouble selling a support plan. There are business models, but they're more complicated and don't provide as much income.
I do wish companies that abandon projects would OSS them more often though.
I do wish companies that abandon projects would OSS them more often though.
Agreed. But to their credit, Google have some history of open-sourcing things[1][2][3][4], so maybe there's a chance that this product will be released as well. At least one can hope...
Yet more wild-eyed, open source zealotry. No GUI-based F/OSS product has ever achieved the level of polish and usability of things like Sparrow because the people working on open source projects only want to do coding, they don't care about design, bug detection, documentation or, God forbid, user interfaces. If the developers of Sparrow had not been paid for their work, which they ensured by keeping it under their control, it would likely not have happened at all.
No it isn't. I didn't say that F/OSS is universally better than closed source, or anything crazy. I said that F/OSS has one specific advantage over closed-source, proprietary software, and that relates to the ability for a different group to continue development of a project that would otherwise be abandonware. Are you going to argue that this isn't the case?
No GUI-based F/OSS product has ever achieved the level of polish and usability of things like Sparrow because the people working on open source projects only want to do coding, they don't care about design, bug detection, documentation or, God forbid, user interfaces.
That's debatable, but it also has nothing to do with what I said. Yes, F/OSS has a reputation for being weaker on the UI/UX/design front, no one is contesting that, so far as I can see.
But Thunderbird proves mindcrime's point - even though Mozilla-the-company has decided that developing Thunderbird is no longer aligned with their interests, community-driven development will continue, because it's open source. Yes, development will be diminished, but it won't die outright like Sparrow or other closed-source software would.
For most consumers it's the same. I'd rather pay someone a few dollars than maintain Thunderbird myself (for example) and most people realistically do not have the option of maintaining it themselves.
On the other hand I use a lot of OSS on servers and in the past on my workstations, and have modified them and fixed bugs and such. There are definite advantages but this particular one is not that useful on a large scale.
That said, yes, I agree that some projects would be difficult (maybe even impossible) to monetize as F/OSS. We know the enterprise stuff works, consumer apps may or may not be a different story. I think that book still remains to be written.
Comments
And now you've gotten lesson #1 on why F/OSS solutions have one huge advantage over their proprietary counterparts: If the original developers of a F/OSS app decide to drop it, you have choices. In the best case, another group of devs may simply fork the project and keep it going, or you ('you' in the general sense here) may choose to bring development in-house, or contract with a 3rd party to maintain and upgrade the app.
Now you might argue that some of those choices aren't that appealing, or that it's not guaranteed that someone else will pick up the app and run with it... but look at the scenarios with a closed-source, proprietary app: If the devs drop it, you're f%!#d, end of story.
Yes, F/OSS has that huge advantage... but even though I'm an F/OSS advocate, I think it's naive to ignore the economics of such projects. They have a much harder time getting off the ground, especially those aimed at a mass market to which you'll have trouble selling a support plan. There are business models, but they're more complicated and don't provide as much income.
I do wish companies that abandon projects would OSS them more often though.
I do wish companies that abandon projects would OSS them more often though.
Agreed. But to their credit, Google have some history of open-sourcing things[1][2][3][4], so maybe there's a chance that this product will be released as well. At least one can hope...
[1]: http://code.google.com/opensource/
[2]: http://code.google.com/opensource/projects.html
[3]: http://code.google.com/hosting/search?q=label:google
[4]: http://google-opensource.blogspot.com/
Yet more wild-eyed, open source zealotry. No GUI-based F/OSS product has ever achieved the level of polish and usability of things like Sparrow because the people working on open source projects only want to do coding, they don't care about design, bug detection, documentation or, God forbid, user interfaces. If the developers of Sparrow had not been paid for their work, which they ensured by keeping it under their control, it would likely not have happened at all.
I agree with your post so I want to add something which I think was your intent:
* without a corporate "sponsor" entity behind it. (Chromium => Google, etc.)
Yet more wild-eyed, open source zealotry.
No it isn't. I didn't say that F/OSS is universally better than closed source, or anything crazy. I said that F/OSS has one specific advantage over closed-source, proprietary software, and that relates to the ability for a different group to continue development of a project that would otherwise be abandonware. Are you going to argue that this isn't the case?
No GUI-based F/OSS product has ever achieved the level of polish and usability of things like Sparrow because the people working on open source projects only want to do coding, they don't care about design, bug detection, documentation or, God forbid, user interfaces.
That's debatable, but it also has nothing to do with what I said. Yes, F/OSS has a reputation for being weaker on the UI/UX/design front, no one is contesting that, so far as I can see.
With open source it is often the same. I am looking at you Mozilla Thunderbird.
But Thunderbird proves mindcrime's point - even though Mozilla-the-company has decided that developing Thunderbird is no longer aligned with their interests, community-driven development will continue, because it's open source. Yes, development will be diminished, but it won't die outright like Sparrow or other closed-source software would.
For most consumers it's the same. I'd rather pay someone a few dollars than maintain Thunderbird myself (for example) and most people realistically do not have the option of maintaining it themselves.
On the other hand I use a lot of OSS on servers and in the past on my workstations, and have modified them and fixed bugs and such. There are definite advantages but this particular one is not that useful on a large scale.
And you've also proved why any dev can't make any money off of open source unless they have speaking engagements lined up.
Tell that to Red Hat, Alfresco, OpenNMS, etc.
That said, yes, I agree that some projects would be difficult (maybe even impossible) to monetize as F/OSS. We know the enterprise stuff works, consumer apps may or may not be a different story. I think that book still remains to be written.