I notice that some parts of OGS (mainly the front-end) are on GitHub under free / libre and open source (FLOSS) licenses. This is great! Are there any plans to make all of OGS (i.e. the back-end too) available on FLOSS licenses? If not, are there any specific reasons why not? I think making all of OGS available on FLOSS licenses would be beneficial for both the developers and the users because enthusiastic individuals (like myself) would then be able to contribute features and bug-fixes that are too much for the development team (which, as I understand it, is pretty much just one person). Then we might be able to sort out, for example, the ladders bug(s).
This has been proposed several times. I believe it is a “one day” item.
As I understand it, there are two main reasons the back-end is not on GitHub with the front end.
The current code base is a jumbled mess, and far too tangled to explain to someone not already familiar with it.
If an error / bug is accidentally introduced in the front end, potential for damage is limited and rollbacks are more or less trivial.
2a.
If an error / bug is accidentally introduced in the back end, potential for damage is site-wide and rollbacks are potentially exponentially difficult depending on what broke and why and what ripple effects that has.
highly doubt anoek would let anyone other than himself rewrite the whole server in a completely different language, if indeed he has any desire to move away from Java in the first place
TN. This thread is not the place to discuss “my favourite language is clearly the best and all others are horrible because…”
This is quite a concerning problem given that it is currently a one-person development team. With everything resting on one person’s shoulders like this, a major existential risk to this server is anoek getting an amazing job offer that he can’t refuse (which is far more likely than the literal “bus factor” risk). As he is a proven full-stack web dev, of a site with quite high visibility and many users that have day jobs across various “tech” companies, this site must only still continue to operate because he turns down many great offers from numerous recruiters on a weekly basis.
This is a good argument for thorough testing and quality control before deploying updates, which could actually be improved by expanding the development team. A good way to work new people onto a complex project is to have them start with only testing/debugging rather than developing new features. This helps them to better understand the code before they make potentially erroneous changes, and they can even help with improving documentation and organization along the way.
Ideally, with a larger team, each update can be more thoroughly tested on a beta server, which would reduce the risk of major bugs affecting the production server.
matburt still has access to the backend, he’s just too busy currently with his day job to help much. anoek is only effectively a one person team, not literally.
Given that he left an objectively better job to come do this, I would posit the risk is low… but even if this did happen, either he or matburt could dump everything they have on GitHub if neither had the desire to continue and let someone else sort it out… once it’s not his problem, he wouldn’t care about the potential problems of such an action.
This could all well be true, but it is a huge undertaking, and during the process anoek would be pulled even further away from adding new features than he already is.
AFAIK anoek has the desire and the intention to one day open source the back end… but it is a huge project that he needs to carefully consider the time and resource commitment for before beginning, not just of the project itself but for the daily processes of the site going forward
At the end of the day, my main concerns are not so much about the open vs closed source aspect, but rather the one person team factor. Expanding the team could also possible while keeping the source closed.
I really hope that something like this won’t be the way it happens, since combined with this:
It would seem that the current developer(s) suddenly leaving the project (even if they threw the code on GitHub) would also lead to a quick demise of the site.
It would certainly take substantial time and effort to ensure the longevity of the site, before the current team would move on to other things.
I don’t see any reason why current functionality would suddenly break overnight. The challenge would come with the desire to change things, either fixing bugs or adding new features.
I don’t know exactly myself, and it probably wouldn’t just happen overnight, since most things are automated, but as you even alluded to earlier, operating a site is more than just making changes to fix known bugs and deploy new features, but also managing the daily processes of operations and putting out the unexpected fires as they come about. No software exists in a vacuum either, and complicated code with lots of dependencies needs to be constantly maintained just to keep it compatible with other systems being updated.
Sounds you like need a quality rewrite anyway then.
(I am not volunteering, by the way. I know that this is at least 2000 hours.)
It is my 6th sense that I have developed after working with Java for x years. Every time I see “error submitting move”, I get flashbacks of “top” displaying 100% in a black and white Linux shell, the SSH session becoming unresponsive… the horror, the horror…
“If the only tool you have is a hammer, then every problem looks like a nail.”
I can see why one does not simply throw code at github and call it a day. Here’s me trying to come up with reasons:
Still applies to closed source as well if you wanted to grow the team so moot point. Messy code either way. At least with open source you dont need to explain anything because often the first time the original author even hears about a new contributor is when they’re submitting a pull request for a problem they fixed. As time goes on even the original author will forget how the mess works. Messy code is a lame excuse.
Probably the backend is a bunch of cron jobs, shell scripts, programs, databases and random services held together with duct tape? And they forgot what all is where and are not sure what to open source as it is not a single piece of software. They could package the whole setup to be conveniently shared but this takes time.
Then there is the reason of having been lazy and hardcoding FTP passwords, directory paths and database logins. Gotta go through the code and see if there is any private stuff accidentally left over. I admit I sometimes do this for my quick hackjobs and later regret it when I wanted to make it public.
And theres the bureaucracy stuff. You need a license, which license do you use? If you copypasted something from a commercial codebase or used a proprietary library or some binary blob you probably need to delete that and write a replacement component. Takes time.
Or maybe a personal thing? No one wants to have their name associated with messy bad code.
I like to use the “messy code” excuse myself precisely because I’m way too embarrassed to bring my terrible development practises to daylight. Heck, maybe I even put the passwords in plaintext. Gotta fix that first.
This argument applies equally to both closed and open source. If you want to be safe you better test the backend upgrades meticulously no matter if its open or closed.
The power of open source is the amount of eyes finding and fixing problems. If anything, less critical bugs. Open source does not mean that anyone gets to mess up the codebase however they like. The core dev is still responsible.
I think the real argument is that the core dev has to sift through a lot of code and double check and test the contributed code. This may be too much work. So you’d need a bigger team of trusted developers to deal with it. Or piss off the community by letting their patches linger around forever before being accepted. In some projects that takes several years.
Both very good points, but now suddenly, on top of all your work, you have to manage, coordinate and train the new team as well.
Apart from the time this might take, which is an obvious issue, there are two main factors that should be taken into consideration in such an undertaking: a) The person that has made the code is automatically the leader and the instructor of the team, but the position does not come with the automatic acquisition of the skills, platience and charisma to fulfill those roles. b) You are going to have a team consisting of people with a similar hobby and some similar knowledge in programming, but at the end of the day those people are a heterogenous group which will have to be screened to test if they mesh with each other well. Having the talent to do something, doesn’t mean that you automatically have the willingness and the character skills to work in concert with a team of other people to achieve that goal.
If a project originally consists of, let’s say five people, then one of them could go “Hey, I’ll be in charge of making the project open source and find and filter and coordinate the new guys. The rest of you, keep working as usual” and that way a project keeps rolling along, while trying to expand with the open source influx of contributions.
But if it is one person, then that person has to stop or severely reduce the time he invests on the project, in order to accomodate the passage to “open source format” and deal with the aforementioned problems, and that simply doesn’t seem very practical, unless, as someone else already mentioned, the original developer wants to move on/away from the project soon.
hopefully one day