Please open source all the things

[wXR]

Open eXternal User Interfaces (OX) is an Open Source Amiga OS GUI Library written 100% in Assembler

http://eab.abime.net/showthread.php?t=71692

Checking about license, none included in the archive from what I could see.

[Korodny]

Originally Posted by phx

So I don't understand the questions about merging it with other licenses or re-releasing it under a different name. Of course you can! It belongs to the public.

You and I share the same definition of "Public Domain", and we are able to share our views with each other in this thread. The situation is a lot less clear if you find some piece of code somewhere, the email address is no longer working and you have no idea how that guy defines "Public Domain".

I had to fix thousands of Aminet readmes in the last decade, I've seen a dozen different definitions of "Public Domain", including "pay me if you like it" or "don't use it in a war or for producing weapons". There's no piece of paper out there containing the definite version of "The Public Domain license".

I didn't want to make such a fuss about it though. Let's just say it makes things more clear for everybody if there is a "proper" license. The BSD license or Creative Commons Zero are pretty much the same as "Public Domain" - and they're well defined.

I didn't know that. I really would like to understand the reasons behind such a stupid law...

I think the intention was to protect the artist from greedy publishers or art dealers. It's useless of course, since you can simple exclusively license all our rights to some 3rd party instead. But it keeps lawyers busy, so I guess it fullfills a purpose

[Mrs Beanbag]

Open source might be very good for certain projects that would benefit from widespread collaboration. But sometimes the author is tempted to think of the software as "my baby!" Well i know that feeling.

I had a mind to release the Mr Beanbag source code along with a special edition, after i finish it (yeah yeah, if...) although not for free, and for personal edification only. But i do hope to release the game engine with an API so others can benefit from it (maybe with interfaces for AMOS and Blitz Basic as well as Asm).

[Amiga1992]

Originally Posted by strim

Proponents of open source need to realise one important thing. Just opening everything does not magically solve the problems of our community. Sure, it often makes things easier, but the most important thing is getting people involved.

So much this. Totally agree.
I think some programs are better off starting as open source, stuff like drivers, utilities, operating systems, technical/utilities stuff, but others, like specific programs and games, do not benefit from open sourcing. Why? Because even though I am sure open sourcing a project can benefit the code of the program a lot, the concept and goal/s of the program will not.

We've been asked many times about open sourcing PT-1210 and my reason not to do it is not selfishness, it's not commercial value because we don't sell it, and it's not because I am hoarding some technical prowess in the code that I want no one to have. It's just that I like that it is a program I made with a friend while in complete agreement, all the time, as to what it is supposed to do and how, and I want to keep it that way for as long as we feel like we can keep working on it. I am not sure about Hoffman's view on the subject but I would guess it's similar.

