Currently, there is a very valuable discussion going on on the rsyslog mailing list on how we can attract more contributors and how moving things to github can help with this. I was writing a longer reply, and then it occured to me that it probably is better to blog about this topic as it may be of future interest to have the current thinking (relatively) esay accessible.
The core question being asked is “
Would it make more sense to leave all that sort of info in one place instead of pulling people from the *official* rsyslog repo on *github* over to *rsyslog.com*?” Then, it had some examples of how logstash uses github README files for that [full text
here in the rsyslog mailing list archives].
These are my thoughts:
I don’t object placing a bit more into readme and related files. However, while this one of the official repos*, it’s not the official *project site*, so I think it makes sense to ask people to go to the project site for anything that’s non-trivial. Looking at the logstash things, to me it pretty much looks like they do the same thing. I have absolutely no problem putting the same information into README-like files inside the repository, as long as the authorative pages reside on the official project web (and yesterday I have begun to do so).
In essence, the question boils down to “
why don’t I want to be locked in into github?” It’s (bad) experience. When rsyslog started we used sourceforge.net intensively. At that time, it was as popular and the place to be on” that github is today. Then, they got some crazy biz ideas, got technical and other problems and … it really turned out to be a mess and bad for the project.
Also, we used Freshmeat for most of our public announcements around the same time (a bit later, and partly togehter with sf.net). All went extremely well, until out of the sudden they had the bright idea of a “redesign” that made the site unusable. Again, bad hit for us.
I really don’t want to see this again. If I use github exclusively, I have no chance to redirect things if they go crazy. I have a hard time moving on to the next hot spot when it is born (because all the Google juice is with github).
I admit that I would like to have the buzz of “I tell you this is an active project, I can judge by the number of issues opened and closed (and so on)”. But at the same time, I remember that this type of entanglement always turned against us after some time.
For example, I tend to file the bug number (actually a link to it) in both commit comments and the change log. If I now link to sf.net, github, etc and they “go away” (some way or the other), all of these links become invalid and I don’t have a chance to fix this (again, I’ve actually experienced that, so it’s not pure theory). And such things happen. For a non-rsyslog example, think about the bitkeeper debacle, where they out of the sudden thought it was due to charge kernel developers for so-far free services.
Again, I would really like to have some of the cool things. With git, it’s relatively safe, as I can move the repo around quickly, and as long as the rsyslog.com site contains the main pointer to where the current official git is, the risk is very limited. But other than that, my experience is that the short-term benefits come at the risk of severe long-term problems.
I am open to really good arguments why I am wrong. One good argument would probably be an OSS complete hosting service that is in place for 15+ yrs without any interruption in user base and breaking URLs – and that is still a hot spot. I guess sf.net mostly qualifies in that category, but as I said, we had our own story with them…
I frankly admit that I am very conservative in this regard. After all, I even post things like this on my personal blog, and not on a site directly owned by Adiscon. But, you may say, you use blogger, so don’t you take a risk here? Well, you probably have noticed that I use blogger under a domain that I have full control over. So whenever they go crazy, I can move on to some other place (not totally effortlessly, but I am in control of those things).
