As someone who has used lots of open source software, in fact making my livelihood off of open source software, I’ve often wondered what happens when the guiding forces behind an open source project decide to make that project closed source? Under what circumstances is that even possible.
I’m the lead developer for my simulation baseball league’s web site. That is a very small venture, so I often say no to requests for additions and changes because, well, I can. It’s okay to be an asshole sometimes instead of just bottling it up all inside. Sometimes I don’t feel like putting in the work to implement certain functionality. Or I don’t feel like the request adds anything to the web site. But if I were the lead developer for a fairly large open source project, I’m pretty sure I would get to some point where the complainers and moaners would get to me and cause me to want to consider closing the source. It’s an easy thing to complain about a bug or missing feature, but it takes real courage to complain *and* go and fix it, showing why and how you fixed it.
So, what would happen if you closed the source? I guess you’d say that you would still accept patches but nobody could distribute or implement those changes without your permission. I believe that Dan Bernstein does this for his immensely popular qmail project and explains that qmail is not open source. I also imagine that the license you release your code under would have a huge impact on this as well. If you took something close sourced, what about all the changes that others had contributed while the project was open sourced? Are they out of luck? Do they remain in the closed source with you giving them credit? Many, many questions to be answered when taking an open source project closed.
The key feature of open source, to me, seems to be that you can get the source, change it, and then distribute those changes. There is nothing wrong with you taking an open source project, make a bunch of your own changes and then using it yourself without distributing those changes. That’s how a lot of cool functionality ends up in an open source project. I seem to remember the systems group at a previous employer hacking on qmail and making some changes to it that were only used internally and, although I am not a lawyer, I can’t imagine that being a problem. Distributing those changes to others is a different story, as that would appear to violate the license that qmail has been released under.
The perception on many open source projects is that the leadership is running things like a closed source project by limiting access to people to commit their changes to whatever central version control repository they are using. Is that a bad thing? I would have to say no because when a project gets to a certain level of complexity (such as, say PHP itself) you don’t want just anyone going in there and making changes that would cause things to break all over the place. CakePHP does exactly that: there is a “core” team of developers who have write access to the subversion repository, and they either change code themselves or go over patches submitted by others, committing them if it’s agreed that the patch fixes a problem.
From my own perspective as a developer, I don’t know if I would stop using an open source application if it would go closed source. As long as it continued to work the way I needed it, I don’t think I would complain too much. But if I needed to make changes and are skilled enough to do so, that’s when it would become really annoying if there was a bug I could obviously fix but have no access to do so. My experiences with some PHP applications that were encoded using IonCube showed me how much time and money was wasted trying to get problems that could’ve been fixed in-house. That’s as closed-source you can get in the PHP world.
Tell me in the comments your thoughts on taking an open source project closed and what you think the ramifications of that would be.
I think that the cakePHP project is in need of some “core” team members who are public relations, marketing, and design-minded, rather than programmers. Having those sorts of people on your team increases your exposure & the bottom-lines of all those heavily involved in the community, not just the “core”.
Also. I would stop using cakePHP the minute it went closed source.
@Walker: What am I, chopped liver?
I’m doing all I can to help out with the public relations and marketing side of things via this blog. I think part of the problem is that the PR, marketing and design types aren’t really attracted to a web application framework project. After all it is for developers. Most of the core guys just don’t blog as much as I do, but they are all passionate about wanting CakePHP to be as good as it can.
I also would stop using cakePHP as soon as it goes closed source. Even if it is just going half-closed like SugarCRM or xt-commerce. There are just too many other good frameworks out there that this would make it easier to choose one.
I also think that the cakePHP should work on the way it presents itself in the public. Some examples I don’t like are the common:
- “use 1.2 because thats where all the features are, but there is no documentation” (the only reason this works it because cakePHP is open source) or one very common from the google group:
- “You are stupid to not understand how this works”, even for the same questions over and over again. I think if the users don’t understand something which seems obvious to you, maybe it isn’t that obvious and the API/doc needs some work
@Christof: Well, it’s not there is no documentation for 1.2. It’s just that it’s all over the place: in the google group, in the Bakery, and various blogs. 1.2 is very stable for “alpha” software and contains so many new features that I can’t imagine having to use 1.1. A lot of the questions people have could be answered via the manual or by searching the google group as well. I don’t ever tell someone they’re stupid, unless they are being deliberately stupid or deliberately off-topic in the mailing list. I guess I have a certain level of expectations for users before they ask a question.
I think that by using central version control repositories, we are forcing all development efforts to go through a bottleneck called “the core team”.
I would consider using distributed version control repositories.
By using distributed repositories, anyone could benefit from everyone else patches. If someone makes a fix or add a feature, he can check it out. If the core team likes a feature/fix, they could also check it out to the official repository.
We should not stop developers from commiting code.
I am fairly new with cakephp, but not so new at open source programming. But there is one thing that i know is once a open source project has been started and have a good following it takes on a life of its own. So when you say things like closing the project, you are basically killing it. Figuratively speaking.. BTW everyone working on the cakephp team is doing an awesome job, i think i saved myself at least 12 months of work useing cake, keep up the good work.
@Walker, @Christof: why all the talk of CakePHP closing its source? CakePHP is, in my opinion, a great example of a well run open source project. Lots of discussions, lots of contributions. The idea that it would go closed source just seems to me to go against everything that the project stands for.
Walker and Christof, then why not just stop using CakePHP now? Clearly, it has no value to you other than the fact that is free.
Is there a direct correlation between people who contribute to a community and people who would stop using the open source project from that community, if it closed its source?
Hopefully, you see my point that “value” is part of every decision. Many people are free riders, choosing to capture all the value for themselves. Some people contribute back, realizing that they can derive even more value that way. I assure you that CakePHP would continue thriving without the free riders. They do nothing to make CakePHP or the community better.
Our hope is that people will find value in CakePHP not because it is open source, but because it makes life more enjoyable. Clearly, I am a bit idealistic as the expressions of Walker and Christof lead me to believe otherwise. Luckily, there are other members of the community that do derive value from CakePHP and contribute back. That is what keeps us going, and that is what ultimately allows the free riders to continue. I try to take the good with the bad and stay positive.
In any case, no one said anything about closing CakePHP source.
@FallenJehova: I don’t have any experience with distributed version control systems like you describe, but I think the idea of people just being able to add code in without it being vetted (for lack of a better word) by people who are more familiar with CakePHP is an idea that wouldn’t get much traction. It’s more about the direction the project needs to go in terms of features.
@Eric: nobody is talking about closing the source to CakePHP. I happen to share your opinion that if you take an open source project and move it to closed source, then you are killing that project.
@gwoo
I’m going to disagree with you a little on this one. Many of the so-called free riders are the user base. They may not have the skills or the time to contribute up front but by using the product they are definitely a supporter. Granted some seem to think this includes free user support and the right to whine.
We all have our passions and pursuits and we developers are very grateful that the core team devotes their time and energies to cakephp. That allows us to pursue our directions and on occasion contribute something back not only to the project but also to the greater open source community.
@all
The license of a project is a definite factor in my decision-making process. I strongly prefer open-source and would migrate away from any project that closed its source. My opinion is that the user community would collapse unless/until the project gained traction with a new set of users.
@Chris Hartjes : I understand that nobody is talking about closing it which i am quite glad of
since i just bake a cake addict like over night.
I would have to agree with you on a project always need direction on terms of features that will go into that release but i do not think it is necessary to close a project to do this. Also the person taking advantage of this tool, looses the flexibitility he/she had when it was open source.
My2Cents…
@Gary
good points, but when i was referring to the free rider it was a reference to “actors who consume more than their fair share of a resource, or shoulder less than a fair share of the costs of its production.” (wikipedia) In the open source world the complainers, whiners, moaners, and those not offering constructive criticism, would be considered free riders. On the other hand, Supporters and those offering constructive criticism consume their “fair” share and would not be considered free riders.
Free riders drive up the costs because time is spent explaining, defending, arguing, among other things that would take away from and not contribute back to production in any positive way. Free riders affect the share that is available for everyone us, thus driving up the costs. In open source terms, this means that the supporters see fewer releases, fewer new features, and fewer bug fixes.
One of the advantages of open source is that the available resources generally outweigh the costs associated with free riders. You lose this advantage when you close the source, as resources are limited by the costs the supporters are now willing to carry. They were carrying many of these costs before but with the resources limited they will have to pick up the slack. At this point could you offer some added value to supporters that would make them want to carry more of the burden?
Maybe there is a hybrid model; open source, closed community. Registered supports gain access to the code and community resources. They may be free to use it and distribute it but only these registered supporters would be allowed to contribute back. If a member approached the status of a free rider, they would be flagged and potentially removed from the community. The community can police itself and ensure that everyone is deriving the maximum value.
@Chris Hartjes
sorry about the long comment, but your blog post was really interesting and brought out some equally intriguing comments.
@gwoo
Never apologize for long comments, as we have had IM conversations that have lasted a lot longer than that. Your hybrid model is an interesting one, but one that I have a few issues with (and we talked about this via IM). I don’t think it’s better than, say, what CakePHP has. It’s just different. It’s like the core PHP developers group: a number of people who have been trusted to make solid contributions by proving they can make solid contributions through patches. In a way we already have that in CakePHP by having the “CakePHP development team” that is invitation only and merit-based.
Here’s great article, “10 golden rules for running an open source project” the cake core team should read it. It’s written by Greg Beaver (PEAR and other projects)
http://greg.chiaraquartet.net/archives/171-10-golden-rules-for-running-an-open-source-project.html
@Beth – I think Greg’s rules are good ones…but if you’ve been part of the CakePHP core devlopment team I don’t think you can say that it’s not being run properly. PhpNut runs a tight ship because he wants things to be done right, and he doesn’t believe in babying the people who want to contribute to the project. The problem with Mr. Beaver’s rules are that they are easy to talk about, difficult to implement. Geeks don’t always have good social skills, and good social skills are the key to a great open source project.
Hi Chris,
I never explicitly or implicitly inferred that the cake was “not being run properly”. The point of the link was to merely share Greg’s insights based on his experiences.
There are too many other good frameworks out there that this would make it easier to choose one.
You should try Akelos Framework, it’s growing fast.
http://www.akelos.org
For the love of God people, chill out. As much as we like to complain about freeloaders, we have no plans to close the source.
However, the sad truth is people, good developers in the PHP community can be pretty hard to find. My reasons for saying this are both statistical and anecdotal; i.e. some of the retarded patches we get.
So yeah, we keep a tight lid on things, and for good reason, trust me. But no, we are not closing the source.
And Akelos? Seriously? At that rate I might as well just use Madeam.
@Nate: As someone who has used both Akelos and Cake, I would take Akelos seriously. Their codebase if far much better than Cake 1.2, so comparing it to Madeam seems like a response built upon ignorance.
I think the Cake core team should have a have a look into Akelos source to learn a little bit more about why Rails is getting more popular day by day (making things easier for almost everyone using though assumptions on default options). As Fabio Cevasco suggested in his blog some time ago, Cake should learn from Akelos and viceversa. I add that we core developers should learn from Rails and Django as well.
[Insert clever reply here]
Bog, no offense but you shouldn’t be trying to promote your framework here.
@Dante: On what do you base your statement that Akelos’s codebase is “far much better than Cake 1.2″? I’d love to hear why.
@Chris Hartjes: I’ll tell you the differences I see from a RoR addict and PHP background.
Akelos is is far closer to Rails than Cake is. The methods and parameters are exactly the same for most tasks. I know Cake core team is proud of their clean IP, but I want to learn just one framework that makes sense and that Rails for me. Whenever I have to deal with PHP projects it is easy for me to use Akelos.
Regarding implementation details, let me go into detail on the Active Record implementation differences between Cake and Akelos. This are the things I’ve found at Akelos and could not find in Cake:
* Single table inheritance
* Optimistic locking
* Calculations like min, max, average, sum …
* Acts as list and nested sets
* Transactions. How can be that such a popular framework like Cake doesn’t have transactions? Akelos even wraps association operations inside transactions.
* Real validators not simple regexes
* Triggers/Callbacks, before/after every action
* Migrations for distributing DB changes using subversion
That as far as it goes on the Active Record side without getting into detail on how associations have been implemented in Cake, but it might be as different as the base Active Record.
Regarding internationalization Akelos is unique, Rails should have something like Sintags (their template language) for internationalizing. Other lovely thing about Sintags it that you can use Ruby code in the views like ‘person’, :action => ‘edit’ %>
I think those are good reasons for the Cake’s core team to have a look into Akelos code, which I’ve just realized that has examples in their source that are written in Ruby… :/
@Dante
I think you are missing a key point: CakePHP is not trying to be “Rails for PHP”. It’s just trying to be CakePHP. Like any open source project, features bubble to the surface based on time, need and desire.
@Dante – I have a programmer who likes to torture himself – he is trying to develop an application using Akelos believe me till he had not submitted a patch a basic HABTM wouldn’t work.
But yes to Bermi’s credit he patched the source up pretty fast.