In a program like mine, lack of focus on the concept would have yielded a program that was never released in the state it is now: something that does everything we wanted it to do and works in 80% of scenarios (because, of course, has bugs, but functionally, it's 100%). Open source programs usually give me the idea that they are an eternal work in progress that never gets finished and that doesn't work for things like games.

phx released his source code to Solid Gold but ONLY after he finished the game. It is meant to be for people who want to learn upon it and create their own thing based on it
His game is finished, and that was only possible, I think, because he worked with his team closely and focused until they finished the game. If they had opened it in the middle of development, the game would have never been finished.

As much as we need open source programs in many aspects of the Amiga world, we also need a lot of people like phx or Mrs. Beanbag who will work on one project, with focus, until completionof their programs.

[wXR]

Originally Posted by Akira

So much this. Totally agree.
I think some programs are better off starting as open source, stuff like drivers, utilities, operating systems, technical/utilities stuff, but others, like specific programs and games, do not benefit from open sourcing. Why? Because even though I am sure open sourcing a project can benefit the code of the program a lot, the concept and goal/s of the program will not.

What about open sourcing a program removes the rights you already have to control your branch, which will almost certainly be the primary one?

Originally Posted by Akira

We've been asked many times about open sourcing PT-1210 and my reason not to do it is not selfishness, it's not commercial value because we don't sell it, and it's not because I am hoarding some technical prowess in the code that I want no one to have. It's just that I like that it is a program I made with a friend while in complete agreement, all the time, as to what it is supposed to do and how, and I want to keep it that way for as long as we feel like we can keep working on it. I am not sure about Hoffman's view on the subject but I would guess it's similar.

Again, nothing changes about that. There is no requirement for you to accept peoples' proposals (as it is presently), nor their changes to the code. The concept of branches -- and especially forks -- are good to be familiar with. Additionally, the concept of a "pull request" is such that another developer can say 'hey, I made these changes, you can add them in if you want to'. Nothing is mandatory.

Originally Posted by Akira

In a program like mine, lack of focus on the concept would have yielded a program that was never released in the state it is now: something that does everything we wanted it to do and works in 80% of scenarios (because, of course, has bugs, but functionally, it's 100%). Open source programs usually give me the idea that they are an eternal work in progress that never gets finished and that doesn't work for things like games.

There are plenty of large game projects that are open source, you just have to look around.

https://en.wikipedia.org/wiki/List_o...ce_video_games

While you're not likely to find a new AAA game open sourced this way, recently even Unreal Engine 4 took on this direction.

http://blog.gsmarena.com/epic-making...n-source-free/

But you're right, open source implies (given the developer interest/built community strim mentions) eternal development -- that's rather the point. It does not however, imply no releases. That's up to you.

Originally Posted by Akira

phx released his source code to Solid Gold but ONLY after he finished the game. It is meant to be for people who want to learn upon it and create their own thing based on it
His game is finished, and that was only possible, I think, because he worked with his team closely and focused until they finished the game. If they had opened it in the middle of development, the game would have never been finished.

As much as we need open source programs in many aspects of the Amiga world, we also need a lot of people like phx or Mrs. Beanbag who will work on one project, with focus, until completionof their programs.

Agreed. And it's up to the developer, of course! But I certainly think this can work well, both ways. When I look at the thread about the Rygar conversion capers, etc, it's obvious that there are enthusiasts who will gladly contribute work to good projects. That's motivating / educational / exciting for everyone.

NewsRog:
http://sourceforge.net/projects/newsrog/

BlitzBasic:
http://eab.abime.net/showthread.php?t=8587

[Mrs Beanbag]

Originally Posted by wXR

While you're not likely to find a new AAA game open sourced this way, recently even Unreal Engine 4 took on this direction.

Of course it is possible to open-source a game engine but not open-source the actual games.

[kamelito]

Well John Carmack and others did just that. The Zenimax acquisition of ID put an end to this though
Kamelito

[Amiga1992]

Originally Posted by wXR

What about open sourcing a program removes the rights you already have to control your branch, which will almost certainly be the primary one?

The whole idea of "my branch" and "other branches" is exactly what I want to avoid. I don't want it to branch out. It's fine as it is. Just one.
As I said, code-wise there's probably a lot of benefit in letting it out in the open, but concept wise, there isn't.

My opinion i that coding-wise I wholeheartedly agree with you, but concept-wise I don't. The kind of program I am interested in working on is not just about code, probably, is mostly not about code!

[commodorejohn]

Not to mention that forks are never developed in isolation. If you release the source to a project that's still ongoing, you're going to get called upon by anybody who has an issue with it while you're still trying to get it sorted out yourself. (Yes, it can also mean more manpower for debugging or even development, but there's still an issue of organizational complexity, because changes don't get cleaned up and merged by the power of magical pixie dust.) Even if you're planning to open-source it eventually, I can see the sense in holding off until a later alpha or early beta.

[wXR]

I think you guys make fair points, although I would mention about the point about "concept" in particular: You are by no means required to accept anyone else's conceptual alterations, or even to pay them any mind. What "Freeing" your software means literally, is that it can outlive your vision, your personal interest, and perhaps your very life.

Well, if all that comes of this in the end is that you guys end up properly licensing and releasing the source of software you're no longer interested in maintaining, then I guess we have made some progress.

Originally Posted by Mrs Beanbag

Of course it is possible to open-source a game engine but not open-source the actual games.

I posted a Wikipedia link to an enormous number of games -- not engines -- that are open.

[Vot]

I think people also need to consider that not only software projects should be open sourced but also hardware projects. Look at the great projects that have come from others (kippers ide boards from the ide68k and a608 projects) and the problems that arise when they don't. I.e the cortex floppy emulator that is great but has bugs and is receiving little/slow development. Not to mention the fpga projects that have built on others.

[wXR]

Originally Posted by Vot

I think people also need to consider that not only software projects should be open sourced but also hardware projects. Look at the great projects that have come from others (kippers ide boards from the ide68k and a608 projects) and the problems that arise when they don't. I.e the cortex floppy emulator that is great but has bugs and is receiving little/slow development. Not to mention the fpga projects that have built on others.

That's right. And again, we have Sakura showing how this can be done.

http://eab.abime.net/showthread.php?t=75417&page=1

https://github.com/Sakura-IT/decelerator4030

I don't know if strim has received any input to this project yet that came about specifically as a result of it being open source, but there's no doubt that this can serve as a great point of study for anyone wishing to make an accelerator card in the future.

[strim]

Originally Posted by wXR

Wow that's pretty neat. Can you share the setup for that workflow somewhere?

It's no magic actually, just careful planning.

From my experience, if you want to develop something in an open source way, you need to make the whole workflow as painless as possible. If your environment is complicated for the developer, it will result in rare code releases (think decelerator4030 :P). If you need to do some special things just to get the code out, it's a waste of time that could be spent on actual development.

With Sonnet project we wanted be able to build it on both AmigaOS and UNIX-likes. We also wanted to do proper code versioning _and_ to be able to share it publicly, just in time, as it is developed.

This required selection of appropriate tools, to make it as automated and convenient as possible. First, linker, assembler and so on (sonnet.library is mostly written in assembly). The only actively developed suite, that works both natively and for cross-compilation is vasm/vlink/etc. tools by phx. The alternative would be GNU as, ld, etc. but they aren't getting much Amiga love recently and are just huge. Also, phx being an Amigan, happily added more features as we requested them .

Other requirements are minor, like GNU make to build the whole project and the required include files that sonnet.library is depending on (AmigaOS NDK and WarpOS includes).

When it comes to code versioning workflow looks like this:
- Let's say on Amiga I am developing the code, I write, write, write
- Once I am satisfied with the result I do "cvs commit", which sends the updated code to CVS repository on the UNIX server (there is a nice Amiga port of cvs client done by phx), naturally this requires the Amiga to be connected to the internet.

And that's it! Couldn't possibly be simpler.

The rest is done automatically:
- There's a cron job on the CVS server that checks for new commits every 15 minutes.
- If there is a new commit, it runs a script that calls "git cvsimport", which updates the local git-converted repository with latest CVS changes.
- Then the changes are pushed to GitHub with "git push".

Additionally we have a script running on the CVS server that checks for commits and tries to do automated build of the whole project. So we can almost immediately see, if the commit resulted in some regression. The build results are shared via web then. In a modern open source projects this is called "continuous integration" and is nothing unusual really.

The actual build procedure for sonnet.library is laid out in TOOLCHAIN file.

Note the focus on simplicity for the developer. It works so well only because it is painless. If I had to manually move the code to PC just to commit it, I just wouldn't do it - I am too lazy.

[wXR]

Here's something cool -- Cahir / Whelpz & Ghostown has released his demo sources here, which apparently includes "Sunglasses at Night":

https://github.com/cahirwpz/demoscene

[wXR]

Originally Posted by strim

When it comes to code versioning workflow looks like this:
- Let's say on Amiga I am developing the code, I write, write, write
- Once I am satisfied with the result I do "cvs commit", which sends the updated code to CVS repository on the UNIX server (there is a nice Amiga port of cvs client done by phx), naturally this requires the Amiga to be connected to the internet.

How about pulls back into the local CVS repo, in the case where your co-conspirators have been contributing as well? Any issues with conflict resolution this way?

[strim]

Originally Posted by wXR

How about pulls back into the local CVS repo, in the case where your co-conspirators have been contributing as well? Any issues with conflict resolution this way?

Currently this works one way only. Everyone that wants to directly contribute needs an account on the mentioned (private) CVS server. There are only two developers now (Dennis and me).

Of course it does not stop anyone from forking the GitHub repo. Just that if someone does a pull request on GitHub, I'd have to integrate it manually into CVS source. Not as much of a problem as it seems, since you can easily convert pull request into plain diff and then apply with "patch" command (even on Amiga). And I almost never apply pull requests without modification, even where CVS is not involved, since I am picky about style and correctness (so I always mess with them anyway).

The real solution would be porting git client to OS3 (I'm not doing that ).

[Korodny]

Originally Posted by Mrs Beanbag

Open source might be very good for certain projects that would benefit from widespread collaboration.

That's one aspect of open source, but not the main one IMHO. Especially in our community, where big projects are the exception and you seldom need lots of contributions from outsiders.

Open source is about sharing, IMHO - that's why I prefer the term "free software". You give something away to help others: Reading other people's code is the best way to improve your own techniques, other people might have a use for some clever routines you wrote...

phx released the sources of his finished game project. He doesn't benefit from this directly - but others certainly do, given how there are several threads on here where people are trying to understand what he did or using his code in their own projects. phx, on the other hand, might benefit indirectly from the general mindset of sharing stuff with others - e.g. he's running BSD as his main operating system (IIRC).

But sometimes the author is tempted to think of the software as "my baby!" Well i know that feeling.

I understand the reluctance, we all grew up with home computers where "free software" means "cracked software" - i.e. software always was someone's property, and others were out to steal it.

But in my experience, it doesn't work like that. It's not becoming less of "your baby" by open sourcing it, because people don't just pirate open source code. Somebody might port it to a different platform (less likely in the case of an ASM project, of course), or use parts of it in his own project while properly crediting you. What else could happen?

A real problem bedroom coders might encounter is academically trained professionals badmouthing their code, the way they name variables or how they interact with the OS. I did witness a coder or two getting annoyed with less polite feedback.

[Korodny]

Originally Posted by wXR

Open-source dos.library:
http://eab.abime.net/showthread.php?t=60181

Open-source graphics library:
http://eab.abime.net/showthread.php?t=62731

Heart is in the right place, but again these are mostly bereft of licenses and attribution, so it is unclear what can legally be done.

It's quite clear in the these two cases: they can never be distributed without violating a third party's copyrights, so whatever license you would put on them wouldn't be valid anyway.

[Mrs Beanbag]

Originally Posted by wXR

I posted a Wikipedia link to an enormous number of games -- not engines -- that are open.

I think you read me wrong there, i didn't mean "it is not possible to open source games", only that it is possible to open source a game engine without any game that uses it having to be open source as well.

[Cylon]

I do like the idea of sharing knowledge of a specific approach towards solving a problem in code but i certainly don't like the "open src for all" idea.
today it is (as already mentioned) worse: "old" stuff is getting revitalized and money is earned by creating mobile apps out of other (older) creations. i don't like that.
i'm willing to contribute my silly src to make newcomers first steps a little less steep - but that's about it. nothing more.