I've been maintaining my personal website as plain HTML for five years now. I must say, I quite like this method. There's no substitute for practice when it comes to maintaining your skills at editing HTML and CSS.
Yes, you must copy and paste content and not having layout page is annoying at times. But the overhead of just doing it yourself is surprisingly small in terms of the time commitment.
Typically, I'll draft a post in MS Word then open the git repo for my site, hosted on github pages, duplicate and rename the template.html page that includes the CSS, footer, and header for my site and then copy my content into it. When I'm happy with everything, I'll make my commit and then a minute later it's live at my custom domain. Seeing that it takes only 11KBs and 26ms to load my landing page strangely delightful.
> copy and paste content and not having layout page is annoying at times
HTML was envisioned as an SGML application/vocabulary, and SGML has those power features, such as type-checked shared fragments/text macros (entities, possibly with parameters), safe third-party content transclusion, markup stream processing and filtering for generating a table of content for page or site navigation, content screening for removal/rejection of undesired script in user content, expansion of custom Wiki syntax such as markdown into HTML, producing "views" for RSS or search result pages in pipelines, etc. etc. See [1] for a basic tutorial.
I didn't expect this to be serious and am surprised on that the tutorial actually delivers. Way back when I was learning HTML and it was said that it was built with SGML, then this relation remained a total mystery to me.
> I didn't expect this to be serious and am surprised on that the tutorial actually delivers.
Same here. I believed that SGML was like Lisp of markup languages, except that it went completely extinct. Good to see it's still usable, I feel like I want to try it out now (instead of making a third generation of my static site generator from scratch).
I’ve become quite a fan of writing in SGML personally, because much of what you note is spot-on. Some of the points seem a bit of a stretch though.
Any type-checking inside of SGML is more akin to unused-variable checking. When you say that macros/entities may contain parameters, I think you are referring to recursive entity expansion, which does let you parameterize macros (but only once, and not dynamically within the text). For instance, you can set a `¤tYear` entity and refer to that in `copywrite "¤tYear/¤tDay`, but that can only happen in the DTD at the start of the document. It’s not the case that you could, for instance, create an entity to generate a Github repo link and use it like `&repoName = "diff-match-patch"; &githubLink`. This feature was used in limited form to conditionally include sections of markup since SGML contains an `IGNORE` “marked section”.
<!ENTITY % private-render "IGNORE">
...
<![%private-render[
<side-note>
I’m on the fence about including this bit.
It’s not up to the editorial standards.
</side-note>
]]>
SGML also fights hard against stream processing, even more so than XML (and XML pundits regret not deprecating certain SGML features like entities which obstruct stream processing). Because of things like this, it’s not possible to parse a document without having the entire thing from the start, and because of things like tag omission (which is part of its syntax “MINIMIZATION” features), it’s often not possible to parse a document without having _everything up to the end_.
Would love to hear what you are referring to with “safe” third-party transclusion and also what features are available for removal or rejection of undesired script in user content.
Apart from these I find it a pleasure to use because SGML makes it easy for _humans_ to write structured content (contrast with XML which makes it easy for software to parse). SGML is incredibly hard to parse because in order to accommodate human factors _and actually get people to write structured content_ it leans heavily on computers and software doing the hard work of parsing.
It’s missing some nice features such as namespacing. That is, it’s not possible to have two elements of the same name in the same document with different attributes, content, or meanings. If you want to have a flight record and also a list of beers in a flight, they have to be differentiated otherwise they will fail to parse.
DSSSL was supposed to be the transforms into RSS, page views, and other styles or visualizations. With XML arose XSL/XSLT which seemed to gain much more traction than DSSSL ever did. My impression is that declarative transforms are best suited for simpler transforms, particularly those without complicated processing or rearranging of content. Since `osgmls` and the other few SGML parsers are happy to produce an equivalent XML document for the SGML input, it’s easy to transform an SGML document using XSL, and I do this in combination with a `Makefile` to create my own HTML pages (fair warning: HTML _is not XML_ and there are pitfalls in attempting to produce HTML from an XML tool like XSL).
For more complicated work I make quick transformers with WordPress’ HTML API to process the XML output (I know, XML also isn’t HTML, but it parses reliably for me since I don’t produce anything that an HTML parser couldn’t parse). Having an imperative-style processor feels more natural to me, and one written in a programming language that lets me use normal programming conveniences. I think getting the transformer right was never fully realized with the declarative languages, which are similar to Angular and other systems with complicated DSLs inside string attribute values.
I’d love to see the web pick up where SGML left off and get rid of some of the legacy concessions (SGML was written before UTF-8 and its flexibility with input encodings shows it — not in a good way either) as well as adopt some modern enhancements. I wrote about some of this on my personal blog, sorry for the plug.
> When you say that macros/entities may contain parameters, I think you are referring to recursive entity expansion,
No, I'm referring to SGML data attributes (attributes declared on notations having concrete values defined on entities of the respective notation); cf. [1]. In sgmljs.net SGML, these can be used for SGML templating which is a way of using data entities declared as having the SGML notation (ie. stand-alone SGML files or streams) to replace elements in documents referencing those entities. Unlike general entities, this type of entity expansion is bound to an element name and is informed of the expected content model and other contextual type info at the replacement site, hence is type-safe. Data attributes supplied at the expansion site appear as "system-specific entities" in the processing context of the template entity. See [2] for details and examples.
Understanding and appreciating the construction of templating as a parametric macro expansion mechanism without additional syntax may require intimate knowledge of lesser known SGML features such as LPDs and data entities, and also some HyTime concepts.
> create an entity to generate a Github repo link
Templating can turn text data from a calling document into an entity in the called template sub-processing context so might help with your use case, and with the limitation to have to declare things in DTDs upfront in general.
> it’s not possible to parse a document without having the entire thing from the start, and because of things like tag omission (which is part of its syntax “MINIMIZATION” features), it’s often not possible to parse a document without having _everything up to the end_.
Why do you think so and why should this be required by tag inference specifically? In sgmljs.net SGML, for external general entities (unlike external parameter entities which are expanded at the point of declaration rather than usage), at no point does text data have to be materialised in its entirety. The parser front-end just switches input events from another external source during entity expansion and switches back afterwards, maintaining a stack of open entities.
Regarding namespaces, one of their creators (SGML demi-good James Clark himself) considers those a failure:
> the pain that is caused by XML Namespaces seems massively out of proportion to the benefits that they provide (cf. [3]).
In sgmljs.net SGML, you can handle XML namespace mappings using the special processing instructions defined by ISO/IEC 19757-9:2008. In effect, element and attributes having names "with colons" are remapped to names with canonical namespace parts (SGML names can allow colons as part of names), which seems like the sane way to deal with "namespaces".
I haven't checked your site, but most certainly will! Let's keep in touch; you might also be interested in sgmljs.net SGML and the SGML DTD for modern HTML at [4], to be updated for WHATWG HTML review draft January 2025 when/if it's published.
Edit:
> Would love to hear what you are referring to with “safe” third-party transclusion and also what features are available for removal or rejection of undesired script in user content.
In short, I was mainly referring to DTD techniques (content models, attribute defaults) here.
Took me a while to process your response; thanks for providing to so much to think about. And yes, it is indeed nice meeting other SGML enthusiasts!
Can’t say I’m familiar with the use of notations the way you are describing, and it doesn’t help that ISO-8879-1986 is devoid of any reference to the italicized or quoted terms you’re using. Mind sharing where in the spec you see these data attributes?
The SGML spec is hands-down the most complicated spec I’ve ever worked with, feeling like it’s akin to how older math books were written before good symbolic notation was developed — in descriptive paragraphs. The entire lack of any examples in the “Link type definition” section is one way it’s been hard to understand the pieces.
> some HyTime concepts
I’m familiar with sgmljs but have you incorporated HyTime into it? That is, is sgmljs more like SGML+other things? I thought it already was in the way it handles UTF-8.
> Why do you think so and why should this be required by tag inference specifically?
Perhaps it’d be clearer to add chunkable to my description of streaming. Either the parser gets the document from the start and stores all of the entities for processing each successive chunk, or it will mis-parse. The same is true not only for entities for also for other forms of MINIMIZATION and structure.
Consider encountering an opening tag. Without knowing that structure and where it was previously, it’s not clear if that tag needs to close open elements. So I’m contrasting this to things that are self-synchronizing or which allow processing chunks in isolation. As with many things, this is an evaluation on the relative complexity of streaming SGML — obviously it’s easier than HTML because HTML nodes at the top of a document can appear at the end of the HTML text; and obviously harder than UTF-8 or JSON-LD where it’s possible to find the next boundary without context and start parsing again.
> Regarding namespaces, one of their creators (SGML demi-good James Clark himself) considers those a failure:
Definitely aware of the criticism, but I also find them quite useful and that they solve concrete problems I have and wish SGML supported. Even when using colons things can get out of hand to the point it’s not convenient to write by hand. This is where default namespacing can be such an aid, because I can switch into a different content domain and continue typing with relatively little syntax.
Of note, in the linked reference, James Clark isn’t arguing against the use of namespaces, but more of the contradiction between what’s written in the XML and the URL the namespace points to, also of the over-reliance on namespacing for meaning in a document.
What feels most valuable is being able to distinguish a flight of multiple segments and a flight of different beers, and to do so without typing this:
Put another way, I’m not concerned about the problem of universal inter-linking of my documents and their semantics across the web, but neither was SGML.
Get a copy of The SGML Handbook! It includes the ISO 8879 text with much needed commentary. The author/editor deliberately negotiated this to get some compensation for spending over ten years on SGML; it's meant to be read instead of the bare ISO 8879 text.
Regarding HyTime, the editor (Steven Newcomb or was it Elliot Kimber?) even apologized for its extremely hard-to-read text, but the gist of it is that notations were used as a general-purpose extension mechanism, with a couple of auxiliary conventions introduced to make attribute capture and mapping in link rules more useful. sgmljs templating uses these to capture attributes in source docs and supply the captured values as system-specific entities to templates (the point being that no new syntax is introduced that isn't already recognized and specced out in HyTime general facilities). The concept and concrete notations of Formal System Identifiers is also a HyTime general facility.
HyTime was Kimber’s work, and I found this reflections of his on “worse is better” to be quite refreshing, especially when contrasting the formality of SGML against the flexibility of HTML.
I’ll have to spend more time in the SGML Handbook. It’s available for borrowing at https://archive.org/details/sgmlhandbook0000gold. So far, I’ve been focused on the spec and trying to understand the intent behind the rules.
> a couple of auxiliary conventions introduced to make attribute capture and mapping in link rules more useful
Do you have any pointers on how to find these in the spec or in the handbook? Some keywords? What I’ve gathered is that notations point to some external non-SGML processor to handle the rendering and interpretation of content, such as images and image-viewing programs.
> Do you have any pointers on how to find these in the spec or in the handbook?
I just checked now, and apart from FSIDR I was mainly referring to DAFE [1], a HyTime 2nd ed. facility actually part of AFDR (archforms) allowing additional attribute capture and mappings in link rules towards a more complete transformation language as SGML's link rules are a little basic when it comes to attribute handling. Note in a HyTime context, transformations (for lack of a better word) are specified by AFDR notations/data attributes in not only a highly idiosyncratic way but also redundantly when SGML LINK is perfectly capable to express those classes of transformations, and more. sgmljs only implements LPD-based transformations (yet with more power such as inheritance of DTDs into type checking of template processing contexts and pipelining) and only the DAFE part of AFDR but not other parts.
> Yes, you must copy and paste content and not having layout page is annoying at times. But the overhead of just doing it yourself is surprisingly small in terms of the time commitment.
This calls out for server side includes[0]. I so loved server side includes back in the late 90s. You still work in plain HTML and CSS, boilerplate can be centralized and not repeated, and clients receive the entire page in a single request.
Many people who maintain their own sites in vanilla web technologies tend to create reusable functions to handle this for them. It can generate headers and the like dynamically so you don't have to change it on every single page. Though that does kill the "no javascript required" aspect a lot of people like
Of course you could simply add a build step to your pure HTML site instead!
A few extra <object> in a blog post is a worthwhile tradeoff, if you're literally using raw HTML.
- HTTP/1.1 (1997) already reuses connections, so it will not double latency. The DNS lookup and the TCP connection are a high fixed cost for the first .html request.
- HTTP/2 (2015) further reduces the cost of subsequent requests, with a bunch of techniques, like dictionary compression.
- You will likely still be 10x faster than a typical "modern" page with JavaScript, which has to load the JS first, and then execute it. The tradeoff has flipped now, where execution latency for JS / DOM reflows can be higher than network latency. So using raw HTML means you are already far ahead of the pack.
So say you have a 50 ms time for the initial .html request. Then adding some <object> might bring you to 55 ms, 60 ms, 80 ms, 100 ms.
But you would have to do something pretty bad to get to 300 ms or 1500 ms, which you can easily see on the modern web.
So yes go ahead and add those <object> tags, if it means you can get by with no toolchain. Personally I use Markdown and some custom Python scripts to generate the header and footer.
Yes, I’d add that not merely “raw html” but a file on disk can be served directly by Linux without context switches (I forget the syscall), and transferred faster than generation.
Sounds like premature optimization for a simple page. If the objects are sized their regions should be fillable afterward without need to resize and be cached for subsequent access.
Yes, and a Makefile was an option as well. But an include tag was a no-brainer not long after html was invented. Especially after img, link, applet, frame, etc were implemented.
I've adopted the idea that a blog post is archived when it's published; I don't want to tinker with it again. Old pages may have an old style, but that's OK, it's an archive. Copy/paste works great for this.
The only reason I use a blog engine now (Hugo) is for RSS. I kept messing up or forgetting manual RSS edits.
[EDIT: Dammit, my blog doesn't use that webcomponent anymore! Here's an actual production usage of it: https://demo.skillful-training.com/project/webroot/ (use usernames (one..ten)@example.com and password '1' if you want to see more usage of it)]
yeah clearly there's a lot of ways to solve this issue if javascript is enabled. But there's a big overlap between the folks who wanna use vanilla web technologies and the folks who want their site to run without javascript
Not remotely! Unless you meant Preact. React ships an entire rendering engine to the front-end. Most sites that use React won't load anything if javascript isn't enabled
Yes, it is. Unfortunately HN has a crazy bias against JavaScript (the least crazy part of the web stack) and in favour of HTML and CSS, even though the latter are worse in every meaningful way.
It isn't crazy, judging by the number of times I've seen posts here and on other blogs talking about a 100k web page ballooning to 8Mb because of all the Javascript needed to "collect page analytics" or do user tracking when ads are included. Granted that may not be needed for personal websites, but for almost anything that has to be monetized you're going to get stuck with JS cancer because some sphincter in a suit needs for "number to go up".
> I've seen posts here and on other blogs talking about a 100k web page ballooning to 8Mb because of all the Javascript needed to "collect page analytics" or do user tracking when ads are included
Perfect example. HN will see a page with 6Mb of images/video, 1Mb of CSS and 200Kb of JavaScript and say "look at how much the JavaScript is bloating that page".
I don't even know where to begin with the pretence that you can compare HTML with JS and somehow conclude that one is 'better' than the other. They are totally different things. JS is for functionality, and if you're using it to serve static content, you're not using it as designed.
I don't particularly care about "designed for". If you've got to serve something to make the browser display the static content you want it to, the least unpleasant way to do so is with JS.
Least unpleasant to the developer. Most unpleasant to the user. It breaks all kinds of useful browser features (which frontend devs then recreate from scratch in JS, poorly; that's probably the most widespread variant of Greenspun's tenth rule in practice).
> It breaks all kinds of useful browser features (which frontend devs then recreate from scratch in JS, poorly; that's probably the most widespread variant of Greenspun's tenth rule in practice).
Nah, it's the opposite. JS tends to perform better and be more usable for the same level of feature complexity (people who want more complex sites, for good reasons or bad, tend to use JS, but if you compare like with like), HN just likes to use them as a stick to reinforce their prejudices. (E.g. if you actually test with a screenreader, aria labels work better than "semantic" HTML tags)
> E.g. if you actually test with a screenreader, aria labels work better than "semantic" HTML tags
Interesting how this is opposite to the recommendations from MDN, such as:
Warning: Many of these widgets are fully supported in modern browsers. Developers should prefer using the correct semantic HTML element over using ARIA, if such an element exists.
The first rule of ARIA use is "If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so." -- which also refers to: https://www.w3.org/TR/using-aria/#rule1
Though I can believe that real life may play out different than recommendations.
Also, as I understand it, ARIA is orthogonal to JS, and it doesn't alter behavior for browser users.
> Yes, you must copy and paste content and not having layout page is annoying at time
I think this was one of the most common usages of PHP in the beginning, at least for those who basically wrote static HTML/CSS and needed a header/footer. It was probably a gateway into more advanced dynamic pages, eventually ending up using databases and other advanced functionality.
<?php include('header.inc'); ?>
<p>Here's a list of my favourite movies</p>
<ul>
<li>...</li>
</ul>
<?php include('footer.inc'); ?>
It would be great if HTML had a similar capability. People have asked for it for over 30 years, so it's unlikely that it will be implemented now.
To reduce CPU and IO load on the server (or just in circumstances where SSI was not enabled on the server they had available) some would pre-process the SSI directives (obviously this doesn't work for dynamic results such as the output from many #exec examples), so all that is being served is simple static files ‑ a precursor to more complex modern static site builders.
> It would be great if HTML had a similar capability. People have asked for it for over 30 years, so it's unlikely that it will be implemented now.
That doesn't really fit with the intentions of HTML, and could impose a bunch of extra network latency overhead compared to using SSI instead, leading to either complete rendering delays or jumpy pages as included content is merged in in steps, though I have seen it implemented multiple ways using a bit of JS (some significantly more janky than others).
Why not use server side includes? Most web servers support it, and it dates back to one of the early features of webservers.
<!--# set var="pagetitle" value="Main page" -->
<!--# include file="00__header.html" -->
... main content here
<!--# include file="00__footer.html" -->
Because that requires a server with the proper config and this is an HTML file. So it works in every environment, like locally on your machine, or GitHub pages.
This is my workflow for my site, too, just replacing MS Word with Obsidian since it syncs over all my devices allowing me to write/edit my future content wherever I am at, then upload later.
I tried things like bashblog for awhile, but it has some quirks like sometimes placing posts out of order when building the index page. That and I have zero use for the built in analytics options or things like Discus comments, so it seemed like I was really only using about 30% of what it was meant to do.
Here's a link to that for anyone interested. It's quite tweakable.
I've started the Slab templating language[0] to be able to define reusable HTML fragments. It means using a dedicated tool but hopefully not needing to resort to a real programming language.
Impressed that this runs on my RX 6900XT (an RDNA2 GPU) in Chrome without any trouble. Very cool demo, excited to see how people leverage this capability.
I used this stack to replace a Django/Python app that was built over 2 years by another dev in 2 weeks. We regularly have 1 hour turn arounds between when an issue/feature is filed on Github and when a new build is live with that code. The self-contained deployments have made it simple to deploy this app, and now its supporting apps, to our linux-based cloud instances.
I've built on many stacks and although I agree that iteration speed is important; It has more to do with how you organize your project and the quality of your tooling than with the specific language/framework.
If you don't like the OOPy style, don't write in it. Pattern matching in C# is quite nice, and you can always mark you functions as static. As a bonus, simple functions are easier to test to.
Make sure you have a plan to upgrade all your projects to .NET 5.[1]
ASP.NET is quite fun, if you can keep your work up to date. Opening up a project that needs bug fixes, but doesn't have access to the latest tooling in VS2019 or language syntax because it still on the old .NET Framework is a bummer.
Any company that was willing to update their .NET apps regularly, and treat development of the app as a service rather than a one time project would make me jump ship.
My favorite part is the tooling. For example when you hover over a method name in VS 2019 it will show you its signature and what parameters it takes. If you right click on it and select "Go to definition" it will show you the code for the method. Just above the method name you'll a little chunk of text that says "2 References" which you can click on to see all of the places in your project where the method is invoked and links to review them. What makes ASP.NET fun is the quality and completeness of the tooling.
> Seems like companies that are not updating their apps is more common than those that do. I wonder why.
I'm guessing this is just a product of .NET being big in the "enterprise" world. I dont mind modern Java, but I remember when I was working with Java around Java 7 people would complain about being stuck maintaining Java 1.4-1.5 apps.
Open source property tax assessment, admin, and collection software. This space is foundational to the function of local government, but the existing closed-source offerings in this space are expensive, dated, and opaque to the public.
This will never be VC backable because the market is small and each local government has special needs and unique requirements. The cost per customer is high and there's a hard cap on the TAM.
In a prior job I was tasked with building a REST API client for a closed source vendor product in this space as part of project to replace an existing system. Data need to be captured from a dozen on-prem databases that supported other vendor applications and then pushed into this new system using the client I built.
Sadly, the vendor provided scanned copies of JIRA user-stories as documentation of their app's API. Despite much struggling, the vendor wouldn't implement even the most basic auto-generated documentation for their API (Swagger). Bugs filed against their product regularly had a 3 month turn around time.
If there were an open source product in this space I could have forked it, made the changes I needed, submitted a pull request and then escalated it with management to get it mainlined by the vendor.
We were their only client for this product and they needed us to implement their system as an example of success so they could make further sales. But their secrecy made good-faith efforts at building integrations with their product extremely difficult. This might have been survivable if the vendor was good at communicating.
Alas this project just got delayed for another year after it was discovered by one of my old coworkers that the new system wasn't calculating property taxes correctly. If we had taken the vendor at their word this would have not been discovered and incorrect taxes may have gone out. Nobody loves taxes, but people rightfully hate it when their local government makes preventable mistakes.
Open source software in this space would reduce the rate of errors made in these scenarios and allow the public to verify the correctness of the system that taxes their property. As a bonus the cost of developing these systems could be spread across multiple local governments who each employ their own developers, rather than each group struggling through this process on their own once a decade.
I wonder how open source software would be received by local governments. The conditions of government contracts often provide for guarantees/penalties for the delivered software. Moreover, the barriers of entry are typically high, the bidder needs to have x years of "prior experience" with crazy compliance and insurance requirements.
Yeah, my productivity would take a hit if I didn't have a quiet space and a good monitor setup. I've always assumed that coffee shops were more for meeting people than actually getting work done.
I have a very different experience. I’ve often found sitting in a coffee shop helps things click and helps me get into a flow when doing development. It’s the right level of background noise for me and the little bit of public observation helps me get less distracted. A few hours of focused work can go by in a flash. When I worked in an open office I would sometimes spend an hour or two at the coffee shop knocking out some development tasks so that a big chunk of my days work was done, then when in the office I could focus more on collaboration, helping others, socializing a bit, without the big struggle to regain focus after the natural interruptions that happen at work.
It's not surprising: The GPL mostly torpedoes commercial uses, and EA does not want to give their competitors code they can use in their own proprietary games.
It does effectively prohibit you from competing with someone else who compiles there code and puts up a download link for free. The “but you can still charge money for it” aspect has always fallen flat, especially since most people won’t pay for disks containing something they could download online these days.
You could presumably make a derivative game using the engine, and sell the game's assets, while complying with the licensing terms on the engine code.
I don't know any examples of this happening, but we've seen the engine/assets distinction before when DOOM and Quake were opened. Their source code was released as Free and Open Source software, but the game assets remain payware to this day.
Yeah but if I use this GPL licensed code as the basis of a new game, I have to release the source code for my new game as well.
The vast majority of game studios aren't willing to do this, so effectively releasing it under the GPL means that it's much less likely that a competitor uses the code.
Asset flips from other countries with more permissive (or just hard to access for foreigners) legal systems are already a problem for game developers--releasing the source code for your game would ensure that you'd be inundated with assets flips almost immediately if your game is any good.
Gamedev is really a special case (if we consider Web Development to be the "common case"). The fact is, when a company open sources one of it's projects, it expects to "benefit" from open source, i.e. taking community contributions, and make these contributions into its other closed-source products to generate profits. GPL forbids this, and naturally most companies open sources with MIT/BSD.
And follows a repository on GitHub, many issues and PRs, CI, periodic releases (feel free to replace "GitHub" with "GitLab" or some server on some university, replace issues with mailing lists etc.) - that's what we typically expect from an "open source project" backed by other companies, in some other industries (most notably web development).
It doesn't work this way in games (at least for now), EA is only releasing part of the code for modding purpose, EA doesn't expect an "open source community" established on this codebase, and I also don't think EA has the intention to take contributions directly from community (by "directly" I mean, in code). If you have something you don't like about the game, post a comment in Steam and if you are lucky the devs are going to fix it themselves. It has always been working in this way in games, and it's not changing despite the "open source" action.
So in this case, GPL is actually more helpful for EA, as illustrated by other replies.
But what I really want to say is, being a C&C modder myself (I've been modding RA2/YR from 2009 and also briefly worked on C&C3 later), I wholeheartedly support EA's decision to use GPL. Not because it's good for EA, not because I'm also a fan of RMS, it's because of the specific situation of the modding community.
If we take a simplistic view of a mod, it's roughly composed of "assets" and "code" (the same could be said for full games but it'll be more complicated). For assets, there are awesome free content creation software such as Blender and Krita, and tons of learning resources on the Internet. One can easily become a quasi-professional artist given enough exercise (I, personally, have undergone such a process). Well there is also things like music, but they all work the same way in which you "just create something in some external application (which is usually very powerful and extendable) and throw it in the game". You are not really limited in terms of asset.
The real problem is in "code" - modders are ultimately constrained by a proprietary engine, which heavily limits the possibility of mods. Just think about it: when you're making a real game, you can think about "What is the most interesting stuff I can come up with?" and then implemented it in the game engine. But when making a mod, whenever a fancy idea pops up, you're obligated to consider "Can it be implemented in the engine?". Unfortunately, most of the time, the answer is no. And this goes on and on, till a point where your imagination is imprisoned by the capability of the engine, that you lost the inspiration to design anything novel.
Why the engine is so limited? I think we can just imagine the scenario: in the crunch of getting the game finished, the devs don't really care about moddability, they just want to get it working ASAP, then they do all kinds of hack all the way along. In the end the game works, but modding it sucks. They hardcoded many stuff directly into the game engine binary, which is perfectly reflected by this set of search result: https://www.google.com/search?q=hardcode+site%3Amodenc.reneg... ... Oh and this is only about modifying existing stuff, we haven't started talking about adding a completely new system yet ...
To overcome these limitations, modders did a tremendous amount of efforts over the years:
Then this approach evolved, they analyzed the binary to get the class hierarchy of the game, then use C++ to write new logic, inject the compiled routines into the binary: https://ares.strategy-x.com
It seems I digressed a lot, but while one can make very sophisticated models, the "upper limit" of a mod, and the ceiling of the modding community as a whole, really lies on:
* How one can extend the engine. But this makes sense only if one can do this, i.e. has the skill, time, and resource to do it. It's not just some arbitrary CRUD logic, it's bulks of assembly code compiled from poorly written sources (thankfully the compiler is also poor so not much optimization).
* How one can make the best use of the existing features of the engine in absurd ways.
For example, suppose I want a tank firing laser from the sky (think about Athena Cannon in Red Alert 3 https://www.youtube.com/watch?v=IbX7R3UYtzI), the engine doesn't offer such a feature. The solution is to set the Z component of the unit's "firing coordinate" to 65535 so it "looks like" firing from sky.
A more advanced example would be mimicing the sweeping laser of Colossus in Starcraft 2 (https://www.youtube.com/watch?v=u5YEI-_o5dQ), or laser of Future Tank/Giga Fortress in RA3. To do this, one can 1) Make a unit launch a V3 rocket, but make the rocket invisible; 2) Add a weapon to that unit, that automatically attacks the "rocket" it fires, make the weapon draws laser. Then as the "rocket" is approaching the target, the unit will attacking the rocket with laser, and as the rocket is moving, the laser will look to be sweeping. That's how you get this "BTS": https://www.moddb.com/mods/mklab/images/behind-the-scene
Surely this is a horrible hack and it'll break as soon as you have multiple Colossuses in a perimeter simultaneously - the laser weapon works by "filtering all rockets of a specific tag", but the tag can't be made specific to every "instance" of Colossus - there is just no such feature! They will just randomly pick a rocket fired by others and draw the laser and the whole stuff breaks up.
In reality, most people ends up in the later way because they can't do reverse engineering, there are many clever tricks just like the one above contrived by clever people. And even if you're working on the engine binary itself, it'll just be more difficult and time consuming to extract any non-trivial stuff from the huge sequence of instructions.
All these won't be necessary if the game is open sourced. I personally feel sorry for all these brilliant minds "wasted" on these useless shits. And that's exactly why I don't do modding anymore (maybe I'll pick it up again if this open source of Remastered turns out to be interesting enough).
However, despite the grim situation, some people that's working on workarounding the engine just lock their stuff for themselves, for their own mods. They're not sharing. This means newcomers can't leverage their existing program databases to do new work, can't get their own features integrated with others, and even redoing much of others work (no source code access). As a result, fewer people want to get into this business.
This is not an accident: TibSun/RA2 uses their own ".mix" archive for storing assets and some of the code. It kinda like plain tar, just concatenate all files together w/o compression. But the format is designed to be read only by the game. It allows the archive to store only hashes of the filenames, the actually filenames can be omitted in the archive. When the game requests for a certain file it just use hash to identify the file. We have a GPL tool for working with these files. But to protect unapproved reuse of assets and modding of the mod itself, some modders intentionally omit the filename in archives of the mod they distributes to make it incomprehensible for other humans. They also tinkered with the file header so it's only readable by the game and not by other tools.
This is, in fact, very reasonable, I'd say 60% people in the modding community are idiots, they're somewhat likely to just rip assets from other mods and use in their own mods without even crediting the original author. And sometimes it's just the author wants some "unique" stuff in his/her mod, and absolutely don't want others to use it under any term.
90% of the modding community don't know enough about free software, open source or GitHub (also reasonable since the modding community is just samples from ordinary players, and that's also why EA can't expect a proper "open source community"). They don't know how sharing stuff can make things much better. Of course it's their freedom to protect their work, and few people want to share stuff with idiots. I'm mostly with them for protecting assets. But as I said, the engine stuffs are different. These techs are critical for the future of the community, and are best shared as much as possible.
I know someone who did some work on the engine, and has been treating these work as the most closely guarded secret since then, and even becomes paranoid. He once consulted me about "how to protect these magic from being exposed to the public with his mod". Well technically you can do it! (of course only to some degree) But what's the point of doing this?
That's why I think the GPL license mandated on the Remastered source can really make the community much more healthy. Though I'm not very confidence about it - I also discussed with the paranoid guy above about GPL long before the Remastered. I think one can easily infer that if one don't get the point of free software and open source, then he is also not likely to know GPL at all, even if he knows GPL he still can't get the point of it, and will hold the most utilitarianism view towards open source: If I can use it, then take it for myself and hide it deep inside my mod, if I can't use it, find some workaround to use it. After all, it's not likely that EA will sue a non-profit modder for a minor licence violation ...
