Skip to main content
Welcome guest. | Register | Login | Post

Delivering Upgrades To Developers -- How?

5 replies [Last post]
supermike's picture
Offline
Joined: 2006-02-17

Okay, put a developer hat on (even if not one) and imagine this scenario. Imagine you found a CRM-lite web app kind of thing, definitely FOSS, that would be perfect for your office, but you want to add about 2 months of customization to it. After two months, you're done. However, then, on the website where you downloaded that software, you hear that some updates are almost ready for the web app.

Given that scenario, how would you like to see those updates implemented? (It's okay to want to see them implemented in multiple ways at the same time.)

For instance, there are two problems with this:

* Developers who customize the application, especially an application designed intentionally to be customized, will have trouble integrating critical security and business logic patches in with their existing code. They can't just replace files because then they would lose their customization. (Luckily I have implemented a good deal of the project in objects so that one can choose to update objects they haven't touched and leave others alone because they have customized them.)

* I actually want to make money with FOSS by selling consulting services, a programmer manual, pre-installed rackmount servers and memory sticks, and media kits that include printed manuals. But if someone wants to download the app, it's free. So, given that, do you think that there is a problem with this kind of application in this kind of model? Do you think developers will want to get something that they cannot easily update? This is one reason I think why forks occur that can steal marketshare and potential revenue away from FOSS projects.

The products SugarCRM and vTiger are in competition with each other, and vTiger is its fork. There's also the rivalry between Joomla and Mambo, and phpBB and vBulletin. One wants to build something cool that people can use as an SDK, but they also want to pay for their development efforts.

a thing's picture
Offline
Joined: 2005-12-20
not your problem

I don't think this should be your problem. The customizer should try applying patches made from the old version & the custom old version to the new version.

By the way, I hope that manual you plan on selling is free...

Offline
Joined: 2006-03-28
I agree. Though of course

I agree. Though of course you should try to keep separate parts as independant from each other as possible to allow easy customization and also updating you should not worry too much about what the end-user will do with it. He might end up adding lots of stuff that doesn't even follow your own guidelines, and this, of course might end up broken when an update is done. This happens every day I guess.

supermike's picture
Offline
Joined: 2006-02-17
So I Can't Charge For Manuals?

You know, I wonder if the FSF realize that if they keep blogging about their philosophy, expanding it into every realm, GNU/GPL developers may have absolutely zero sources of income. What will we expect next? I mean, will they say, "Spread the word. If a company is charging a fee for the distribution of the media that is more than the cost to make it, that's not GNU and not acceptable." I can't charge like $10 extra, even if it's downloadable for free on the web? Or will they say, "If a company tries to make more than $50 a month on other revenue surrounding the free software, that's not GNU and not acceptable." Should I also lecture on the software for free? I mean, c'mon.

I do plan to produce a sort of OK manual, but one has to realize that I've put 5 years of my work into this project, nights and weekends, while raising a family and with all the frustrations up and down about that. I've sweated blood over it. I had to convince my wife that I couldn't join her and the kids some weekends or evenings because I was embroiled in the thicke of a project. I had to convince my wife of the entire paradigm shift of why free software can have more revenue than non-free, and that took me having a startup company with proprietary software, which failed, to sort of prove it to her first. It took a lot to get her to turn around on that. She can be one cranky individual when it comes to cash flow. So if I want to produce two manuals, one sort of OK and then an elaborate one that's nicely bound and a pay item, why would the FSF think that's not my perogative? What if it takes me one year, nights and weekends, to build the elaborate one -- does the FSF want me to just forget about all that time and donate every little bit of my blood to the community?

One may also argue, "Well, you shouldn't have done that. You should have used a community to build it." Well, let me go back to Steve Jobs on that one. He once said something that made a lot of sense to me. He said, "Sometimes you have to build it your way before people realize your vision." And that's what I was faced with. I was faced with trying to forge a new path that others didn't see was necessary, and parts of it even I didn't see until I started to build it. So, yeah, a community is useful on some projects, perhaps even most, but not all of them.

I'm sorry to say this, but really good free software succeeds only when there is some source of revenue behind it. There has to be a revenue source somewhere in there, where it be the option to get the media burned to CD for you (just a very tiny profit), selling a rackmount server with it, selling an elaborate manual, charging for lectures at conferences for it, enhancement bounties, consulting, tech support, customizing it into verticals, delivering training, T-shirts and other logo gifts, hosted website, and so on. All of this -- just not charging for the software downloads and redistribution, and not charging for at least a halfway decent manual.

Halfway decent software like Gimp and Inkscape don't succeed because they can't find a sufficient revenue source behind them. If they could, then one would have an option to have an MDI interface in Gimp if they wanted (a large percentage of users do), and Inkscape would have an even more intuitive interface and far less bugs. They are decent software, and darn if I don't use them, but the developer groups behind them have like no incentive to jump on something now because 10,000 people think its a problem in their software or the right thing to do. Instead, they get around to it when they feel like it and have the free time.

This isn't also then to insinuate that free software that has a sufficient revenue model is going to be great software either -- surprisingly that's not true either much of the time. Take for instance SugarCRM. It's a multimillion dollar, profitable company, but what I hear is that the product is a bear to install.

So to conclude, I disagree with this blog statement at FSF. I think there's a case for charging for elaborate manuals that are bound and include lots of pictures and diagrams, and it's our perogative as GNU devs to produce a halfway decent free manual that's good enough to get by on in most cases. The FSF should not continue seeking to find ways to squelch all alternative revenue sources from free software.

libervisco's picture
Offline
Joined: 2006-05-04
I think there has been a

I think there has been a misunderstanding.

I completely agree with you that having a revenue source behind Free Software is required to push it further into expansion. The revenue source is simply different with Free Software.

Your manuals, nor even software, doesn't have to be free of charge to still be free as in freedom. You can sell a distribution service, be it over the net or offline, through which people can get it with all the extras you offer that other distribution channels don't.

Your printed manual can be one of the things included in this price. Even if it is licensed under the Free Documentation License (GNU FDL), this is possible, because FDL doesn't forbid you for charging for a distribution in any form just like GPL doesn't forbid you from charging for the same. The only thing they make sure of is that once the customer buys your package he'll be able to share what he purchased with other people around him.

Sure this also means they'll be able to share it online hence seemingly "stealing" your revenues, but this is not the case. You can look at that kind of sharing as your viral marketing campaign. Some of those who will get it for free from others will like it enough to pay you for a premium package next time around (next version or so).

Why is your package "premium"? Well, those who will share online certainly wont be offering a printed manual because it is not as easy to copy. You will. Those who share it online can't offer support the way you can. And they can't always provide the very latest version with all security patches, which you can. By all means you as the original source would be valued more than those who just share what they already bought from you.

This is very similar to the RedHat model. People share RHEL in full in form of CentOS and White Box and yet instead of impacting RedHats sales negatively this seems to promote them. Of course, RHEL doesn't make it very easy to get precompiled binaries of their stuff. They only offer the source, but that is all they're required to offer anyway.

free-zombie's picture
Offline
Joined: 2006-03-08
to state a simple point

Go on, sell the manual - that doesn't prevent freedom.

The manual beeing free means that once someone has purchased it, they have the right to share it, improve upon it, burn it, etcetera. If you publish a book, you'll always have people scanning a few pages for friends or quoting elaborately - what the FSF says is, basically, that this is perfectly natural and you can just endorse it.

I haven't read the FDL recently so I don't know whether it involves machine-readable copies or something.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.